Package: wnpp Severity: wishlist Various people have argued on debian-devel: > >>people, you have to understand that at a government facility all of our > >>traffic can be monitored and we can be held responsible for its content. I > >>like the Debian distribution alot but without a policy statement it simply > >>won't be worth the risk when I can use another distribution that is more > >>careful about its content. I also don't have the time to look at every > >>message that comes out of every package. As I said, the practical solution > >>is that I will rely on the social contract. > > > >The long term trend of this is that repressive governments will damage > >their countries by blocking access to technology and governments that are > >more liberal will benefit. > > I disagree. Governments are much like businesses in this respect - they > must establish some sort of standard of behavior within government > facilities just like a business generally wants a standard of behavior > followed by its employees (such as not surfing the web for porn at work). > A government can regulate itself without repressing the populace in > general. That's how it is in my country anyway :-)
Perhaps a compromise is needed - something that can provide people with a content filter of sorts, while allowing us to package whatever we feel we need to. So, I propose to upload debian-sanitize. The basic idea is that debian-sanitize will Conflict: with packages deemed to be offensive. With this package installed, therefore, offensive packages will not be installed without the admin's explicit consent. As an option, we could use some less absolute method of determining offense, perhaps something like vrms. Generating the list of offensive packages is, of course, the hard part. I propose we do this with the following process. It has the advantages of not (necessarily) promoting the biases of one developer or group. - Offensiveness will be determined by vote. All Debian developers will be allowed to vote on any or all binary packages in Debian. Votes will be registered by sending a GPG-signed E-mail to a particular address. Only one vote per package per developer will be allowed, but developers will be allowed to change or retract their votes. Voting will be optional, and neither the package nor its maintainer will solicit votes from anyone who has not already chosen to participate. - There will be a sense of a quorum; a certain number of votes must be tallied before any action would be taken. Besides "offensive" and "not offensive", developers may vote to abstain, which would count against the quorum but have no effect on the outcome. - After the quorum is reached, a majority (supermajority?) of "offensive" votes will result in the package being labeled offensive. Votes will be tallied on regular intervals, and packages generated from the vote results. The interval will be designed to allow new versions of the package to propagate through Debian. - The BTS entry for the package will be used for contesting classifications, notifying of changes in packages that might affect the vote, and so on. Depending on the results of these bugs, the package maintainer might contact voters or the entire project to alert developers about the situation with certain packages. Suggestions are welcome for a conflict resolution strategy that doesn't involve a General Resolution. - If an offensive package loses its offensive status, debian-sanitize will record its status as offensive previous to the current version in unstable. These records will be kept through one stable release cycle, and then dropped. (If offensiveness is recorded through Conflicts, then the package will gain a versioned conflict.) The package maintainer will reserve the right to modify such historical records as necessary. Packages that re-gain offensive status will have their historical records dropped. - If deemed appropriate, the DPL or his/her delegate may be accorded special status; for example, the DPL may have veto power, or have a vote that counts for more than others' votes. - Only packages in main would be eligible for voting; contrib and non-free are, in a sense, already considered disreputable by their status outside of main. - This maintainer, at least, would refrain from participation in the process to avoid a conflict of interest. I would probably implement this as a set of scripts and a database; at upload time, the scripts would produce a package for my manual approval, signature, and download. Comments?