[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[bmc@it.larc.nasa.gov: Proposal]

-- 
-----    -- - -------- --------- ----  -------  -----  - - ---   --------
Ben Collins <b.m.collins@larc.nasa.gov>                  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc.                 bcollins@debian.org
------ -- ----- - - -------   ------- -- The Choice of the GNU Generation
--- Begin Message --- 
This is a proposal for a better system to handle 'restricted' packages
(currently non-US). I sent this to here so as to avoid the nonsense that
sometimes intermixes on the developers list with legitimate posts. If it
is recieved well then I planned to forward it to the dpkg and ftp lists as
well for consideration.

-- 
-----    -- - -------- --------- ----  -------  -----  - - ---   --------
Ben Collins <b.m.collins@larc.nasa.gov>                  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc.                 bcollins@debian.org
------ -- ----- - - -------   ------- -- The Choice of the GNU Generation


Proposal for Integrating Restricted-Distribution Packages into Debian
(v0.1.0 initial release) by Ben Collins <bcollins@debian.org>

Foreword: This proposal is aimed at unifying the restricted software
packages into the main Debian distribution in a simplistic enough way as
to not hender Users from obtaining or making use of Debian, but robust
enough to handle future problems of this nature in a cohesive manner. It
is NOT the purpose of this proposal to argue, defend, or attack current
import and export restrictions imposed by some countries.

  Currently the debian ftp servers are setup with main distributions
called stable/frozen/unstable. In these directories are the
main/contrib/non-free sections of the distributions. Aside from this we
have a non-US server which houses the packages that for one reason or
another are faced with import/export restrictions and therfore have been
seperated from the main distribution regardless of the DFSG compliance.
They are layed out in a flat directory structure (no subtrees such as
devel, web, x11). Since there seems to be a growing unarguable consensus
that these packages should have a means of being included in the main
distribution the same way that other packages are, calls for a lot of
restructuring in the way that packages are handled not only on the ftp
sites but at a package level so that dpkg/apt and other package handling
systems can cope with these restrictions on a package by package basis.
The following proposal is broken down into a general overview and then
sites specific changes that will need to occur in each of the related
areas of Debian's policy's and package handling systems.

Definition of a restricted package:
  A restricted package is one that, because of certain laws, treaties, or
other reasons, does not allow it to be distributed across international
boundaries freely. This may be because of crypto laws (ie. export
restrictions in the US, other countries have import restrictions) or
because of software patents that makes its use illegal.

  These packages can not be in a freely distributed system since it closes
the door to usage of this system by Users in certain countries. Since our
goal is to support every User possible - with in reason - with free
software then it is a must that we have a simple means for which they can
obtain a Debain distribution that is not hendered by any import/export
restrictions. On the same token, Users in countries that have no such
restrictions, should be able to easily obtain a Debian distribution with
all packages included in a cohesive recognizable layout. The Users should
not see any difference in the packaging system from the seperate
distributions other then one has extra packages that the other does not
(ie. There should be no packages in the non-restricted system that depend
on packages in the restricted system).

  If a package has dependencies on restricted packages then that package
should also be in the restricted system, since its space and usage are
only relevant there. A User should not select a package only to find that
it can not be installed unless they obtain packages which may or may not
be illegal for them to use or obtain. This type of situation makes the
system look broke and incomplete, and should be generally considered a bad
thing.

  Currently there is no way to tell if a package on it's own is a
restricted package or not (without extracting the copyright or similar).
This is why there is a need for specific standards in the control file to
define aspects of a restricted package. The user should be able to look at
the 'dpkg --info package.deb' and get basic output as to the restrictions
that may apply. The packaging system should also be able to recognize this
and alert the user as to possible misuse of the package and what
restrictions the package is under (ie. Patent infringement, crypto) and
possibly what countries it may effect.

Details on the packaging format:
  The new packaging format should not require maintainers of
non-restricted packages to change their control files. A new control file
tag could be added (and would require dpkg and friends to add some code to
handle it) in a form similar to 'Restrictions:'. If the line is missing,
the package should be considered non-restricted.

  The syntax would then follow a set of standards as to the nature of the
restriction, for example 'crypto', 'sw-patent-*'. These standard
restriction types would be agreed upon by the developers and any new
additions would have to be proposed and ratified by a consensus. This will
reduce the amount of coding required by the package systems to maintain
the standards. Each standard would then be given a brief User
understandable statement such as "This software contains encryption
methods that may fall under restrictions of use or distribution in your
country" to be contained in the package system (not the package itself).

  At the package maintainers discretion, they could also add extra
information to clarify where this(these) restriction(s) MAY be effective.
A format similar to dependency versions could be used. For example if a
package was restricted by a patent on RSA that only affects US Users, they
would have a line such as:

	Package: ssh-free
	Restrictions: sw-patent-rsa (US)

Meaning that the restriction is only in affect in the United States. While
if there were a package that was only legally usable in one country (weird
but possible) it would use the lines below:

	Package: weird-obscure-software
	Restrictions: sw-patent-something (ALL,!AU)

Meaning that the restriction applies to every country except Australia.
The two formats need not be combined since the keyword 'ALL' could be used
to set a baseline for countries not listed (ie. ALL=everyone is restricted
by default, !ALL=everyone is not restricted be default). If no countries
are appended, the package system should assume 'ALL' otherwise it should
assume !ALL unless it is specified in the restriction line (since the
maintaner has taken it upon himself to specify the restrictions). These
restrictions can also be chained if there are several involved:

	Package: ssh
	Restrictions: sw-patent-rsa (US), crypto

  The country codes should not be considered mandatory but the maintainer
should be encouraged to review his restricted package as much as possible
to give the Users as much info as possible.

  This system in no way should affect the package systems ablity to
install such restricted packages, as it should be left up to the User as
to whether or not to heed these notices. The package system should only
make the User aware of such restrictions and should not be depended upon
for enforcing the restrictions.

The site layout:
  The distribution sites should then be setup to produce a simple layout
that takes advantage of this control information. The standard
distribution would remain the same. However, the ftp site scripts that
parse the control files and places the packages into the apporpriate
directories, would place all restricted packages into a similar layout as
the standard distribution accept in an apporpriate directory. For example,
our current unstable would be listed as such:

dists/
 potato/
  |\main/
  |   Packages
  |   Packages.gz
  |   devel/
  |   ...
  |\contrib/
  |   Packages
  |   Packages.gz
  |   devel/
  |   ...
   \non-free/
      Packages
      Packages.gz
      devel/
      ...
 potato-r/
  |\main/
  |   Packages-r
  |   Packages-r.gz
  |   devel/
  |   ...
  |\contrib/
  |   Packages-r
  |   Packages-r.gz
  |   devel/
  |   ...
   \non-free/
      Packages-r
      Packages-r.gz
      devel/
      ...
 unstable@ -> potato
 unstable-r@ -> potato-r

Notice that other than the '-r' the layouts are identical as far as
subtrees. Restricted packages would fall under the same DFSG compliance
policies as other packages. This layout would benefit mirror sites in that
they will be able to mirror only the non-restrcited system if desired.
Also, sites that wish to mirror the entire restricted+standard system
could easily do so and even overlay the two systems to make one complete
distribution. Users wishing to download the distribution would also be met
with an easier task, and it would look similar to this:

debian> cd pub/dists/potato
debian> mget main contrib non-free
.....
debian> cd ../potato-r
debian> mget main contrib non-free
.....

Now the User has a complete distribution which includes the standard and
restricted packages and would have nothing further to do as far as dealing
with the restricted packages since they would be handled the same as the
standard.

The package system requirements:
  Obviously the package systems would have to be modified to incorporate
this new setup. Primarily this means recognizing the 'Restrictions:' field
in the control files and having a current database of the standard types
of restrictions and be able to notify the User in laymens terms what the
restrictions are based on that information in the control file. This
should use the one-liner described above then also include info based on
the country restrictions if specified in the package. If the package
contains a non-standard restriction, the packaging software should be able
to deal with the situation without choking. It would also be a good idea
to include a disclaimer concerning restricted packages in general,
releasing the package management tool from liability for it's use in
installing the package.
  Package management software such as dselect and apt will need to
recognize the 'Packages-r' file so as to recognize the CD and ftp layouts
proposed, as well as the 'Restrictions:' tag (which should be included in
the Packages-r file with the current info).

The ftp sites:
  Utilizing Debian's current resources there will still be the need for a
non-restricted server to be able to distribute the restricted packages
(currently nonus.debian.org). It would be a better setup if Debian's main
package upload server were in the same situation, but that is not the
topic of this porposal, only a future consideration. This would allow for
a completely nuetral location to distribute the entire system, but has
it's own draw backs that are better suited for a different discussion. It
is the hopes of the author that this not be the deciding factor in this
proposal since a packaging system such as this would still need to be
implemented to suit the long term and short term goals of the Debian
project.
  The software that handles carrying the uploaded packages to the dists
directories will need to be modified to recognize the restricted options.
It should place all packages with no 'Restrictions:' tag or a
'Restrictions: no' line into the standard distribution. ANY other
situations should be placed into the restricted distribution. The scripts
should not assume to know anymore than that about the validity of the
packages restrictions. It is left to the maintainers as a whole to check
and file bug reports on any package that does not have a proper
'Restrictions:' line (ones with non-standard restriction codes, ones with
malfored 'Restrictions:' tags, and ones that should be restricted, but do
not have the required line).
  Eventually for the sake of continuity, the 'Restrictions:' tag may need
to be considered mandatory so as to force maintainers to review the
restrictions that may fall on their packages. Initally this will not be
possible though.

CD distributions:
  This proposed system will have a great affect on how the CD's are
distributed. Foremost there will always need to be a standard CD with none
of restricted packages since most CD vendors have no desire to tackle
legal issues concerning patents and export restrictions. Debian should
make it a primary goal to insure that CD vendors will have no problems
distributing a complete and usable CD without worry of these restrictions.
  Other vendors who are not susceptible to the restrictions could then
create CD's with the merged standard/restricted packages together in one
CD that is distributable to where ever they legally can do so.

Please direct any contructive responses (critiscism or praises) to the list.

Attachment: pgp3tdV9ev2uZ.pgp
Description: PGP signature


--- End Message ---

Attachment: pgpt7x60voyb4.pgp
Description: PGP signature

Reply to: