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

Bug#138541: ITP: debian-sanitize (was Re: inappropriate racist and other offensive material)

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

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

 - 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.


Reply to: