Your message dated 17 Mar 2002 14:13:29 -0500 with message-id <[EMAIL PROTECTED]> and subject line Bug#138541: ITP: debian-sanitize (was Re: inappropriate racist and other offensive material) has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -------------------------------------- Received: (at submit) by bugs.debian.org; 16 Mar 2002 05:12:59 +0000 >From [EMAIL PROTECTED] Fri Mar 15 23:12:59 2002 Return-path: <[EMAIL PROTECTED]> Received: from 12-222-16-44.client.insightbb.com (sentinel.licquia.org) [12.222.16.44] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 16m6V1-0006I1-00; Fri, 15 Mar 2002 23:12:59 -0600 Received: from server1.internal.licquia.org (server1.internal.licquia.org [192.168.50.3]) by sentinel.licquia.org (Postfix) with ESMTP id CE42D45245 for <[EMAIL PROTECTED]>; Sat, 16 Mar 2002 00:12:57 -0500 (EST) Received: by server1.internal.licquia.org (Postfix, from userid 1000) id 80CD92C1602; Sat, 16 Mar 2002 00:12:57 -0500 (EST) Date: Sat, 16 Mar 2002 00:12:57 -0500 From: Jeff Licquia <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: ITP: debian-sanitize (was Re: inappropriate racist and other offensive material) Message-ID: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <[EMAIL PROTECTED]> User-Agent: Mutt/1.3.27i X-Debbugs-CC: debian-devel@lists.debian.org Delivered-To: [EMAIL PROTECTED] 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? --------------------------------------- Received: (at 138541-done) by bugs.debian.org; 17 Mar 2002 19:13:33 +0000 >From [EMAIL PROTECTED] Sun Mar 17 13:13:33 2002 Return-path: <[EMAIL PROTECTED]> Received: from 12-222-16-44.client.insightbb.com (sentinel.licquia.org) [12.222.16.44] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 16mg61-0001Th-00; Sun, 17 Mar 2002 13:13:33 -0600 Received: from server1.internal.licquia.org (server1.internal.licquia.org [192.168.50.3]) by sentinel.licquia.org (Postfix) with ESMTP id C931045273; Sun, 17 Mar 2002 14:13:31 -0500 (EST) Received: by server1.internal.licquia.org (Postfix, from userid 1000) id 4DA682C1602; Sun, 17 Mar 2002 14:13:30 -0500 (EST) Subject: Re: Bug#138541: ITP: debian-sanitize (was Re: inappropriate racist and other offensive material) From: Jeff Licquia <[EMAIL PROTECTED]> To: debian-devel@lists.debian.org Cc: [EMAIL PROTECTED] In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 17 Mar 2002 14:13:29 -0500 Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 Delivered-To: [EMAIL PROTECTED] On Sun, 2002-03-17 at 11:48, Steve Langasek wrote: > On Sun, Mar 17, 2002 at 02:07:01AM -0500, Jeff Licquia wrote: > > > As I've mentioned in another message, I'm not interested in targeting > > swear words or mild stuff. I'm hoping that this will catch packages > > with highly offensive stuff, like the joke mentioned in this thread. > > The point of the voting system is that a package would have to contain > > something really bad before it would get onto a list like this. > > OTOH, you've also said that you will abandon the experiment if > developers don't get it, which implies that there's yet another set of > criteria being used to measure the success of the project, above and > beyond developer votes. True; this was mostly aimed at people who were proposing to try to censor emacs, perl, and the like because of some purported "moral offense" they take at those packages. I took that as an indication that some people who disagree with the entire concept were willing to exert effort in an attempt to make the package unusable for its primary purpose. To counter that, I was going to make the justification mandatory, and reserve the right to invalidate votes that don't have sufficient justification. I'm sure you can see the trap there - who am I to decide that justification isn't "sufficient"? More flame wars. > I'm always in favor of tools that give users more information, and this > tool definitely fits into this category -- /if done right/. A blacklist > that's assembled with respect to a publically available list of > measurable criteria would be useful to many people. Those who agree > with the criteria benefit from having a package they can use on their > systems. Those who agree with /some/ of the criteria benefit by having > a list available that they can check against. Those who believe that > censorship of the archive is wrong benefit from being able to placate > those who hold a different view. > > Using voting to determine membership in the blacklist, however, lends a > faux legitimacy to this package that it cannot and should not have. > There should be nothing morally authoritative about such a package. If > you say "these are the packages that contain homophobic jokes about > Hindu bitch-cows from the Bible belt", users can decide up front whether > to take it or leave it. If you say "these are the packages that are > allowed to exist in the Debian archive, but that 8 out of 10 Debian > developers believe are morally wrong", the only people you benefit are > those who are willing to subvert their own moral judgement in favor of > that of the Debian community -- and THAT offends /me/ more than anything > else that's been discussed in this thread so far. Well, the idea originally was that the vote would act as a first approximation, with a conflict resolution system of some kind to ward off abuse. I think, though, that the conflict resolution system is being forced to take more and more importance. The question of conflict resolution is one I've been punting on, hoping that someone would have a good idea about that. My own thoughts on the subject have all revolved around the Project having some level of buy-in; this obviously hasn't happened. > > Up to now, censorship has been a matter of the developer's choice, and > > is thus exposed to the wrath of offended users. Since users have no > > recourse other than by harassing the package maintainer, you end up with > > developers self-censoring (before the fact, even) to relieve or avoid > > the pressure. I don't want to take power over a package away from a > > developer, though; rather, I'd like to divert the users' wrath away, so > > the developer can make choices about the package that aren't based on > > relieving peer pressure. > > The types of users who would rather harrass developers to change their > packages than simply remove the package from their own systems aren't > going to go away under your plan. Unfortunately, I see your point here. Note that I'm withdrawing my proposal. I still agree with the general goal: provide a way for people to figure out what they might object to without having to audit the project or be unpleasantly surprised one day. It seems that my solution has too many holes to be workable.