formalizing the ARB publishing policy
Allison Randal
allison.randal at canonical.com
Fri Jun 17 18:44:29 UTC 2011
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)
----------
More information about the App-review-board
mailing list