Re: CoC policy for package contents

The Wanderer <[email protected]> Mon, 21 Jul 2025 08:29:03 -0400
Newsgroups	gmane.linux.debian.devel.vote
Organization	This space intentionally left blank.
Message-ID	<[email protected]>
On 2025-07-21 at 07:02, Wouter Verhelst wrote:

> When I wrote the code of conduct, I did not make it explicit that I
> thought it was not meant to apply to the contents of packages, but I
> think that anyone who reads it can understand that this is the case by
> the language used.
> 
> However, I think it's clear by now that we need a project-wide consensus
> on what policies apply to the contents of packages. This discussion
> keeps popping up, and we don't really have a good answer, since we never
> had a GR about the subject.

<snip>

> - The code of conduct applies to all program messages or documentation
>   texts that could be seen by a user in the normal use of a Debian
>   system, as well as to anything written by a Debian developer for the
>   Debian project. However, the following exceptions apply:
>   - Quotes by historic people when provided in appropriate context,
>   - Historic texts that are widely disemminated outside of Debian.
> 
> The main paragraph mentions "program messages (...) that could be seen
> by a user in the normal use of a Debian system", which does not
> encompass things like offensive messages in source code comments, or
> problematic variable names. This is not an accident; we are not the
> morality police, and I think it serves no purpose for us to try to patch
> out code of conduct-violating things in upstream source code. This is
> not because I think things like that are not a problem; rather, because
> I think it is a fight that should be fought upstream, not in Debian.
> Meanwhile, we should not remove packages from Debian just because
> there's one four-letter word directed at a particular person in a fringe
> comment in a barely-used part of the source code.
> 
> The first exception would allow for things like quotes from Mein Kampf
> in a fortunes-off package

I infer from the context here that you are intending that the fact of
being included in a package whose name marks it as containing
potentially-offensive material would be the "appropriate context"
referenced by the rule. (If that is not correct, then the next paragraph
or two would not be applicable.)

However, it would be easy to argue that when the Mein Kampf quotes are
presented by a call to 'fortune -o' or 'fortune -a', they are presented
without *any* context, and therefore are not being provided "in an
appropriate context".

I don't know if there's any useful way to clarify or otherwise improve
the wording here to address that type of possible mismatch in
interpretation, but I don't want to let the possibility go unconsidered.

> or in a package that generally discusses the atrocities committed by
> the Nazis and provides the quote for context; the second one would
> allow things like religious texts or medieval literature.

Would there be need to consider the definition of "historic" for these
purposes? Would that be a line that shifts forward as history
progresses? Is there even an important value in the "historic" qualifier
here, at least for the second exception, vs. letting that exception
cover widely-disseminated texts more broadly?

Speaking as someone who, while not a Debian Developer, has been anywhere
between disappointed and hurt by the entire move against the
fortunes*-off packages since its inception: on initial consideration, I
find this proposal heartening, and approve of this proposed set of
criteria (modulo potential tweaks) and the apparent thinking behind it.

> I considered adding an exception for "quotes that are in a package
> explicitly marked as not following this rule" to allow for fortunes-off
> packages containing anything the maintainer thinks is reasonable; but I
> am not sure that it would be welcomed by most people in our community,
> and also think that this opens the door to far too much, and I would
> rather have a rule that sets explicit exceptions for particular types of
> offensive contents like I did before. I would be open to adding more
> exceptions if they're reasonable, these are just the two that I can
> think of right now.

I can't think of any other exception categories offhand either.

However, I think it would be valuable and potentially important to
include some provision for adding more exceptions in the future without
needing to call another GR (with the attention from, and therefore
disruption to, the entire project which that would require).

I am not sure if there would be practical way of doing so, given that
the need for project approval would seem to be the key aspect of it all,
and that the way of determining whether the project approves of a change
*is* the GR - but having a potentially-incomplete set of exceptions
locked in behind such a heavy-weight barrier to changes seems, to my
eye, to be setting things up for friction in the future.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw
signature.asc (application/pgp-signature, 833 B)