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
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?
Reply to: