ubuntu-policy.txt

This manual describes the policy requirements for the Ubuntu distribution. This includes the struc

2.2.1. The main category
------------------------

     Every package in _main_ must comply with the Ubuntu Licensing Policy.

     In addition, the packages in _main_
        * must not require a package outside of _main_ for compilation or
          execution (thus, the package must not declare a "Depends",
          "Recommends", or "Build-Depends" relationship on a non-_main_
          package),
        * must not be so buggy that we refuse to support them, and
        * must meet all policy requirements presented in this manual.

2.2.2. The restricted category
------------------------------

     Every package in _restricted_ must comply with the Ubuntu Licensing
     Policy, with the exceptions that source code may not be available and
     that modification may not be permitted.

     In addition, the packages in _restricted_
        * must not be so buggy that we refuse to support them, and
        * must meet all policy requirements presented in this manual that
          it is possible for them to meet.  [1]

     The Ubuntu team recognises that many users have vital hardware in
     their computer that requires drivers that are currently only available
     in binary format.  We urge all hardware vendors to insist that their
     suppliers provide open source drivers for their components, but we
     recognise that in some cases binary drivers are the only way to make
     your hardware work.  As a result, Ubuntu includes several of these
     drivers on the CD and in the repository, clearly separated from the
     rest of the software by being placed in the _restricted_ category.

     Binary drivers are a poor choice, if you have a choice.  Without
     source code, Ubuntu cannot support this software, we only provide it
     for users who require it to be able to run the Free Software we
     provide in main.  Also, we cannot make binary drivers available on
     other architectures (such as the Mac or IPAQ) if we don't have the
     ability to port the software source code ourselves.  If your hardware
     is fully supported with open source drivers you can simply remove the
     _restricted_ category, and we would encourage you to do so.

     The _restricted_ category may not include application software, only
     hardware drivers.

[1]  It is possible that there are policy requirements which the package is
     unable to meet, for example, if the source is unavailable.  These
     situations will need to be handled on a case-by-case basis.

2.2.3. The universe category
----------------------------

     Every package in _universe_ must comply with the Ubuntu Licensing
     Policy.

     Packages in the _universe_ category are not supported by the core
     Ubuntu developers and Canonical Ltd.  Packages may be moved between
     _main_ and _universe_ as their support status changes.

     In addition, the packages in _universe_
        * must not require a package outside of _main_ and _universe_ for
          compilation or execution (thus, the package must not declare a
          "Depends", "Recommends", or "Build-Depends" relationship on a
          non-_main_ and non-_universe_ package), and
        * must meet all policy requirements presented in this manual.

2.2.4. The multiverse category
------------------------------

     Every package in _multiverse_ must comply with the Ubuntu Licensing
     Policy, with the exceptions that source code may not be available,
     that modification may not be permitted, that rights may not be passed
     on along with the software, that they may discriminate against
     persons, groups or fields of endeavour, and that their license may be
     specific to Ubuntu.  (In other words, they must be redistributable
     without a fee and must not contaminate other software licenses.)

     Packages must be placed in _multiverse_ if they are not compliant with
     the parts of the Ubuntu Licensing Policy that cover other categories
     of the archive, or if they are encumbered by patents or other legal
     issues that make their distribution problematic.

     Packages in the _multiverse_ category are not supported by the core
     Ubuntu developers and Canonical Ltd.

     In addition, the packages in _multiverse_
        * must not be so buggy that we refuse to support them, and
        * must meet all policy requirements presented in this manual that
          it is possible for them to meet.  [1]

[1]  It is possible that there are policy requirements which the package is
     unable to meet, for example, if the source is unavailable.  These
     situations will need to be handled on a case-by-case basis.


2.3. Copyright considerations
-----------------------------

     Every package must be accompanied by a verbatim copy of its copyright
     and distribution license in the file
     `/usr/share/doc/<package>/copyright' (see Section 12.5, `Copyright
     information' for further details).

     We reserve the right to restrict files from being included anywhere in
     our archives if
        * their use or distribution would break a law,
        * there is an ethical conflict in their distribution or use,
        * we would have to sign a license for them, or
        * their distribution would conflict with other project policies.

     Programs whose authors encourage the user to make donations are fine
     for the main distribution, provided that the authors do not claim that
     not donating is immoral, unethical, illegal or something similar; in
     such a case they must go in _multiverse_.

     Packages whose copyright permission notices (or patent problems) do
     not even allow redistribution of binaries only, and where no special
     permission has been obtained, must not be placed on the Ubuntu FTP
     site and its mirrors at all.

     Note that under international copyright law (this applies in the
     United States, too), _no_ distribution or modification of a work is
     allowed without an explicit notice saying so.  Therefore a program
     without a copyright notice _is_ copyrighted and you may not do
     anything to it without risking being sued!  Likewise if a program has
     a copyright notice but no statement saying what is permitted then
     nothing is permitted.

     Many authors are unaware of the problems that restrictive copyrights
     (or lack of copyright notices) can cause for the users of their
     supposedly-free software.  It is often worthwhile contacting such
     authors diplomatically to ask them to modify their license terms.
     However, this can be a politically difficult thing to do and you
     should ask for advice on the `ubuntu-archive' mailing list first, as
     explained below.

     When in doubt about a copyright, send mail to
     <[e-mail]>.  Be prepared to provide us with the
     copyright statement.  Software covered by the GPL, public domain
     software and BSD-like copyrights are safe; be wary of the phrases
     "commercial use prohibited" and "distribution restricted".


2.4. Sections
-------------

     The packages in the categories _main_, _restricted_, _universe_ and
     _multiverse_ are grouped further into _sections_ to simplify handling.

     The category and section for each package should be specified in the
     package's `Section' control record (see Section 5.6.5, ``Section'').
     However, the maintainers of the Ubuntu archive may override this
     selection to ensure the consistency of the Ubuntu distribution.  The
     `Section' field should be of the form:
        * _section_ if the package is in the _main_ category,
        * _segment/section_ if the package is in the _restricted_,
          _universe_ or _multiverse_ distribution areas.[1]

     The Ubuntu archive maintainers provide the authoritative list of
     sections.  At present, they are: _admin_, _comm_, _devel_, _doc_,
     _editors_, _electronics_, _embedded_, _games_, _gnome_, _graphics_,
     _hamradio_, _interpreters_, _kde_, _libs_, _libdevel_, _mail_, _math_,
     _metapackages_, _misc_, _net_, _news_, _oldlibs_, _otherosfs_, _perl_,
     _python_, _science_, _shells_, _sound_, _tex_, _text_, _utils_, _web_,
     _x11_.

     Ubuntu: The _metapackages_ section exists for the benefit of package
     management tools.  When removing a package in that section, its
     dependencies will not be automatically considered for removal by tools
     which track the distinction between packages that were installed
     explicitly and packages that were only installed to satisfy
     dependencies.

[1]  Packages that originally came from the Debian archive will often not
     have `Section' fields matching the distribution area selected for them
     in Ubuntu.  There is no need to change the package just for this; the
     maintainers of the Ubuntu archive can and will override its placement.


2.5. Priorities
---------------

     Each package should have a _priority_ value, which is included in the
     package's _control record_ (see Section 5.6.6, ``Priority'').  This
     information is used by the Ubuntu package management tools to separate
     high-priority packages from less-important packages.

     The following _priority levels_ are recognized by the Ubuntu package
     management tools.

     `required'
          Packages which are necessary for the proper functioning of the
          system (usually, this means that dpkg functionality depends on
          these packages).  Removing a `required' package may cause your
          system to become totally broken and you may not even be able to
          use `dpkg' to put things back, so only do so if you know what you
          are doing.  Systems with only the `required' packages are
          probably unusable, but they do have enough functionality to allow
          the sysadmin to boot and install more software.

     `important'
          Important programs, including those which one would expect to
          find on any Unix-like system.  If the expectation is that an
          experienced Unix person who found it missing would say "What on
          earth is going on, where is `foo'?", it must be an `important'
          package.[1] Other packages without which the system will not run
          well or be usable must also have priority `important'.  This does
          _not_ include Emacs, the X Window System, TeX or any other large
          applications.  The `important' packages are just a bare minimum
          of commonly-expected and necessary tools.

     `standard'
          These packages provide a reasonably small but not too limited
          character-mode system.  This is what will be installed by default
          if the user doesn't select anything else.  It doesn't include
          many large applications.

     `optional'
          (In a sense everything that isn't required is optional, but
          that's not what is meant here.) This is all the software that you
          might reasonably want to install if you didn't know what it was
          and don't have specialized requirements.  This is a much larger
          system and includes the X Window System, a full TeX distribution,
          and many applications.  Note that optional packages should not
          conflict with each other.

     `extra'
          This contains all packages that conflict with others with
          required, important, standard or optional priorities, or are only
          likely to be useful if you already know what they are or have
          specialized requirements.

     Packages must not depend on packages with lower priority values
     (excluding build-time dependencies).  In order to ensure this, the
     priorities of one or more packages may need to be adjusted.

[1]  This is an important criterion because we are trying to produce,
     amongst other things, a free Unix.


-------------------------------------------------------------------------------


3. Binary packages
------------------

     The Ubuntu distribution is based on the Debian package management
     system, called `dpkg'.  Thus, all packages in the Ubuntu distribution
     must be provided in the `.deb' file format.


3.1. The package name
---------------------

     Every package must have a name that's unique within the Ubuntu
     archive.

     The package name is included in the control field `Package', the
     format of which is described in Section 5.6.7, ``Package''.  The
     package name is also included as a part of the file name of the `.deb'
     file.


3.2. The version of a package
-----------------------------

     Every package has a version number recorded in its `Version' control
     file field, described in Section 5.6.12, ``Version''.

     The package management system imposes an ordering on version numbers,
     so that it can tell whether packages are being up- or downgraded and
     so that package system front end applications can tell whether a
     package it finds available is newer than the one installed on the
     system.  The version number format has the most significant parts (as
     far as comparison is concerned) at the beginning.

     If an upstream package has problematic version numbers they should be
     converted to a sane form for use in the `Version' field.

3.2.1. Version numbers based on dates
-------------------------------------

     In general, Ubuntu packages should use the same version numbers as the
     upstream sources.