Extension Repository Policy
The objective of the extension repository policy is to ease the path to publishing packages, while protecting Ubuntu users from poor quality, malicious, or illegal software. 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 Extras, Partner, and Commercial (they appear in Software Center as “Independent”, “Canonical Partners”, and “For Purchase”).
1.0 Technical Criteria
Packages in the extension repositories must meet the following criteria:
1.1 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).
1.2 Packages should follow the Filesystem Hierarchy Standard (FHS). This may include extensive use of package-specific directories under /opt.
1.3 The package may only depend on other packages that are present in Main, Universe, Restricted, Multiverse, or in the same extension repository.
1.4 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
1.5 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
1.6 The package must not perform any malicious actions.
1.7 Packages in Main, Universe, Multiverse and Restricted must not depend on packages in any of the extension repositories (Extras, Partner, or Commercial)1
1.8 For Partner and Commercial repositories, the partner must sign a distribution agreement, unless Canonical explicitly decides to carry full responsibility for the package (including maintenance, support and legal).
1.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 package2 that has a known issue (security or discovery of a fact that breaks the above rules) when the partner fails to respond to our requests to fix in a timely manner. A specific Ubuntu Security Notice might also be published in this case.
2.0 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: The debian/copyright file is where Debian packages store information about the copyright and license of a package. A distribution agreement transfers the responsibility of copyright management to the partner, so we won't perform independent verification of the contents of this file for partners. For the benefit of the users, you should include copies of the software's standard copyright statements and licensing terms in debian/copyright. It's also helpful to provide information on any free software included in the package.
3.3 Maintainer of a package: the maintainer should be a valid entity defined by the partner
4.5 Copyright: debian/copyright: see notes on 2.3.
Chapter 8 - Shared libraries: is waived if a distribution agreement is signed. It is left to the maintainer to choose how they will use shared libraries, as long as it does not conflict with the behavior of existing shared libraries
10.2 Libraries: is waived if a distribution agreement is signed. It is left to the maintainer to choose how they will use libraries, as long as it does not conflict with the behavior of existing libraries
12.5 Copyright information: see notes on 2.3.
This policy was approved by the Ubuntu Technical Board on August 11, 2011.