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
Attachment:
signature.asc
Description: OpenPGP digital signature