formalizing the ARB publishing policy

[Allison Randal]

The Tech Board recently reviewed a publishing policy for the Partner 
repository, and one of their recommendations was that it might be merged 
with the Extras publishing policy. See the discussion thread starting here:

https://lists.ubuntu.com/archives/technical-board/2011-June/000912.html

I've talked with Nick Barcet this week about how we might do this, and 
came up with a draft that merges our ARB policy with their draft policy. 
Actually, the two were quite close, so it was mainly a matter of adding 
a few points from ours to theirs.

I'll put this up on the wiki as soon as logins start working from the 
upgrade last night, but in the meantime, I've put the full text at the 
bottom of the message. Does this seem like a good match for our policy? 
Our policy is currently scattered across a few documents, mainly in 
https://wiki.ubuntu.com/PostReleaseApps/Process. I left out a few bits 
that were more purely technical, and could be handled in a packaging 
guide (like how to install in /opt).

Not sure if "Software Center" is the best name to use, but I thought of 
it while working out how to explain the connection between Extras, 
Partner, and Commercial. In Natty and later, the names of the 
repositories in Software Center will be what most users see.

Allison

----------
Software Center Publishing Policy

The objective of the Software Center publishing policy is to ease the 
path to publishing packages, while protecting Ubuntu users from poor 
quality, malicious, or illegal applications. In general, we're seeking a 
light-weight framework that enables developers to clearly understand the 
rules and how we apply them. This policy applies to software published 
through one of the extension repositories in Software Center 
(“Independent”, “For Purchase”, or “Canonical Partners”).

Packages in the Software Center must meet the following criteria:
     1. The package must not create a problem with the proper function 
of Ubuntu or any of the packages present in Main, Universe, Restricted 
or Multiverse
     2. The package may only depend on other packages that are present 
in Main, Universe, Restricted, Multiverse, or in the same extension 
repository.
     3. The package must not modify files that do not belong to the 
application, such as files provided by another package or that are put 
in place during the Ubuntu installation process
     4. The package must not perform any malicious actions.
     5. Packages in Main, Universe, Multiverse and Restricted must not 
depend on packages in any of the extension repositories (“Independent”, 
“For Purchase”, or “Canonical Partners”)1
     6. Only new packages that are not present in Main, Universe, 
Restricted or Multiverse are eligible (e.g an updated version of an 
application in an existing repository is not eligible).
     7. Packages should follow Filesystem Hierachy Standard (FHS). This 
may include extensive use of package-specific directories under /opt.
     8. For “Canonical Partners” or “For Purchase” software, the partner 
must sign a distribution agreement, unless Canonical explicitly decides 
to carry full responsibility for the package (including maintenance, 
support and legal).
     9. Content must be suitable for general audiences, respecting the 
Ubuntu Code of Conduct.

Archive administrators will enforce the above rules before accepting a 
package in the repository and may eventually remove any package[2] that 
has a known issue (security or discovery of a fact that breaks the above 
rules) when the partner failed to respond to our requests to fix in a 
timely manner. A specific Ubuntu Security Notice might also be published 
in this case.

Packaging

Packages should use the Debian package format, correctly indicate all 
dependencies, and be cleanly installed and removed. It is recommended to 
follow the Ubuntu Policy Manual as closely as possible, but note the 
following differences:

     2.1 Ubuntu Licensing Policy: if a redistribution agreement is 
signed, no limitations apply in terms of licensing, as licensing 
responsibility is transferred to the partner
     2.2 Archive Areas: should be read with an added reference to this 
policy for the extension repositories.
     2.3 Copyright Considerations: is waved if a distribution agreement 
is signed, as it transfers the responsibility of copyright assignment to 
the the partner
     3.3 Maintainer of a package: the maintainer should be a valid 
entity defined by the partner
     4.5 Copyright: debian/copyright: is waved if a distribution 
agreement is signed as it transfers the responsibility of copyright 
assignment to the partner (partners should still pay close attention to 
this, though)
     Chapter 8 - Shared libraries: is waved if a distribution agreement 
is signed. It is left to the maintainer to choose how he will use shared 
libraries, as long as it does not conflict with the behavior of existing 
shared libraries
     10.2 Libraries: is waved if a distribution agreement is signed. It 
is left to the maintainer to choose how he will use libraries, as long 
as it does not conflict with the behavior of existing libraries
     12.5 Copyright information: is waved if a distribution agreement is 
signed as it transfers the responsibility of copyright assignment to the 
partner (partners should still pay close attention to this, though)


Footnotes

     This is a standard policy for these repositories that is not being 
defined here, just placed here as a reminder (1)
     This will not remove the the software for users that have already 
deployed it but will prevent its installation by any other users. (2)

----------