Bug#138541: marked as done (ITP: debian-sanitize (was Re: inappropriate racist and other offensive material))
Your message dated 17 Mar 2002 14:13:29 -0500
with message-id <1016392410.13575.19.camel@server1>
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 jeff@licquia.org Fri Mar 15 23:12:59 2002
Return-path: <jeff@licquia.org>
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 <submit@bugs.debian.org>; 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 <licquia@debian.org>
To: submit@bugs.debian.org
Subject: ITP: debian-sanitize (was Re: inappropriate racist and other offensive material)
Message-ID: <[🔎] 20020316051257.GA14263@licquia.org>
References: <20020313221046.GD17997@auctionwatch.com> <20020315165611.GG25412@netexpress.net> <20020315125732.B9074@icantbelieveimdoingthis.com> <20020316000859.937241ED06@lyta.coker.com.au> <3C92B520.8010401@softhome.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C92B520.8010401@softhome.net>
User-Agent: Mutt/1.3.27i
X-Debbugs-CC: debian-devel@lists.debian.org
Delivered-To: submit@bugs.debian.org
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 licquia@debian.org Sun Mar 17 13:13:33 2002
Return-path: <licquia@debian.org>
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 <licquia@debian.org>
To: debian-devel@lists.debian.org
Cc: 138541-done@bugs.debian.org
In-Reply-To: <20020317164824.GE20357@dodds.net>
References: <20020313221046.GD17997@auctionwatch.com>
<20020315165611.GG25412@netexpress.net>
<20020315125732.B9074@icantbelieveimdoingthis.com>
<20020316000859.937241ED06@lyta.coker.com.au>
<3C92B520.8010401@softhome.net> <[🔎] 20020316051257.GA14263@licquia.org>
<[🔎] 20020316203949.GA20357@dodds.net> <[🔎] 1016315540.2850.15.camel@server1>
<20020317054546.GC20357@dodds.net> <1016348821.2755.157.camel@server1>
<20020317164824.GE20357@dodds.net>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0.2
Date: 17 Mar 2002 14:13:29 -0500
Message-Id: <1016392410.13575.19.camel@server1>
Mime-Version: 1.0
Delivered-To: 138541-done@bugs.debian.org
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.
Reply to: