Re: (LONG) Correct non-US solution
(I'm coming in late here, but I'll make some remarks anyway. If others made them as well just ignore me). A couple of remarks: * we don't control how mirrors mirror our archives, and we don't want to create a situation where mirrors need special tools and/or scripts. (okay, we probably could create a `safe' symlink-tree or so, but that's ugly). * the same discussion was held earlier as while. One of the points made was that you don't want to list the countries in the package, but the reasons why a package is restricted (ie RSA, LZW, mp3) and have a seperately maintained list to map those to countries. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpVBKJ48fD6K.pgp Description: PGP signature
Re: (LONG) Correct non-US solution
On Sun, 23 May 1999, Wichert Akkerman wrote: A couple of remarks: * we don't control how mirrors mirror our archives, and we don't want to create a situation where mirrors need special tools and/or scripts. According to previous posts, our top tier mirrors already run special software to mirror us, and under the new scheme those are the only ones that would need to run our custom stuff anyways. was that you don't want to list the countries in the package, but the reasons why a package is restricted (ie RSA, LZW, mp3) and have a seperately maintained list to map those to countries. Yes, that is undoubtedly a superior solution, but a lot more work. It relies on a few people to make up these lists and maintain them. The new way would distribute the load over all our developers, as it would distribute load over our mirrors. a) the file mapping is much more complex to implement b) doesn't give a developer much control over his own package (ie, if your package suddenly became illegal somewhere for some reason that wasn't already listed, the developer could quickly respond, instead of yanking it from the distribution) Jonathan
Re: (LONG) Correct non-US solution
e.g. if i hear of a cool idea for a new and/or improved gadget, i can build one myself and use it whenever i like. In the US, you can be sued for patent infringement for doing that. I am not certain that it is so in all countries. Do you know with certainty that some countries make an exception for that kind of use? Either way, the program can't be considered free software in the countries where there are patents.
Re: (LONG) Correct non-US solution
On Sat, May 22, 1999 at 03:09:43AM -0400, Richard Stallman wrote: e.g. if i hear of a cool idea for a new and/or improved gadget, i can build one myself and use it whenever i like. In the US, you can be sued for patent infringement for doing that. I am not certain that it is so in all countries. Do you know with certainty that some countries make an exception for that kind of use? In Sweden, patent law restricts only professional use, not personal use. I imagine that there are other countries with the same sort of law. This still means the software isn't free, though, because I can only use it for certain, limited purposes, but it is at least better than not being able to (legally) use it at all. -- Patrik Nordebo [EMAIL PROTECTED] http://a39.ryd.student.liu.se/~isildur Phone: +46-(0)13-4739006 snail mail: Bjornkarrsgatan 11C10, 584 36 Linkoping, Sweden
Re: (LONG) Correct non-US solution
On Thu, May 20, 1999 at 10:53:19AM +1000, Craig Sanders wrote: On Wed, May 19, 1999 at 07:51:31PM -0400, Richard Stallman wrote: Also, I am not sure it is useful to distinguish between use-restricted and patent-restricted, given that the consequences would be the same. the reason i suggested having a patent-restriced category is that patents don't necessarily prevent individuals from using the patented technology in their own home, they only prevent the commercial exploitation of that patented technology. e.g. if i hear of a cool idea for a new and/or improved gadget, i can build one myself and use it whenever i like. i can even tell my friends how to do the same. what i can't do, however, is sell it without licensing the technology from the patent holder. No, you can't. If you use it - home, bathtub, car, lab, product - you are subject to patent license whims. The 'fair use' you describe above is for copyright, not patent. IANAL, and would welcome chapter and verse showing me wrong, but this is my understanding. ...jfree
Re: (LONG) Correct non-US solution
As a practical matter, I don't think any countries restrict importation of software that might be in Debian, unless they also restrict its use. The only such circumstances I can think of have to do with pornography; in the UK, for example, customs will seize things that are on sale openly in London. But I don't expect there to be anything in the Debian main collection that would be objectionable on those grounds. Both in the case of encryption and in the case of patents, the countries that restrict import also restrict use. Also, I am not sure it is useful to distinguish between use-restricted and patent-restricted, given that the consequences would be the same. However, making the extra distinctions won't cause any harm if people want to do that.
Re: (LONG) Correct non-US solution
On Wed, May 19, 1999 at 07:51:31PM -0400, Richard Stallman wrote: Also, I am not sure it is useful to distinguish between use-restricted and patent-restricted, given that the consequences would be the same. the reason i suggested having a patent-restriced category is that patents don't necessarily prevent individuals from using the patented technology in their own home, they only prevent the commercial exploitation of that patented technology. e.g. if i hear of a cool idea for a new and/or improved gadget, i can build one myself and use it whenever i like. i can even tell my friends how to do the same. what i can't do, however, is sell it without licensing the technology from the patent holder. what is the difference between sharing the plans for a gadget, and sharing the source code for a program? in other words, it's debatable whether a software patent entitles a company to sue an individual for compiling and using free source code that implements their patented algorithms. craig -- craig sanders
Re: (LONG) Correct non-US solution
On Tue, 18 May 1999, Joey Hess wrote: Well, we've established that no site in the US will carry the crypto stuff. So what if I'm in the US and want to get non-US stuff? Since non-us has disappeared into the distribution, I can't add a line to apt pointing to non-us. So what am I supposed to so? Right in the first draft of the proposal, in the section about modifications to apt, it said: apt will attempt to download the package from the sites in sources.list, and if those fail, will try all the sites in master.list until one is found which hosts the .deb. The master.list file contains all official debian mirrors, in a format that was already outlined. Jonathan
Re: (LONG) Correct non-US solution
On Mon, May 17, 1999 at 12:40:44AM -0700, Jonathan Walther wrote: Package: ssh Export-Restricted: United States Import-Restricted: Russia, France i haven't had time to read or think about your entire proposal yet, but my initial reaction to this is that using country names is wrong, it should instead use the ISO country codes. i.e. us, ru, fr instead of United States, Russia, France. second reaction is that Use-Restricted and Patent-Restriced may be useful fields as well. some countries may not care about import, but do restrict usage, and some may not restrict import or export but patents exist to restrict usage or sale. craig -- craig sanders
Re: (LONG) Correct non-US solution
Debian is about freedom, specifically freedom of software. Being seen as examplary citizens can only help our cause. We have a sterling reputation for high standards. I agree with you on using the two letter iso country codes. However, I don't see a need for the extra fields Use-Restricted and Patent-Restricted. If a country limits the freedom of the software, then there is no point in importing it. Debian is not set up to cater to a million local regulations, we only want to help get our software on as many mirrors as can legally take it without opening ourselves up to wrath from above. The only reason for bothering with respecting import restrictions is for people who WISH to have boxes compliant with local law, no matter how much that compromises their personal freedom. The case may easily be that violation of the law could limit their freedom even further. How about government funded agencies who don't dare do one thing out of line for fear of losing their government funding? This puts us one step towards being usable and friendly for everyone. If we demonstrably have a solution to that, that puts us far ahead of every other linux distribution in MANY countries out there. Cheers Jonathan On Wed, 19 May 1999, Craig Sanders wrote: my initial reaction to this is that using country names is wrong, it should instead use the ISO country codes. i.e. us, ru, fr instead of United States, Russia, France. second reaction is that Use-Restricted and Patent-Restriced may be useful fields as well. some countries may not care about import, but do restrict usage, and some may not restrict import or export but patents exist to restrict usage or sale.
Re: (LONG) Correct non-US solution
On Tue, May 18, 1999 at 12:20:35PM +0100, Philip Hands wrote: Perhaps a better goal (although significantly more difficult) would be to design a system where we can have multiple symmetric masters, where you can upload to any of them, and the propagate packages amongst themselves. The Comprehensive TeX Archive Network (CTAN) is set up like this. The network consists of three hosts; uploads can go in any of them, and the files propagate to all of them. If we go with something like this, it would be instructive to study the CTAN setup. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Good Times are back again! http://www.iki.fi/gaia/zangelding/
Re: (LONG) Correct non-US solution
Antti-Juhani Kaijanaho writes (Re: (LONG) Correct non-US solution): On Tue, May 18, 1999 at 12:20:35PM +0100, Philip Hands wrote: Perhaps a better goal (although significantly more difficult) would be to design a system where we can have multiple symmetric masters, where you can upload to any of them, and the propagate packages amongst themselves. The Comprehensive TeX Archive Network (CTAN) is set up like this. The network consists of three hosts; uploads can go in any of them, and the files propagate to all of them. If we go with something like this, it would be instructive to study the CTAN setup. If necessary, I could talk to the CTAN folks and find out what they do behind the scenes... I've been doing a little bit of CTAN work (license issue) for a while now and converse fairly regularly with some of the CTAN maintainers. Note that CTAN recently has split their archive into main and non-free trees based upon licenses like we do. :) -- Richard W Kaszeta PhD. Candidate and Sysadmin [EMAIL PROTECTED] University of MN, ME Dept http://www.menet.umn.edu/~kaszeta
Re: (LONG) Correct non-US solution
On Wed, May 19, 1999 at 08:26:21AM -0500, Richard Kaszeta wrote: Note that CTAN recently has split their archive into main and non-free trees based upon licenses like we do. :) Yes, I've noticed it. What criteria do they use? The DFSG? The OSD? A YAFSG (yet another free software guideline)? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Good Times are back again! http://www.iki.fi/gaia/zangelding/
Re: (LONG) Correct non-US solution
Jonathan Walther wrote: Thus, server foo in France will not download the ssh package, but if the maintainer of ssh always uploads to the Incoming on a canada.debian.org, all mirrors that are allowed to will hit every server in the master.list that might have the package until it finds the one (canada.debian.org) that has it. Well what do you do about a mirror in the US that can import software but cannot export it? You either have to somehow validate all downloads of that software from the mirror are from people in the US, or you leave the mirror open to downloads from everywhere and thus breaking the law. -- see shy jo
Re: (LONG) Correct non-US solution
On Mon, 17 May 1999, Joey Hess wrote: Well what do you do about a mirror in the US that can import software but cannot export it? You either have to somehow validate all downloads of that software from the mirror are from people in the US, or you leave the mirror open to downloads from everywhere and thus breaking the law. I would think that if a mirror couldn't export a peice of software, it just wouldn't host it. The logistics of figuring out which country every IP is in are... daunting, to say the least. Jonathan
Re: (LONG) Correct non-US solution
Jonathan Walther wrote: I would think that if a mirror couldn't export a peice of software, it just wouldn't host it. The logistics of figuring out which country every IP is in are... daunting, to say the least. Well then your proposal doesn't do away with the non-us division. Every county except the few like the netherlands is going to be in essentially the same situation they are in now. -- see shy jo
Re: (LONG) Correct non-US solution
How do you figure Joey? Some countries will let us distribute patented stuff... other countries will let us distribute crypto stuff... The scheme proposed does do away with non-US, by making its original functionality so fine-grained that it disappears into the rest of the distribution. Or am I missing something here? And, according to comments I've heard from others, you are wrong. Most countries outside the US *do* allow export of crypto, so our situation would change pretty dramatically. suddenly a lot more currently non-US packages would be on a lot more mirrors, and thus harder to stamp out, and the laod would be much better distributed among our mirrors. Again, am I missing something here? Jonathan On Mon, 17 May 1999, Joey Hess wrote: Well then your proposal doesn't do away with the non-us division. Every county except the few like the netherlands is going to be in essentially the same situation they are in now.
Re: (LONG) Correct non-US solution
Package: ssh Export-Restricted: United States Import-Restricted: Russia, France ssh is a bad example, since it is non-free software everywhere in the world. It is restricted by its developers. Version 2 is even more restricted than version 1. However, the general idea seems like a reasonable one, as long as we make the checking *optional*. We want to make it easy for people to avoid patented software; but we should not take this so far that we become patent enforcers! Changes to apt and dpkg: --- Respect the presence or absence of /etc/LEGAL. If a selected package is Import-Restricted, it won't download or install it unless /etc/LEGAL is missing. I think that is going too far--it should ask the user what to do. If a person wants to risk using encryption in Russia, or feels that RSADSI is not likely to sue him for using RSA in the US, he or she should be able to say go ahead. I see a possible discrepancy (or else maybe I have misunderstood something) in these two statements: Export-Restricted determines which mirrors will accept the package for redistribution. Change to dupload and dinstall: --- If the maintainer of a package is in one of the Export-Restricted countries, refuses upload the package. No package should ever be maintained by someone in a country from which it can't be exported--that would be shooting ourselves in the foot. If this is properly checked when packages are accepted, then there should be no need to check the maintainer's country for upload. So the Export-Restricted field that should be checked is the one on the server. The server should not accept a package which it cannot export.
Re: (LONG) Correct non-US solution
Jonathan Walther [EMAIL PROTECTED] writes: How do you figure Joey? Some countries will let us distribute patented stuff... other countries will let us distribute crypto stuff... The scheme proposed does do away with non-US, by making its original functionality so fine-grained that it disappears into the rest of the distribution. Or am I missing something here? And, according to comments I've heard from others, you are wrong. Most countries outside the US *do* allow export of crypto, so our situation would change pretty dramatically. suddenly a lot more currently non-US packages would be on a lot more mirrors, and thus harder to stamp out, and the laod would be much better distributed among our mirrors. Again, am I missing something here? I can think of one thing that seems to have been missed: To where do we upload packages ? Are we going to end up with a situation where we have to have the uploads to the Cayman isles, or some such ? Or do we end up with a separate site for non-US type stuff, with the rest going to master ? It seems that we'll just get back to the situation we already have. Perhaps a better goal (although significantly more difficult) would be to design a system where we can have multiple symmetric masters, where you can upload to any of them, and the propagate packages amongst themselves. Cheers, Phil.
Re: (LONG) Correct non-US solution
On 18 May 1999, Philip Hands wrote: Perhaps a better goal (although significantly more difficult) would be to design a system where we can have multiple symmetric masters, where you can upload to any of them, and the propagate packages amongst themselves. Perhaps I didn't explain it clearly enough, but that is what I intended. However, instead of having symmetrical masters, I intended for all .changes files etc to get posted to master, with the .deb, .diff.gz and .orig.tar.gz being sent to any of the other upload sites, whichever one is legal. That way master can generate the Packages list, then our sync script would run on each top-tier mirror and seek out the packages. I was hoping each of our top-tiers could double as potential upload sites for developers. This method is secure, for reasons I already outlined in the original proposal. Jonathan
Re: (LONG) Correct non-US solution
Jonathan Walther wrote: How do you figure Joey? Some countries will let us distribute patented stuff... other countries will let us distribute crypto stuff... The scheme proposed does do away with non-US, by making its original functionality so fine-grained that it disappears into the rest of the distribution. Or am I missing something here? Well, we've established that no site in the US will carry the crypto stuff. So what if I'm in the US and want to get non-US stuff? Since non-us has disappeared into the distribution, I can't add a line to apt pointing to non-us. So what am I supposed to so? -- see shy jo
(LONG) Correct non-US solution
We are here to make software free. We can make it free, or we can drive thorns into our flesh trying to change the minds of uncaring governments. Our current situation with the non-US section of our distribution is akin to a form of fruitless martyrdom. Its painful to us, but doesn't really affect the policy of any governments involved. I would like to propose a solution that makes the distribution of export/import restricted software both painless to us, and as hard as possible to any collection of entitites to stamp out. And, for citizens who wish to respect the law of their country, I propose that the same measures will add simple, automatic facilities for keeping their systems legal, configurable dynamically. The proposal calls for the folding of non-US into the other three distributions so it disappears without a trace, like the morning dew in the afternoon sun. The changes that would make this feasible follow: Changes to a packages control file: -- Two new fields are added to the control file, Import-Restricted and Export-Restricted. These fields take a comma delimited list of countries. For example, Package: ssh Export-Restricted: United States Import-Restricted: Russia, France Import-Restricted lists countries where its illegal to install the software. The user can do a `touch /etc/LEGAL` to make apt respect Import-Restricted. Someone might also want to write a legalize program to deinstall illegal software should the feds come a'knocking. `rm /etc/LEGAL` would allow full access again. Export-Restricted determines which mirrors will accept the package for redistribution. Changes to /etc --- We add a file called country which contains the name of the country the box is in. This lets the package software keep the system conformant to the laws for the particular country its in. It also will allow a maintainer to easily see if a configuration works for a particular country in conjunction with the legalize program. As mentioned before, there is the LEGAL file, which makes the package software respect the laws of the country its in if its present, and if absent, the software ignores the Import-Restricted field. Change to dupload and dinstall: --- If the maintainer of a package is in one of the Export-Restricted countries, refuses upload the package. If the server specified is in one of the Import-Restricted countries, refuses to upload the package. A package may be uploaded to any of the official servers that allow it, by a maintainer, however the .dsc and .changes file will be uploaded to one central server (probably master.debian.org) automatically by the script, from which the Packages files will be generated and Mirrored. Dinstall will be modified to account for the fact that a package may be on another server, but the security implications of having an untrusted server are minimal, given we have md5sums and a rejected Package won't show up in the Packages file, thus being invisible, should a mirror maintainer decide to unilaterally move something from Incoming to its appropriate directory themselves. The mirroring software will be modified to check its current packages against the Packages list, and hunt down and download any package it is allowed to (which it is not Export or Import restricted from) that has changed. Thus, server foo in France will not download the ssh package, but if the maintainer of ssh always uploads to the Incoming on a canada.debian.org, all mirrors that are allowed to will hit every server in the master.list that might have the package until it finds the one (canada.debian.org) that has it. Changes to apt and dpkg: --- Respect the presence or absence of /etc/LEGAL. If a selected package is Import-Restricted, it won't download or install it unless /etc/LEGAL is missing. Packages files: are the same on every mirror, are NOT generated locally. If a package isn't found on one server, apt automatically hunts for it first, on servers in sources.list, then on servers in master.list /etc/apt/sources.list will now just be taken as hints: downloads and Packages updates will be attempted from the sites in the file, but failure of those servers is no longer fatal; downloads will be attempted from master.list /usr/share/apt/master.list will contain a list of all official debian mirrors in the same format as sources.list, with the exception that the name of the country the server is in will be prepended to each line. However, the meaning of the entries are slightly different; it is a what I provide and where to find it entry, as opposed to a look here for this entry. This: canada deb http://http.ca.debian.org/debian bo main is the entry for a Canadian server that just provides the main section of the bo release. This: france deb http://http.fr.debian.org/t/debian unstable main contrib non-free france deb http://http.fr.debian.org/gin/borsch stable main contrib non-free
Re: (LONG) Correct non-US solution
Jonathan Walther wrote: Mirroring Software: --- Im not sure what software is currently used for synchronizing mirrors, however, it will need to take the above policies into account. Hopefully our additions to the policy will make it so much easier to stay legal and avoid worries about legalities that the maintainers will wish to use such software. Here's the problem. We have no control over what software most mirror sites run, and most of them run a standard mirroring program that handles all their mirrors. They will not want to make an exception for Debian. You will have to find a scheme that can be handled by generic tools. Richard Braakman
Re: (LONG) Correct non-US solution
On Mon, May 17, 1999 at 12:41:04AM -0700, Jonathan Walther wrote: For example, Package: ssh Export-Restricted: United States Import-Restricted: Russia, France Can I suggest that we use ISO country codes instead? The user can do a `touch /etc/LEGAL` to make apt respect Import-Restricted. It should be the other way around surely, otherwise Debian's default install would be illegal. There's also the question of whether an official Debian should provide tools for breaking the law. We add a file called country which contains the name of the country the This would be useful for other reasons too - default languages, timezones etc. could be guessed from this (as mentioned by someone else on this list). There have been concerns about the mirroring implications raised, and there may be some dependency problems that arise from packages suddenly disappearing but this is an area worth consideration (IMHO) Cheers, Ben -- +-Ben Bell - A song, a perl script and the occasional silly sig.-+ /// email: [EMAIL PROTECTED]www: http://www.deus.net/~bjb/ bjb Snail: 20 Guildford Road West, Farnborough, GU14 6PU \_/Open Source - It's easier to create than to destroy.
Re: (LONG) Correct non-US solution
Richard Braakman [EMAIL PROTECTED] writes: Jonathan Walther wrote: Mirroring Software: --- Im not sure what software is currently used for synchronizing mirrors, however, it will need to take the above policies into account. Hopefully our additions to the policy will make it so much easier to stay legal and avoid worries about legalities that the maintainers will wish to use such software. Here's the problem. We have no control over what software most mirror sites run, and most of them run a standard mirroring program that handles all their mirrors. They will not want to make an exception for Debian. You will have to find a scheme that can be handled by generic tools. Well, nearly every mirroring script I have ever seen takes a list of files to exclude. Since every mirror would have a set of the metadata for all packages, they could generate the list of excluded packages which they should not get. So a script which took the package metadata, and the ISO country code would be able to generate a script for mirrors in any given country. These could be put into a well known location on the master server and all servers would mirror them just like another file. Then at mirror time, the exclusion list appropriate to their country would be given to their mirroring software. Only one mirror per country (the root mirror prefereably) need do this, as the rest could just mirror them straight up like they always have. Am I missing anything? -- Craig Brozefsky[EMAIL PROTECTED] Less matter, more form! - Bruno Schulz ignazz, I am truly korrupted by yore sinful tzourceware. -jb The Osmonds! You are all Osmonds!! Throwing up on a freeway at dawn!!!
Re: (LONG) Correct non-US solution
Hi, Jonathan == Jonathan Walther [EMAIL PROTECTED] writes: Jonathan Changes to a packages control file: Jonathan -- Two new fields are added Jonathan to the control file, Import-Restricted and Jonathan Export-Restricted. These fields take a comma delimited Jonathan list of countries. Jonathan For example, Jonathan Package: ssh Jonathan Export-Restricted: United States Jonathan Import-Restricted: Russia, France I like the idea, but I am concerned about a) Potential liability placed on the maintainer (is he liable for being wrong or not having the complete list of countries in eithe category? b) the additional burden placed on developers (I have no idea what laws strange countries may have about even what is, to me, innocuous pieces of software). I think we may need a repository (which may just be a file) that people contribute to, which would be a resource that developers can look at. Since more hands are doing the work, there are fewer chances of errors. On the other hand that may make the project, or at least all contributors, partly liable as well. manoj -- So this is it. We're going to die. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
