On Sun, Nov 15, 1998 at 04:17:53PM -0500, Mitch Blevins wrote: > It seems that at present, the way packages are organized (having non-us) > is a very US-centric way of doing things. There are practical reasons > for this (US-based CD distribution, etc). <a very good idea - removed for length reasons :) > > > Maybe we should hash out a technical solution to this, then move the > discussion to debian-policy. > > -Mitch An alternate idea would be to provide a seperate file, similar to the package files, that lists distribution restrictions. ie. it would contain lines such as '"United States of America" main/binary-i386/utils/gpg', which specify which mirrors cannot download this software, thus preventing any crypto software from being put onto an american mirror. Ok, this will need a bit of working to make it functional, but I think the idea is ok. Heres some of the additional things that would be required: - Mirrors would have to be set up to enforce the restrictions specified by the restrictions file. - A disclaimer will need to be put onto the ftp servers .welcome announcing that the distribution contains crytographic software is subject to restrictions as per the restrictions file. - An alternate upload point will need to be arranged so that packages don't _have_ to be uploaded onto a US server. Something similar to the way chiark works, but checks restrictions first... - Apt, etc, etc would need to also check this file to see if it is legal to download (not a problem at the moment, but maybe some country will oneday ban importing crypto). Apt will also have to be intelligent enough to fetch files that arn't on mirror in your local country (ie US) from another mirror (ie. specify a primary download mirror, and a secondary for any packages unavailable on the first). That way packages could depend on crypto software. Also, if a package cannot be downloaded because of import restrictions the user should be notified and dependant packages not installed. - When installing packages subject to restrictions the user should be notified so that they don't unwittingly re-export them. - Some way of updating the restrictions file will need to be considered. The only advantage I can see for this over the other method is that it will be plainly obvious what the restrictions are (rather than being specified by a virtual-package), plus it can deal with source code. Of course, this is only a suggested way of looking at the problem, no a full solution - but I think these kind of approaches is how debian should be doing things. Lets face it, Debian is an international project, and while we _must_ adhere to the laws of the various countries we provide software for, we should should still try and produce the best, well equipt distribution that we can, and deal with the import/export laws later. Chris -- ---------------------------------------------------------------------- REALITY.SYS corrupted: Reboot universe? (Y/N/Q) ....Debian GNU/Linux ---------------------------------------------------------------------- Reply with subject 'request key' for PGP public key. KeyID 0xA9E087D5
Attachment:
pgpMYZawAlIH3.pgp
Description: PGP signature