This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
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


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEJCOqsZEc2qVC44pUBKk1jTQoMmsFAmh+Mo8ACgkQBKk1jTQo MmtHhBAAoBcyCVdtSlNQbHIi1HobPfjzzmTs9xyW7VFPZ4fuuIs4SuZAuHNAdma8 pk1DjmFCUor213OZpZ7I2HDYgmN28nt7ZG564ZQghl/upf96sg6/dnXeB3cf5Z9B IKfg9sIp/TiCk4zH7N9Ij/yKdqdNdA3sLVGHSksa8tXXTQjdG98UFpH4x236iNFI sAM8pJJh9dzIkM6fZ2R+oQ/AKpwvziVDU6SQ3UW+VCRP7uD4uSNmRZE+lsv7Tryi Hj5Ay0OVcOrI/ZtAvwgxMg8gnNPO5+GrRztHfGkgyKXG6g3F0vdnaP27+KQIczm2 fbu2CIHCJqYeSq3Stv4NknWKIHK3oDt/5r1OdycYl0/Lss0mYcTMZFL2gk0TkI+o VHbYz3tmH2rvdJPjtWbDsjA3CuOwL8mxtDKtbyAHTbaWsXU97omMUyn2VZqQiaZK Jt4QCP0ZMm5mjGYkNCk+uQlpmzTXE7Ur9b5LhnRMDqQ7iyeHzfHDFm6RRA2fjVz7 2yDMnxWlfCl6naTt6XsJZOS+W64bIvjXsotYcF01pwYX6HnuZuywdKzZjF5d7GMP kmwfmhxMqRbCA5SuQSFOdYYHzXWJ4m1ciPE41qX8nP3MHqyxuKZkcNHHXO3AvTtg 1Z0jOcw1BY6Ec10AaRsUmHUoXYoJ

On Mon, Jul 21, 2025 at 08:29:03AM -0400, The Wanderer wrote:

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

Yes, good point. Let me reword the exception to say,

"Quotes by historic people when either provided in an appropriate
content, or when behavior contrary to these policies was explicitly
requested."

This leaves the "by historic people" part of the exception, even to fortunes-off packages. I don't think we should be having a policy that basically allows discriminatory remarks by any Tom, Dick or Harry who
found their way to IRC at some point in the past to make it through this
or our regular code of conduct.

[...]

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?

Not in my opinion, no.

One thing I learned while drafting the original code of conduct is that
it's always OK, and sometimes sometimes beneficial, to be vague.

If you make up rules of human behavior, there will always be a bit of a
gray zone where it is not clear whether something is allowed, according
to the rules, or not. You can never hope to eliminate that gray zone completely; you can only make it asymptotically smaller. However, every
time you try to do so, there are two things that will happen:
- Your text gets larger and larger, until it gets unwieldy
- The chance increases of the rules outlawing something that should not
be outlawed, or not outlawing something that should be.

Because of this, I think it is a better idea to have a definition that
uses terms that are generally understood while still having some leeway
in it.

The phrase "historic person" is generally understood to mean "a person
of note who lived some time ago". Plato is, today, a historic person. So
are Adolf Hitler, JFK, and Yassir Arafat. But my great-great-great-great-great-great-grandfather, Petrus Verhelst[1], is
not, because he was not "a person of note". The current US president,
whoever that is at the time of writing of a particular text, also not. I
don't know where the cutoff point is, and neither do you, and I think
that's a feature, not a bug.

[1] Thanks, uncle Jan, for doing the whole genealogy thing so I can say
this with confidence :-)

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?

I think "widely-disseminated texts" also covers "memes", and just
because a racist text became a meme in some despicable Internet subgroup doesn't mean we should accept it in Debian.

--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
On 2025-07-21 at 10:41, Wouter Verhelst wrote:

On Mon, Jul 21, 2025 at 08:29:03AM -0400, The Wanderer wrote:

On 2025-07-21 at 07:02, Wouter Verhelst wrote:

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

Yes, good point. Let me reword the exception to say,

"Quotes by historic people when either provided in an appropriate
content, or when behavior contrary to these policies was explicitly requested."

That looks mostly good to me. People might still try to argue that
there's no explicit request involved in *the package itself*, or in
including a particular quote therein, but I think that argument would be considerably harder to support.

This leaves the "by historic people" part of the exception, even to fortunes-off packages. I don't think we should be having a policy that basically allows discriminatory remarks by any Tom, Dick or Harry who
found their way to IRC at some point in the past to make it through this
or our regular code of conduct.

Agreed. (Though some of the quotes already present in fortunes-off -
including some, but certainly not all, of the ones even I might agree
should be removed - come from what appear to be past Debian developers
in IRC. That's not "any Tom, Dick, or Harry", but it's not far off either.)

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?

Not in my opinion, no.

One thing I learned while drafting the original code of conduct is that
it's always OK, and sometimes sometimes beneficial, to be vague.

If you make up rules of human behavior, there will always be a bit of a
gray zone where it is not clear whether something is allowed, according
to the rules, or not. You can never hope to eliminate that gray zone completely; you can only make it asymptotically smaller. However, every
time you try to do so, there are two things that will happen:
- Your text gets larger and larger, until it gets unwieldy
- The chance increases of the rules outlawing something that should not
be outlawed, or not outlawing something that should be.

Because of this, I think it is a better idea to have a definition that
uses terms that are generally understood while still having some leeway
in it.

Fair, and agreed. I mostly wanted to make sure this detail, and its
potential consequences, had been specifically considered; what you've
now written seems to sufficiently indicate that it has.

The phrase "historic person" is generally understood to mean "a person
of note who lived some time ago". Plato is, today, a historic person. So
are Adolf Hitler, JFK, and Yassir Arafat. But my great-great-great-great-great-great-grandfather, Petrus Verhelst[1], is
not, because he was not "a person of note". The current US president,
whoever that is at the time of writing of a particular text, also not. I don't know where the cutoff point is, and neither do you, and I think
that's a feature, not a bug.

Agreed.

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?

I think "widely-disseminated texts" also covers "memes", and just
because a racist text became a meme in some despicable Internet
subgroup doesn't mean we should accept it in Debian.

True, though I would think that there would be other factors that would
lead to its not being included.

I'm holding back thoughts and possible concerns about a drawn line like
that preventing the inclusion of a pithy quote (from the news, from IRC,
or from wherever else) because it's too new to count as historic. I
think in practice very few, if any, quotes which might come into
consideration that way would also be close enough to the offensiveness
boundary for this criterion to even be involved.

(Some of the quotes in fortunes-off which come from past Debian
developers in IRC, and must have been quite recent at the time the
decision to add them to the package was made, do push close to that
line. It's been quite a long while since the last of those was added,
however, and it wouldn't be implausible if the types of discussions that produced them just aren't happening anymore.)

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


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEJCOqsZEc2qVC44pUBKk1jTQoMmsFAmh+VpMACgkQBKk1jTQo MmvIhA/+JzQN4TGQow3v/u8yOp118lRK3hLqyX0vXyUklNSoIQWp68RabhLcr7ck QYtbbwB4t5qMeNzyYcLWXQLevGDm/Flt4wjI2RFAeohaT/wR3mdwO/4QK0IYxacN /gBlEQcPfaIOSkuKi1NhdohYW2Qjv5SOWDLbDSlGVVV4Yoy67rZlaoIeLQ3ptjIJ x2RdIlu4Qn1LtNsrUxPZqJfgDs4ad+SbwClcYTjpezbJy6GhIqSPAHU4z8xZKU08 C2BSuIQCgpLuz/UmfPi1IuD7qYRIYK+B82RUgshopuFkkHzwHDkW8d+OY/Olb9hT elDVale6FpxwvbF3yFTkOgpGpZD2f/X7LMmFlVbBYBrHfIzNZNq496VkOzwYlFlw kTEwZAXNUBhrdJ8QzqeIOvwBSMA8vE29yWW7kDQCHLFKwQ2hh6S+Sc7XH8zYL2FF kAzBA1E/SHLIu3ZnVjuIgkaVHzA4ZoybkKxnvzy4UrsEayrTtd6RnecKYha+9VWA 33mKtDe6QBwvXQuU3ycXA484sFs8g2rPZoV4y6EJx63y+Bm0Yn2JDqSp9kXxxLl7 WNO73/K/AZDbHWtiwqpo8jfSm+tZ/MBrX8F+oAIymCXyvwEKqn211hrf8W/VqPmG FXn6STen3R7vv1lD7uODZNhkWe91

On Mon, Jul 21, 2025 at 11:02:43AM -0400, The Wanderer wrote:

On 2025-07-21 at 10:41, Wouter Verhelst wrote:

This leaves the "by historic people" part of the exception, even to fortunes-off packages. I don't think we should be having a policy that basically allows discriminatory remarks by any Tom, Dick or Harry who
found their way to IRC at some point in the past to make it through this
or our regular code of conduct.

Agreed. (Though some of the quotes already present in fortunes-off - including some, but certainly not all, of the ones even I might agree
should be removed - come from what appear to be past Debian developers
in IRC. That's not "any Tom, Dick, or Harry", but it's not far off either.)

Yes.

I considered this, but honestly? If a Debian Developer is doing
something on IRC today which falls afoul of the code of conduct, then I
don't think we should be celebrating that by putting it in fortune
files. And if we don't want to do that for developers today, why are we celebrating developers doing this 20 years ago?

Remember that this is for *exceptions* to the code of conduct. If
there's something in fortunes-off from a developer saying something on
IRC that does not fall afoul of the code of conduct, then it doesn't
matter, because that wouldn't need an exception.

--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andreas Metzler <[email protected]> writes:

Looking at the CoC again imho it just does not apply to this
purpose. The CoC is all about interaction between people while this is
more like a one-way-street.

Yes, I think I agree. I don't think the contents of packages *within the
Debian context* are very usefully defined as conduct in the sense of our
code of conduct.

Conduct, in that context, is generally the behavior of someone within a community that one voluntarily joins. It's an effort to formalize the
mutual expectations among people who are part of that community. It's the
rules or guidelines that we've agreed to try to follow so that we can get
along with each other even though we disagree (including, often, about the merits of some of the rules or guidelines). It's ideally the result of a process of mutual negotiation within the standards of a community.

Packages are different because by definition most of them are not coming
from part of our community. The authors are usually not engaged with any
of that process and usually don't want to be. As you say, it's a one-way
thing: Debian decides what we do and don't want to package, and that's
largely outside of the control or influence of upstream. And, similarly, upstream decides what they want to put into their packages and that's
outside the *control* of Debian, except to decide not to package the
software. (We can *ask*, of course, but that's not control.)

Also, I don't think our users largely consider the contents of packages provided by upstream to reflect our community. That's not what Debian is
for: we're trying to provide a functional Linux distribution and our
primary emphasis is on that functionality. I think there's a pretty deep understanding among our users that we're responsible for the packaging and integration, and to some extent the selection, but the upstream authors
are responsible for the content of the software. Although we might deal
with something particularly egregious, we're not generally going to try to
fork upstreams to try to make them follow an internal Debian code of
conduct. Even apart from the serious questions of whether this would be justifiable, I think it's obviously impractical.

I think it's important to not over-promise what we're willing to do with packages, and starting from our own code of conduct I think would run a
danger of over-promising. Unless something about a package is particularly
"in your face," I think we're generally going to prioritize functionality
and compatibility with the rest of the Linux ecosystem, even if we really dislike the behavior of some of our upstreams.

I would rather have something much narrower which could not be misused
to e.g. prevent shipping doom.

Yes, these sorts of conversations are usually quite contentious and
draining and I think we have a limited capacity as a project to sign up
for a whole lot of them, so it feels worth the effort up front to narrow
the rules down to the things we really care about.

There have been a few cases in the past where the behavior of an upstream
is particularly egregious (harassing Debian maintainers, for instance) or sophmoric, and I think I remember at least one case where it was pretty
obvious that upstream was going out of their way to make their software offensive just to annoy people. I think it might be helpful to have a
packaging policy that says we're not willing to put up with that sort of
thing. But there are going to be lots of places where bits and pieces of upstream software (particularly expressive and creative upstream software
such as games, as you point out) don't fit the sorts of standards that
Debian would apply to interactions inside the project, and I think that's
fine.

Comparing Debian directly to a public library probably goes too far, in
that we are trying to create a unified distribution and don't have the
same public mission of collecting as broad of a range of human expression
as possible, but I think there's some part of the same basic impetus at
work.

--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, July 21, 2025 7:41:10 AM Mountain Standard Time Wouter Verhelst wrote:

One thing I learned while drafting the original code of conduct is that
it's always OK, and sometimes sometimes beneficial, to be vague.

If you make up rules of human behavior, there will always be a bit of a
gray zone where it is not clear whether something is allowed, according
to the rules, or not. You can never hope to eliminate that gray zone completely; you can only make it asymptotically smaller. However, every
time you try to do so, there are two things that will happen:
- Your text gets larger and larger, until it gets unwieldy
- The chance increases of the rules outlawing something that should not
be outlawed, or not outlawing something that should be.

Because of this, I think it is a better idea to have a definition that
uses terms that are generally understood while still having some leeway
in it.

I second this. I think a principle-based code of acceptable content is much better than an enumerated-list-of-all-possibilities (which you will never really arrive at anyway) based code of acceptable content.

--
Soren Stoutner
[email protected]
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmh+nJkACgkQwufLJ66w tgNbUhAAjs0MaH9xdu6/3olKu72LN2hrC6bbp/lhKzwHtX/NEBRI9/Z5C8cWKZ1J LD43WeZLX7GMYcroSqwDV06WO1I1uez668MBY+8V2nvhkxa8ISRF7g4sXek+4dSb 0Bw7z/l39dKZSv2g6V8RfNOCgMSKUusb5CQSxDhUytv2U+HjRGqhDSvq2qzB7A+M 5q+T4uZsK1H9H6xtGYYi8Gp1jJ2fDO9xLZl5CGUTjNrbpn3cLlzz6fjdjvbFURPp CcHzP+I17QA/RDxI2NSFjLWRKCi0LoCgefE4p8kNVT59bRxXJjy3NqBUS+Z0h8lo 1KtUIdCXMjPnOyCEuHWsj6ha8af1zDhQsbAnPn3Vp0cBnATaHm3ulD/BB4xsOktS gdgTTM9Cpa/lRzw9jZOnn3e1UxzONJdG6KEs9Cj6yIWnPRDiFvTVCaqj+fh7lykg skmK68AIxpjtt33zJ0xvMMy+hw+YbWwQWq6nQvrKa7fpjByzcW/S9GEhS9mD67E0 IIX0Oqe7G+nntl/x/Z33rNW5yIQUHk9bvn/4j4KUmeWXONX1ECtsQoGCJQ6UKsUV RYdhKrlGGDu4aWfdesXAHQ/7CxRS6K6Rx5Vc7O7OGuKTR30Nk7fj9A763JrPFDpi X7f5r1IlvCaHopCRcz1uoatfpIGD9XhKo1AxVhas3+9xL4JDwmI=
=2tFy
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 21 Jul 2025 19:22:22 +0200, Wouter Verhelst wrote:

On Mon, Jul 21, 2025 at 04:59:32PM +0200, Iustin Pop wrote:

My point is here that setting a CoC for package data is just a proxy for
what we actually want, which I'm not sure is clear (to me; it might
already be to other people). If it is, then deriving the CoC for
packages from it should be rather straightforward.

Honestly, what *I* want is an answer, that we all can agree with, to the >question of whether the code of conduct applies to what we package, and
if so whether it fully applies or only partially.

I'm feeling somewhat uneasy, and/because I think we have a logical
problem here:
- The CoC is about interaction between people;
- what we are discussiong right now is accaptable contents of
packages (messages, texts).

That's categorically different; I can't be respectful, assume good
faith, be collaborative, be concise, be open, etc. against a text (as
I can be about other people's behaviour).

I see the point in this topic about creating rules about what texts
we want and don't want to have in Debian. But I strongly think that
framing this as "application of the Debian CoC for packages" is a
logical dead end. - If we want this, we need to create some new "What
language is acceptable in Debian" rules.


Cheers,
gregor

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmh+vgZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ qgbsRQ//SyYlOmbur8gUbyLPNCaPePaa1rk45sl/OwlV3jBwkxgIaGec5UWqXVpv a3Eq910Cu3kBY0VZrbw6vjtcDipegKTy4E24LwoEUac0dqiC/Pi0jTqO33Lb3YQu d5dL3pkE349Vug+VACyfpAX40UbWFyT8ylSyNKd0ESCLMLkZUwO8UEzj4iZv8zSR 4I1sEJ2cOrhIikuT8REK4p/0AE9N3LDz1r1eu4UiZsMg/K8rfTuZgyhOj9hcsDj4 jrymhgX4Idh3QvqTI6ObzPjxAYWPfXe0fsoRfLpGdJdJDbq4jYRo4GU1DwhZ4e7+ qLcrpSACAkT/OVX2ubTvB5vPWIUHxtj6kxaSUzvVfMF5q7lHNai3hzt8dtS97Z0C JhisIvP0PKHU2tbHpdkh/wI/SrBgLmn52UNbnwFgMEBS4wrXUPkfD3neInzuGp5J Rbl2iJg7zscV7+ZFFPwHXCLrTXH63XT3hwIVU6c0OLPxngfYeIIYv3tZZPzB43DA CJkQJarB4+Gyr5izVXxG+iYCB9MeDWNoY7Pb57tOCUz6DI6S5u5O622zN4F8YIln S2XueWhC2h4KS33iCNFQUwu/7KROURNjcTDH5z7p7auV4vgbwvXIypfTaPo9f0JH YEuPGBa6RLTL63sedMoU1sNTf9dEmOnUjdW6/c3ALjrCnX2Pyps=
=6OUT
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Tue, Jul 22, 2025 at 12:24:06AM +0200, gregor herrmann wrote:

On Mon, 21 Jul 2025 19:22:22 +0200, Wouter Verhelst wrote:

On Mon, Jul 21, 2025 at 04:59:32PM +0200, Iustin Pop wrote:

My point is here that setting a CoC for package data is just a proxy for what we actually want, which I'm not sure is clear (to me; it might already be to other people). If it is, then deriving the CoC for
packages from it should be rather straightforward.

Honestly, what *I* want is an answer, that we all can agree with, to the question of whether the code of conduct applies to what we package, and
if so whether it fully applies or only partially.

I'm feeling somewhat uneasy, and/because I think we have a logical problem here:
- The CoC is about interaction between people;
- what we are discussiong right now is accaptable contents of packages (messages, texts).

That's categorically different; I can't be respectful, assume good faith, be collaborative, be concise, be open, etc. against a text (as I can be about other people's behaviour).

I see the point in this topic about creating rules about what texts we want and don't want to have in Debian. But I strongly think that framing this as "application of the Debian CoC for packages" is a logical dead end. - If we want this, we need to create some new "What language is acceptable in
Debian" rules.

That's my understanding as well. As much as I appreciate Wouter's
efforts on this, I'm having trouble to imagine an explicitly link
between the Debian CoC and such set of rules in practical terms.

Also, it seems to me that we're talking about an issue that isn't a
recurrent problem in the project, so it perhaps doesn't really need new
rules, a GR or another long thread in -vote.

Honest question: in ~30 years, how many packages have been removed from
our archive due to offensive content? 4? 5? How many of the removal
requests turned into big drama?

Bests,

--
Tiago Bortoletto Vaz

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEOAYLMZqeqHbTW+jfgVxjVIQAXyEFAmh+6bwACgkQgVxjVIQA XyE01RAAoIXW67KptMVwJFxs6uYB6vuC+XlWm76Vl0wNMuJTyrLsAa8Gn0vPc5DM G4wT238ROjIFqRTH0m9O7H9Yd7tLYp0k4OkuAOcYhbaNldf68tAGRf/mIPbWiyvc pi2qoJVoKlaftdeUVw7yuDqDaPon8azd+AxUCGjLiRah3hs3yokUiD+02drRq7vt KVVsowNqT63PkeXjIaFmvtwQARclVMg7hJ6QaUthQpc+Jw7XJ5Dj7dmKBbN+uTQ6 1c1mVG9XOHyIPQRa0ikrEkvBo/oS6oYWc/SOoHoVl0HCczic4OJltt/YC7s7zCD3 Y6Ds+ivoHWEh/8Na6G6hUCAFP1QLCehX8BETfeaQ2DpN/j25THNid8Ut5Q3E9oLn jUDrLuWosI4/0H3wu87DWe5Y+RgGP4f3vFDojM3bnPtuSBZ+uyS2/FIhfCUjq+Ho APB0Mhi072oAZuyZCDMTE37XgNK4CLPHiNJaMEEiUWLDcDCRkXTCCaQjVo93Uabh Dkrp6uV0Rp5oOGQR31rr4rHhjOgZUAs6ATI0mo31plGP2X6K740p8EB3YHoqlHJw J0qBWXOXF/9pm+mxvJxVCD+cLx6Y8SJz8kqHHvFdR93d8GSexvIWYjrADCchxlSC L0ZGIuz4YbjeRsS79On1qQudYKsbohzu9BztHGHp06Nu9iJh7hk=
=Cl6I
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 7/22/25 02:22, Wouter Verhelst wrote:

I.e. we just can't afford to be the morality police, but we agree with
it and wish someone would do it.

More like, we think it's a good idea if someone did it, but it's not the
main focus of our project and we should focus on the things that we can change (i.e., what gets into Debian), rather than trying to impose our
will upon the larger (Free Software) world.

FWIW, someone else being the morality police is going to go poorly, it
is therefore not a good idea, and we should resist it when it comes up.

However, this should not take the form of the stupidest form of
liberalism where the more vile the speech you defend, the more of a free
speech advocate you are.

We decide what we ship and therefore make available to a wider audience,
and this can not be distinct from our own values, or we spend a lot of
time counteracting ourselves.

Simon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

Also, it seems to me that we're talking about an issue that isn't a
recurrent problem in the project, so it perhaps doesn't really need new rules, a GR or another long thread in -vote.

It is a recurrent problem in the project. It's not daily but it
certainly is recurrent.

Honest question: in ~30 years, how many packages have been removed from
our archive due to offensive content? 4? 5? How many of the removal
requests turned into big drama?

AFAIK, all of them.

Also it is very annoying for people to be hit by unknown and unwritten
rules that leave no room to appeal.

It is my first time as a DD but it certainly is not my 1st time as a
user, having packages disappear because someone else decided they were
immoral and to maintain my innocence I should not be able to easily
install them.

Having a rule that exists rather than "because I say so" would
probably be less controversial.

Best
--
Salvo Tomaselli

I difensori della morale tradizionale sono raramente persone di cuore. Si è tentati di pensare che essi si servano della morale come di legittimo sfogo
al loro desiderio di fare del male agli altri.
-- Bertrand Russell, Perché non sono cristiano. 1957

http://ltworf.github.io/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-07-22 13:26:12, Simon Richter wrote:

Hi,

On 7/22/25 02:22, Wouter Verhelst wrote:

I.e. we just can't afford to be the morality police, but we agree with
it and wish someone would do it.

More like, we think it's a good idea if someone did it, but it's not the main focus of our project and we should focus on the things that we can change (i.e., what gets into Debian), rather than trying to impose our
will upon the larger (Free Software) world.

FWIW, someone else being the morality police is going to go poorly, it is therefore not a good idea, and we should resist it when it comes up.

However, this should not take the form of the stupidest form of liberalism where the more vile the speech you defend, the more of a free speech
advocate you are.

We decide what we ship and therefore make available to a wider audience, and this can not be distinct from our own values, or we spend a lot of time counteracting ourselves.

Yes, but the recent messages in the thread are about how _close_ should
be the package polict to our CoC. Nobody argues for opposite, but there
are valid points that it should not be simply the CoC with a few words
flipped.

iustin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jul 22, 2025 at 07:37:27AM +0200, Salvo Tomaselli wrote:

Hello,

Also, it seems to me that we're talking about an issue that isn't a recurrent problem in the project, so it perhaps doesn't really need new rules, a GR or another long thread in -vote.

It is a recurrent problem in the project. It's not daily but it
certainly is recurrent.

This, exactly.

I have shown a few examples upthread. Those were only the ones *I* could remember, so any examples that I didn't know about, or any examples that
I forgot about, were not there.

I think a clearer rule is a good idea. Right now, the release team have
chosen to take action because "Code of Conduct", but I'm not so sure
it's the right call, and I'm *also* not sure that the code of conduct
even applies to that (as others have also pointed out in this thread).

And that leaves out the question of whether the release team is really
the right team to be making this call, at all.

And honestly, if we think about this and decide as a project that
"anything is allowed except things that are obviously illegal", then
that's fine with me too. I just want us to think about this and make the
call, rather than leaving this to a team that really have a different responsibility and will take the flak for doing something that shouldn't
even be their job but nobody else is doing it.

Do we *need* a content policy? I'm not 100% convinced we do, but clearly
there are people who do think so, and who feel that it should be
imposed. So if that's the case, then I think we should decide as a
project, rather than have one decided by a team which may or may not
have ended up with what happens to be the project's consensus.

Note that none of the above is meant as criticism to the release team.
They do a hard job under difficult circumstances, and that is
appreciated. It's just that this may not be the best use of their time
or experience.

And if we have a GR about this, that will also reduce the flak they get
for this, because then it's not their fault that the policy is what it
is.

Honest question: in ~30 years, how many packages have been removed from
our archive due to offensive content? 4? 5? How many of the removal requests turned into big drama?

AFAIK, all of them.

Well, I imagine there might have been a few cases where people went "I
don't agree with this, it's sad, but meh, I don't have enough spoons to
fight this".

--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Luke,

On Mon, Jul 21, 2025 at 07:49:24PM +0200, Luke W Faraone wrote:

On 21/07/2025 19:22, Wouter Verhelst wrote:

Do I think the answer "the code of conduct does not apply to packages in Debian and anything is allowed there" is appropriate? Well, that's complicated, as then that opens the door to blatant coc violations in changelog entries. Someone writing a changelog entry with "**** the XYZ team for making my life a living hell with this stupid requirement" in
it is potentially violating the code of conduct.

Noting briefly: yes, the "debian/" directory / tarball is a "mode of communication within the project" and already covered by the CoC.

Thanks for that note. I hadn't intended that interpretation when I
originally wrote that sentence, but it's actually a very valid
interpretation of it and it is a good rule, so I'm happy that you do
interpret it that way :-)

It does mean that a potential package content policy wouldn't have to
worry too much about having to deal with differentiation between debian-specific and not debian-specific contents, as we could just say
"native packages and the contents of the debian directory for non-native packages fall under the coc" and be done with that bit.

So that's a whole tangled mess avoided :-D

Hi Mathias,

On Tue, Jul 22, 2025 at 09:15:14AM +0200, Mathias Behrle wrote:

* Wouter Verhelst: " CoC policy for package contents (was: Re: Can the
community team remove packages or kick me out for not removing packages?)"
(Mon, 21 Jul 2025 13:02:32 +0200):

Hi Wouter,

I intend to make this a formal GR proposal with the third option in the above list a few weeks from now, unless the thread is still full-on and productive by then.

I appreciate a lot your proposal. Would it make sense to delay a little bit further, because in a few weeks from now quite some interested people at least
in EU will be on vacation?

I think the early feedback shows that it's a complicated matter with a
lot more corner cases than I anticipated at first sight, so I imagine it
might take quite a while to get to something useful anyway.

I may have to bite the bullet and write something separate, like I
suggested as the fourth option in my original message. Sigh. We'll get
there.

--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

CgpPbiBKdWwgMjMsIDIwMjUgMjA6MTgsIFNvcmVuIFN0b3V0bmVyIDxzb3JlbkBkZWJpYW4ub3Jn PiB3cm90ZToKCj4KCj4gSSBhZ3JlZSB3aXRoIGFsbCBvZiB0aGUgYWJvdmUuICBJIGJlbGlldmUg dGhpcyBpcyBhbHJlYWR5IERlYmlhbuKAmXMgZGUgZmFjdG8gCgo+IHBvbGljeSwgYnV0IGFueSBD b2RlIG9mIEFjY2VwdGFibGUgQ29udGVudCB3ZSBkZXZlbG9wIHNob3VsZCBleHBsaWNpdGx5IHN0 YXRlIAoKPiB0aGF0IERlYmlhbiB3aWxsIG5vdCBkaXN0cmlidXRlIGlsbGVnYWwgY29udGVudCBp biB0aGUganVyaXNkaWN0aW9ucyB3ZSAKCj4gc3VwcG9ydCwgYW5kIHRoYXQsIGJlY2F1c2UgRGVi aWFuIHdpbGwgbmV2ZXIgcGVyZm9ybSBhZ2UgdmVyaWZpY2F0aW9uIG9uIGl0cyAKCj4gdXNlcnMs IHRoYXQgbWVhbnMgdGhhdCBEZWJpYW4gd2lsbCBub3QgZGlzdHJpYnV0ZSBtYXRlcmlhbCB0aGF0 IGlzIGlsbGVnYWwgZm9yIAoKPiBtaW5vcnMgaW4ganVyaXNkaWN0aW9ucyBpdCBzdXBwb3J0cy4g Cgo+Cgo+IFRoZSBkaXN0aW5jdGlvbiBhYm91dCBqdXJpc2RpY3Rpb25zIHdlIHN1cHBvcnQgaXMg aW1wb3J0YW50LiAgQXMgcmVnaW9uYWwgCgo+IHZhcmlhdGlvbnMgaW4gbGF3cyBpbmNyZWFzZXMs IHdlIGFyZSBzb29uIGdvaW5nIHRvIGhhdmUgdG8gY29uZnJvbnQgCgo+IGRpZmZpY3VsdGllcyBp biBsb2NhbCBsYXdzIHByb2hpYml0aW5nIGZ1bmRhbWVudGFsIGFzcGVjdHMgb2YgRGViaWFu4oCZ cyAKCj4gbWlzc2lvbi4gIEZvciBleGFtcGxlLCBJIGRvIG5vdCB0aGluayBpdCB3aWxsIGJlIHRv byBmYXIgZGlzdGFudCB3aGVuIHNvbWUgCgo+IHBhcnRzIG9mIHRoZSB3b3JsZCB3aWxsIG1ha2Ug dGhlIERGU0cgNSAiTm8gRGlzY3JpbWluYXRpb24gQWdhaW5zdCBQZXJzb25zIG9yIAoKPiBHcm91 cHPigJ0gYW5kIERGU0cgNiAiTm8gRGlzY3JpbWluYXRpb24gQWdhaW5zdCBGaWVsZHMgb2YgRW5k ZWF2b3LigJ0gaWxsZWdhbCBieSAKCj4gcmVxdWlyaW5nIHNvZnR3YXJlIGRpc3RyaWJ1dGlvbnMg dG8gZGlzY3JpbWluYXRlIGFnYWluc3QgcGVyc29ucywgZ3JvdXBzLCBhbmQgCgo+IGZpZWxkcyBv ZiBlbmRlYXZvci4gIEF0IHRoYXQgcG9pbnQsIHdlIGFyZSBnb2luZyB0byBoYXZlIHRvIGRlY2lk ZSBpZiB3ZSB3aWxsIAoKPiBsb3dlciBvdXIgc3RhbmRhcmRzIG9yIGlmIHdlIHdpbGwgY2Vhc2Ug dG8gYWN0aXZlbHkgZGlzdHJpYnV0ZSBpbiBhbmQgc3VwcG9ydCAKCj4gdGhvc2UganVyaXNkaWN0 aW9ucy4gIE15IGV4cGVjdGF0aW9uIGlzIHRoYXQgd2Ugd2lsbCBkZWNpZGUgdG8gd2l0aGRyYXcg ZnJvbSAKCj4gdGhvc2UganVyaXNkaWN0aW9ucyByYXRoZXIgdGhhbiBhbGxvdyB0aGVtIHRvIHJl d3JpdGUgdGhlIERGU0cuICBJbiB0aG9zZSAKCj4gY2FzZXMgd2hlcmUgd2Ugbm8gbG9uZ2VyIHN1 cHBvcnQgYSBqdXJpc2RpY3Rpb24gYmVjYXVzZSBpdHMgbGF3cyBjb25mbGljdCB3aXRoIAoKPiBv dXIgY29yZSBwcmluY2lwbGVzLCB0aGVuIGFiaWRpbmcgYnkgdGhlIGxhd3Mgb2YgdGhhdCBqdXJp c2RpY3Rpb24gd2lsbCBubyAKCj4gbG9uZ2VyIGFwcGx5IHRvIHRoZSBDb2RlIG9mIEFjY2VwdGFi bGUgQ29udGVudCBlaXRoZXIuIAoKPgoKPiAtLSAKCj4gU29yZW4gU3RvdXRuZXIgCgo+IHNvcmVu QGRlYmlhbi5vcmcKCgoKVGhlcmUgbWF5IGJlIHNvbWUgZWRnZSBjYXNlcy4gV2hhdCBpZiBhIGNv dW50cnkgZGVjaWRlZCB0byBmb3JiaWQgc2hpcHBpbmcgeW91dHViZSBkb3dubG9hZGVycyA/IE9y IGdhbWJsaW5nIHNvZnR3YXJlID8KCgpUaG9tYXMgR29pcmFuZCAoemlnbykKCgo= PGh0bWw+PGJvZHk+PGJyPjxkaXYgZGlyPSJsdHIiPk9uIEp1bCAyMywgMjAyNSAyMDoxOCwgU29y ZW4gU3RvdXRuZXIgJmx0O3NvcmVuQGRlYmlhbi5vcmcmZ3Q7IHdyb3RlOjwvZGl2Pgo8ZGl2IGRp cj0ibHRyIj4mZ3Q7PC9kaXY+CjxkaXYgZGlyPSJsdHIiPiZndDsgSSBhZ3JlZSB3aXRoIGFsbCBv ZiB0aGUgYWJvdmUuwqAgSSBiZWxpZXZlIHRoaXMgaXMgYWxyZWFkeSBEZWJpYW7igJlzIGRlIGZh Y3RvIDwvZGl2Pgo8ZGl2IGRpcj0ibHRyIj4mZ3Q7IHBvbGljeSwgYnV0IGFueSBDb2RlIG9mIEFj Y2VwdGFibGUgQ29udGVudCB3ZSBkZXZlbG9wIHNob3VsZCBleHBsaWNpdGx5IHN0YXRlIDwvZGl2 Pgo8ZGl2IGRpcj0ibHRyIj4mZ3Q7IHRoYXQgRGViaWFuIHdpbGwgbm90IGRpc3RyaWJ1dGUgaWxs ZWdhbCBjb250ZW50IGluIHRoZSBqdXJpc2RpY3Rpb25zIHdlIDwvZGl2Pgo8ZGl2IGRpcj0ibHRy Ij4mZ3Q7IHN1cHBvcnQsIGFuZCB0aGF0LCBiZWNhdXNlIERlYmlhbiB3aWxsIG5ldmVyIHBlcmZv cm0gYWdlIHZlcmlmaWNhdGlvbiBvbiBpdHMgPC9kaXY+CjxkaXYgZGlyPSJsdHIiPiZndDsgdXNl cnMsIHRoYXQgbWVhbnMgdGhhdCBEZWJpYW4gd2lsbCBub3QgZGlzdHJpYnV0ZSBtYXRlcmlhbCB0 aGF0IGlzIGlsbGVnYWwgZm9yIDwvZGl2Pgo8ZGl2IGRpcj0ibHRyIj4mZ3Q7IG1pbm9ycyBpbiBq dXJpc2RpY3Rpb25zIGl0IHN1cHBvcnRzLiA8L2Rpdj4KPGRpdiBkaXI9Imx0ciI+Jmd0OzwvZGl2 Pgo8ZGl2IGRpcj0ibHRyIj4mZ3Q7IFRoZSBkaXN0aW5jdGlvbiBhYm91dCBqdXJpc2RpY3Rpb25z IHdlIHN1cHBvcnQgaXMgaW1wb3J0YW50LsKgIEFzIHJlZ2lvbmFsIDwvZGl2Pgo8ZGl2IGRpcj0i bHRyIj4mZ3Q7IHZhcmlhdGlvbnMgaW4gbGF3cyBpbmNyZWFzZXMsIHdlIGFyZSBzb29uIGdvaW5n IHRvIGhhdmUgdG8gY29uZnJvbnQgPC9kaXY+CjxkaXYgZGlyPSJsdHIiPiZndDsgZGlmZmljdWx0 aWVzIGluIGxvY2FsIGxhd3MgcHJvaGliaXRpbmcgZnVuZGFtZW50YWwgYXNwZWN0cyBvZiBEZWJp YW7igJlzIDwvZGl2Pgo8ZGl2IGRpcj0ibHRyIj4mZ3Q7IG1pc3Npb24uwqAgRm9yIGV4YW1wbGUs IEkgZG8gbm90IHRoaW5rIGl0IHdpbGwgYmUgdG9vIGZhciBkaXN0YW50IHdoZW4gc29tZSA8L2Rp dj4KPGRpdiBkaXI9Imx0ciI+Jmd0OyBwYXJ0cyBvZiB0aGUgd29ybGQgd2lsbCBtYWtlIHRoZSBE RlNHIDUgJnF1b3Q7Tm8gRGlzY3JpbWluYXRpb24gQWdhaW5zdCBQZXJzb25zIG9yIDwvZGl2Pgo8 ZGl2IGRpcj0ibHRyIj4mZ3Q7IEdyb3Vwc+KAnSBhbmQgREZTRyA2ICZxdW90O05vIERpc2NyaW1p bmF0aW9uIEFnYWluc3QgRmllbGRzIG9mIEVuZGVhdm9y4oCdIGlsbGVnYWwgYnkgPC9kaXY+Cjxk aXYgZGlyPSJsdHIiPiZndDsgcmVxdWlyaW5nIHNvZnR3YXJlIGRpc3RyaWJ1dGlvbnMgdG8gZGlz Y3JpbWluYXRlIGFnYWluc3QgcGVyc29ucywgZ3JvdXBzLCBhbmQgPC9kaXY+CjxkaXYgZGlyPSJs dHIiPiZndDsgZmllbGRzIG9mIGVuZGVhdm9yLsKgIEF0IHRoYXQgcG9pbnQsIHdlIGFyZSBnb2lu ZyB0byBoYXZlIHRvIGRlY2lkZSBpZiB3ZSB3aWxsIDwvZGl2Pgo8ZGl2IGRpcj0ibHRyIj4mZ3Q7 IGxvd2VyIG91ciBzdGFuZGFyZHMgb3IgaWYgd2Ugd2lsbCBjZWFzZSB0byBhY3RpdmVseSBkaXN0 cmlidXRlIGluIGFuZCBzdXBwb3J0IDwvZGl2Pgo8ZGl2IGRpcj0ibHRyIj4mZ3Q7IHRob3NlIGp1 cmlzZGljdGlvbnMuwqAgTXkgZXhwZWN0YXRpb24gaXMgdGhhdCB3ZSB3aWxsIGRlY2lkZSB0byB3 aXRoZHJhdyBmcm9tIDwvZGl2Pgo8ZGl2IGRpcj0ibHRyIj4mZ3Q7IHRob3NlIGp1cmlzZGljdGlv bnMgcmF0aGVyIHRoYW4gYWxsb3cgdGhlbSB0byByZXdyaXRlIHRoZSBERlNHLsKgIEluIHRob3Nl IDwvZGl2Pgo8ZGl2IGRpcj0ibHRyIj4mZ3Q7IGNhc2VzIHdoZXJlIHdlIG5vIGxvbmdlciBzdXBw b3J0IGEganVyaXNkaWN0aW9uIGJlY2F1c2UgaXRzIGxhd3MgY29uZmxpY3Qgd2l0aCA8L2Rpdj4K PGRpdiBkaXI9Imx0ciI+Jmd0OyBvdXIgY29yZSBwcmluY2lwbGVzLCB0aGVuIGFiaWRpbmcgYnkg dGhlIGxhd3Mgb2YgdGhhdCBqdXJpc2RpY3Rpb24gd2lsbCBubyA8L2Rpdj4KPGRpdiBkaXI9Imx0 ciI+Jmd0OyBsb25nZXIgYXBwbHkgdG8gdGhlIENvZGUgb2YgQWNjZXB0YWJsZSBDb250ZW50IGVp dGhlci4gPC9kaXY+CjxkaXYgZGlyPSJsdHIiPiZndDs8L2Rpdj4KPGRpdiBkaXI9Imx0ciI+Jmd0 OyAtLSA8L2Rpdj4KPGRpdiBkaXI9Imx0ciI+Jmd0OyBTb3JlbiBTdG91dG5lciA8L2Rpdj4KPGRp diBkaXI9Imx0ciI+Jmd0OyBzb3JlbkBkZWJpYW4ub3JnPC9kaXY+Cjxicj48YnI+PGRpdiBkaXI9 Imx0ciI+VGhlcmUgbWF5IGJlIHNvbWUgZWRnZSBjYXNlcy4gV2hhdCBpZiBhIGNvdW50cnkgZGVj aWRlZCB0byBmb3JiaWQgc2hpcHBpbmcgeW91dHViZSBkb3dubG9hZGVycyA/IE9yIGdhbWJsaW5n IHNvZnR3YXJlID88L2Rpdj4KPGJyPjxkaXYgZGlyPSJsdHIiPlRob21hcyBHb2lyYW5kICh6aWdv KTwvZGl2Pgo8YnI+PC9ib2R5PjwvaHRtbD4=

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, July 22, 2025 4:29:00 AM Mountain Standard Time Ilu wrote:

More importantly than morality issues Debian needs to consider legal
issues. I have no idea whether a CoC or GR is needed but if such an GR
is put to the vote legal constraints cannot be ignored.

Am 21.07.25 um 20:05 schrieb Lucas Nussbaum:

On 21/07/25 at 19:22 +0200, Wouter Verhelst wrote:

I can think of a few more examples that caused controversies in in the
past:
- A system load monitor, about 20 years ago, that used a cartoon of a

lady who was progressively undressed as the computer got warmer.

It was named 'hot-babe'.

Those themes for hot-babe could serve as test data points for a policy
on the content of packages: http://caca.zoy.org/wiki/hot-babe

- A toolkit called "weboob" (for "WEB Outside Of Browser") that had

devolved into a bunch of juvenile boob jokes

#906119, #907199

I vaguely remember a mailing list discussion about distributing a game
with child-porn elements - that was considered fine by some but is
strongly illegal in lots of jurisdictions. Luckily it never made it into Debian.

I *also* think that it's not a problem if software in Debian does such
things optionally, if explicitly enabled. But perhaps not everyone
agrees with that, and that's fine.

The line is difficult to draw: fortunes-*-off, hot-babe or weboob
are/were optional in Debian (as in no user is forced to install them,
and they probably don't/didn't have reverse-depends). So it would be OK
to keep them in Debian?

Debian has a responsibility regarding their mirrors to not make them inadvertendly distribute punishable material, even if optional. In some jurisdictions this also involves historical quotes if not put into a scientific historical context. Keeping them optional will not help the
mirror in case it gets under scrutiny.

I know that what different jurisdictions see as punishable offense
differs wildly around the world. But there is at least some agreement in
a majority of jurisdiction about what never goes and about what only
goes from a certain age. Remember that distributing inappropriate
material to minors is also punishable in some (most?) jurisdictions. And Debian does not do age verification. This means that at least the user interaction of every package needs to stay on the "appropriate for children"-side. No matter whether optional or not.

I haven't looked at fortune-off but if it contains porn, violence or
quotes of certain historical figures without appropriate context (I'm
not talking about DDs here), it needs to leave Debian.

Enforced age verification might cause problems for some games which does
not sit well with me and might need further discussion if legislation
goes as planned by the EU. But even games in Debian should have their
limits (as in the example mentioned above).

In any case user interaction can be required to respect the laws and
whenever anybody feels the need to present material to the user that is
known to be illegal in many jurisdictions it should not be distributed
by Debian. At the very least in order to protect our mirrors.

I agree with all of the above. I believe this is already Debian’s de facto policy, but any Code of Acceptable Content we develop should explicitly state that Debian will not distribute illegal content in the jurisdictions we support, and that, because Debian will never perform age verification on its users, that means that Debian will not distribute material that is illegal for minors in jurisdictions it supports.

The distinction about jurisdictions we support is important. As regional variations in laws increases, we are soon going to have to confront difficulties in local laws prohibiting fundamental aspects of Debian’s mission. For example, I do not think it will be too far distant when some parts of the world will make the DFSG 5 "No Discrimination Against Persons or Groups” and DFSG 6 "No Discrimination Against Fields of Endeavor” illegal by
requiring software distributions to discriminate against persons, groups, and fields of endeavor. At that point, we are going to have to decide if we will lower our standards or if we will cease to actively distribute in and support those jurisdictions. My expectation is that we will decide to withdraw from those jurisdictions rather than allow them to rewrite the DFSG. In those cases where we no longer support a jurisdiction because its laws conflict with our core principles, then abiding by the laws of that jurisdiction will no longer apply to the Code of Acceptable Content either.

--
Soren Stoutner
[email protected]
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmiBJ1sACgkQwufLJ66w tgPPrBAAsPszvefcyryvGtKRg8jzLxFlHiW+ypuLWBcVf7yrtFejt4AR3J3vn9ca c3O1TkTetuFpXIBfiki/T3kCiVtRQ/jviFM7JKqq5VBWWh9bS1UMqsg+kEordV1r bxdgpQmEoBj2NaIBsg7I1/mnZUiNvwxN11GsreRAB8/dHVzwg6EgQjOoVkiUmKMA eh9ANwuolV6L/j8v6iBLt0WvKstAQEhDcSWv48DPXZd/Jmn7a7lAgHczBjtJkA6Y +Png8ONL5wqWk/gTtI5zZNPadqHMAqAx1PoK4OXZOtzkD0PUmmbIz+JjNQQ4zFp3 DULfFaP0ozEZfDLJFF40GEfpC6d/JGCq0OjndNClLd5K2+ZmqXbBtjUG/U7sGaiV oFX81sU9Tiap5nKQMXz4MdYKQ77vIT2EPPIUo3XJOnLvYnLzlvSklOBBPYsLpQ5v XuqBgXzCLyGHQWek24KliD9MVfYkU2EnKB2e5cGiqeJVCemPAXiWVeTZ06YpG6gs sqRZ5r4xcPBkWQYp4xdp7IuUxFtJ3n/6/MvJwNdXztpyuaRMrPzky9nJqbLN6gtn WJNf/90FUjkM4Vm3mbPgSet62J6ciSWKQlXW3ahf8l8zVVxqaEXRPCySDaeLpDrr VitYbcavSELLuroK1eb7vn95wcbH3TRYnamC9n6f6qxDIX2I/QQ=
=SnuI
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, July 23, 2025 12:21:38 PM Mountain Standard Time Russ Allbery wrote:

[email protected] writes:

There may be some edge cases. What if a country decided to forbid
shipping youtube downloaders ? Or gambling software ?

Or cryptographic algorithms that do not have government back doors.

That is a good point. In the past, Debian dealt with the issue of cryptographic export legislation by effectively having two archives of Debian, on that could be distributed in the US and one that couldn’t.

We could certainly try to go down that road again. However, as world laws get more fractured on these issues, I think the more likely route is that we are going to decide there are certain jurisdictions where we are going to refuse to distribute and support Debian rather than complying with their laws. Partially because having 50 different versions of Debian is unsustainable from a volunteer effort perspective.

In a more general sense, I think that the divergence of an international legal standard on a whole host of issues is probably going to be the single greatest threat to Debian in the decades to come. We saw this on a very small scale with the sanctions placed on Russia. By its nature, open-source software is developed collaboratively on an international scale.

What happens when war breaks out between significant international players?

What happens when countries pass laws that prohibit the use of software with contributions from citizens of countries with which they are at war?

What happens when countries pass laws that prohibit the distribution of software to citizens of countries with which they are at war?

Debian could likely find itself in a situation where they can no longer continue to operate in countries on both sides of an armed conflict. At that point, it can either fracture into two organizations, one on each side of the conflict. Or, it can case to operate in countries on one side of the conflict.

To make this more complex, I don’t think we will end up with just two sides of
a conflict like we have had for the last 80 years or so. Rather, things are moving towards a more splintered future.

Most of what I have written above doesn’t directly address the topic at hand,
except for the sense that I think any Code of Acceptable Content policy should be explicit that we follow all legal requirements for the content we ship, but only for those jurisdiction where we operate. Currently that is the whole world (as far as I know), but it won’t be able to stay that way indefinitely.

--
Soren Stoutner
[email protected]
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmiBPkoACgkQwufLJ66w tgM0mxAArCzfiHBOoX6+FLChoM2HLB6TiaOEf1MtbQvgohFOqWXfsVZ+QoeborSH DKcWRkZjnD9RC7tiRIhP55eSLQRshqZdUPEVhBovbJFY+zWqmiY3Q2t2mhphcPqu khkaBMDEgjVMiK/W+vSr6aC4m3/7wLf840ICWhg9JMMO/hbmuIuXI3Uoj5IhN77o a2+gdjclwMA7SgGhWIYlNRD97MzjUKKFct2pevI5iMSIhsKyuFd9shQFeYKsdw4d 3gVz3QYyzQ2u0l+JVepsamhUpIoPQeoMOdM+D2+VPD/1XO5ubGRx9QwhjukDQ+ub Wr77EWmCmZm2OIZRXEEmzX/RTejCmsbJGS6/eNBDn64HYa8pmdDsxsOwZEnUGLOv UNw+PR6GRwUKIMYH4XXohrBfKcUIrwfqVhEKTd90UjO7ohFWvX9Axhh/ANhQ6uMa 5LNWTljz3kz7MiDXGmcxofg2lg0LoPSIxY2ohwHwgdgC/2B929VCJ8qarhFJGEz3 KGsokYgaLrR/BVk0H7IGiQM1XcoTFU19wX8/Wd7h6+vb8NAzH3/WpcL40M1xT90W y/B7gMUoyqlFDabJ7iDUDsKSpuIffEPlp+fJgaK/1majUxGa3/Uz557ZJw0LfMP4 RfJ2mgTENrsVgeeBatSmXWwHnI0xHklQzRObEOoKZjjLbpF5yJY=
=krIc
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[email protected] writes:

There may be some edge cases. What if a country decided to forbid
shipping youtube downloaders ? Or gambling software ?

Or cryptographic algorithms that do not have government back doors.

--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Ilu,

On Thu, 24 Jul 2025, Ilu wrote:

I see absolutely no reason for an uproar about a minor package that the release team (I fully trust their evaluation) considered to be not adequate for being legally distributed by Debian. If not already done, source should be removed too, for the same legal reasons.

But you see that this is the first of then many many packages which
will become removed because "you already removed packages, why not
this?"

This is a first case. if the people who want to remove as many
packages as possible they do not like (remember, there was no general
consensus or voting about removing packages which have 'offensive' in
their name, not checking for content) win, they will demand a lot of
more packages to be removed - because they can.

That is the main reason I say we have to revert the decision of the
release team: we have no rule which says _why_ this package has been
removed, we have no consensus about this decision and there is no way
to say before wether a package gets thrown out.

if we want to demotivate more people with their work, go ahead. but
then we shouldn't be wondering why we have no more new people helping
out.

best regards, Hanno Wagner
--
| Hanno Wagner | Member of the HTML Writers Guild | Rince@IRC |
| Eine gewerbliche Nutzung meiner Email-Adressen ist nicht gestattet! |
| 74 a3 53 cc 0b 19 - we did it! | Generation @ |

#"Die Informationsgesellschaft heisst Informationsgesellschaft, weil in
# ihr die staatliche Kontrolle von Informationen zu einer zentralen Frage
# wird." -- [email protected] (Axel H. Horns), [email protected]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Ilu,

On Thu, 24 Jul 2025, Ilu wrote:

Yes, if a package is illegal in a jurisdiction we care about (this does not necessarily include the whole world), it needs to be removed. Full stop. There is no compromise possible on that. I'm not discussing morals here. I'm discussing law.

There I agree with you.

That being said I have not downloaded and checked any fortune package myself because messages in this thread described content that is illegal in my jurisdiction. Nothing said in this thread convinced me otherwise.

the package we were discussing is not illegal, like being a package
about gambling, pornography or something similar. it is a
fortunes-package where quotations are in.

best regards, Hanno Wagner
--
| Hanno Wagner | Member of the HTML Writers Guild | Rince@IRC |
| Eine gewerbliche Nutzung meiner Email-Adressen ist nicht gestattet! |
| 74 a3 53 cc 0b 19 - we did it! | Generation @ | #"Allerdings muss man wohl befuerchten, dass jetzt Leute nur deshalb
# GIGO einsetzen, damit sie von mir die neuste Linux-Release per Mail
# geschickt bekommen." -- Heiko Schlichting <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Ilu,

On Thu, 24 Jul 2025, Ilu wrote:

That very much depends on "which quotes?".

I agree. But the packages was removed without even checking the
content. and _that_ is not what we want. there was no check wether the
content was (only) inappropriate or wether it was illegal.

period that you are not allowed to repeat in Germany without extensive discussion of historical context. I cannot see anybody reviewing every language to make sure those quotes are reliably removed.

then we would have to remove everything textbased until these reviews
have been done?

but this is why I proposed (similar to you) a different repository for
these kind of packages. we should have them, but mirrors can decide
wether they want to mirror these packages.

best regards, Hanno Wagner
--
| Hanno Wagner | Member of the HTML Writers Guild | Rince@IRC |
| Eine gewerbliche Nutzung meiner Email-Adressen ist nicht gestattet! |
| 74 a3 53 cc 0b 19 - we did it! | Generation @ |
#"Bill Gates wife has informed him that the deployment of Bill Gates IV
# has been delayed for another 6 months due to a redesign of the user
# interface."

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

I see absolutely no reason for an uproar about a minor package that the release team (I fully trust their evaluation) considered to be not
adequate for being legally distributed by Debian.

I don't think any legal reason was mentioned in the bug report. Or any
reason at all for that matter. Nor was the decision made by the
release team, they were merely asked to enforce it.

I think the point of this discussion is to avoid arbitrary decisions,
and their inevitable fallout, since most people dislike when arbitrary
rules are used against them.

Best
--
Salvo Tomaselli

I difensori della morale tradizionale sono raramente persone di cuore. Si è tentati di pensare che essi si servano della morale come di legittimo sfogo
al loro desiderio di fare del male agli altri.
-- Bertrand Russell, Perché non sono cristiano. 1957

http://ltworf.github.io/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ilu <[email protected]> writes:

I'm not sure whether developing a Code of Acceptable Content policy at
this point in time is a good idea though.

I'll go much further than that, and say that I believe it's an
exceptionally bad idea.

As Debian Developers, we commit to adherence to a set of core common
values, which are expressed in our Social Contract. None of those
values clearly lead us to need a policy governing package content on any
axis other than compliance with the DFSG.

If external forces, like laws, force us to elide some content or come up
with additional complications in our distribution mechanisms as US law
on crypto export once did, then fine, we'll deal with those when we
must. But trying to apply some sort of moral code to package content,
or offering to avoid offending individuals or groups with the software
we distribute, feels likely to be directly in conflict with DFSG 5, "No Discrimination Against Persons or Groups", and/or DFSG 6, "No
Discrimination Against Fields of Endeavor".

It is at best a VERY slippery slope given our broad differences of
opinion about what is and is not offensive, that I think we should
completely avoid.

Bdale

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEHguq2FwiMqGzzpLrtwRxBYMLn6EFAmiCNPAACgkQtwRxBYML n6FoVA//b1+/y6lNQ++y4M/QcgYubzxVkbiKP6eJB0TXWRvn2iTLb4c240pId1LQ f4S1npsnTzVRegHQLH5jYurT0Y+70DPXShsGXxZjA90ePPZE6DNzLcUlgRt+7cwM SY1U6PvbQmFk/nYAeao8Ezo89CgWKQSN0BQHtoub5PmaSysl8Jh9NEeWJFZtdJuo Jns0LwXEqqA1W+30cNz7tJmeMk56UWmw5GkCWinJEj+mNhLmaDh/QIs0RINxnKUc qdF/FTQf+SCctd8h9hopoRvbd41ylmAjdKiMpkA+JDCL5UtoSOxhwYllO1mjXFyY +8YBWLnYIhBLqdruuUWkilyIBQTLats90a/aGddKgr75KfjX3p7l5Tv+hTXKkdnw y9tlVHNLP7iktj/LlTzaDZYO0cgu9BynxKM+lnVjfSqeCDtv6EYBfjQJ+r/EnQC/ i7fIvYwTEFwYWbNKgEb8Fexs/8TWyZY7VrfTk1z0EOlV5SrVLXzljx4q9MDEdFvg NvpaI13h+QfTLBtgjdWUnNbSTTmp0A1apLyKy2u+RjXWTnyjUuhoxRuH+BLArBAo NGgdbauV5wDvPZTCyAbuxLpKvjgelK9/F86MJqcsBUCPaKOkutGEtU1Db1xeikDd 1g/gcjbGMX+M6K9j/d94XaM0uH0TS4siODK62QIRHYC3HGtYCnQ=+4/l
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Jul 24, 2025 at 03:28:16PM +0200, Bdale Garbee wrote:

Ilu <[email protected]> writes:

I'm not sure whether developing a Code of Acceptable Content policy at
this point in time is a good idea though.

I'll go much further than that, and say that I believe it's an
exceptionally bad idea.

As Debian Developers, we commit to adherence to a set of core common
values, which are expressed in our Social Contract. None of those
values clearly lead us to need a policy governing package content on any
axis other than compliance with the DFSG.

If external forces, like laws, force us to elide some content or come up
with additional complications in our distribution mechanisms as US law
on crypto export once did, then fine, we'll deal with those when we
must. But trying to apply some sort of moral code to package content,
or offering to avoid offending individuals or groups with the software
we distribute, feels likely to be directly in conflict with DFSG 5, "No Discrimination Against Persons or Groups", and/or DFSG 6, "No
Discrimination Against Fields of Endeavor".

It is at best a VERY slippery slope given our broad differences of
opinion about what is and is not offensive, that I think we should
completely avoid.

The problem with this entire email (and other ones like it elsewhere in
the thread) is that it ignores that we are already there.

It is my understanding that fortunes packages with so called 'offensive' contents are being removed from the archive for code of conduct
reasons[1]. The debian changelog aside, this was never the intent of
the code of conduct, and that means that the code of conduct is being
abused, today, as a sort of code of acceptable conduct.

When I said upthread that I thought we should apply the code of conduct
to some parts of our package archive, it was because I bekieve (and a
member of the conduct team stated tey agree with that position) that
things like the debian changelog qualify as Debian conduct and thus fall
under the CoC. When a package sprouts insults our users or at Debian in general, I think we should take reasonable efforts to switch that
behavior off (e.g., by not shipping sudo with the 'insults' feature on
by default), but we shouldn't require extensive patching to do so, and
we shouldn't exclude packages from the archive for that reason.

Yet, fortunes-off packages have been and are being removed, against the
package maintainer's explicit wishes, for these reasons. This means that
we already do have an effective code of acceptable conduct, decided by
the release team and not the project at large, and I think that is
wrong.

I want us to have a vote on this subject so everyone agrees on what is expected, but I would want the outcome of that vote to make it clear
that, with perhaps a few exceptions as stated above, the code of conduct
does *not* apply to the archive and removing packages for that reason is
wrong.

But make no mistake about it: the status quo is not "we have no code of acceptable conduct". The status quo is that we do.

[1] I say 'understanding' because I did not actually check the
communication from the release team that happened when these
packages were being removed, so all I know is second hand
information that may be inaccurate. Even so, that would imply that
there is some confusion about this subject, which is a similar
problem that a vote could solve, too.

--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Jul 24, 2025 at 01:24:34PM +0200, Ilu wrote:

Am 24.07.25 um 12:27 schrieb Ilu:

Shipping gambling software is already forbidden in some jurisdictions
since Debian does not do age verification. At least if the gambling involves money in some way. Needs further investigation, does Debian
have such a package?

Shipping youtube downloaders has been negatively decided by at least one court case in one country that I know of, but the verdict is only enforcable inter partes. Shipping carries significant legal risks
though..

Shipping games without age verification is another risk. Has anybody
ever reviewed the games Debian ships under that aspect? I'd help with
such a review, I just don't want to install all those games and waste
time on playing them.

Just to make sure I'm not misunderstood: I do not want to start a discussion about games removal. I would - if really necessary - propose a move to a separate section in the archive to facilitate an easy "parental controls" setup.

Parental controls don't need a separate section. They need you to not
give root access to the child.

I could see us perhaps add a field to debian/control to say "in
jurisdiction X, this package is considered acceptable for people over Y
years of age", and then add some controls in apt to disallow it to
install packages marked as such. But that is a lot of work for something
that could be solved easily by saying "do not give root passwords to
your children".

--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sigh.

s/acceptable conduct/acceptable content/ over this entire email, of
course; "conduct" and "content" are too close for my brain to make the distinction, apparently...

On Fri, Aug 01, 2025 at 09:33:09AM +0200, Wouter Verhelst wrote:

The problem with this entire email (and other ones like it elsewhere in
the thread) is that it ignores that we are already there.

It is my understanding that fortunes packages with so called 'offensive' contents are being removed from the archive for code of conduct
reasons[1]. The debian changelog aside, this was never the intent of
the code of conduct, and that means that the code of conduct is being
abused, today, as a sort of code of acceptable conduct.

When I said upthread that I thought we should apply the code of conduct
to some parts of our package archive, it was because I bekieve (and a
member of the conduct team stated tey agree with that position) that
things like the debian changelog qualify as Debian conduct and thus fall under the CoC. When a package sprouts insults our users or at Debian in general, I think we should take reasonable efforts to switch that
behavior off (e.g., by not shipping sudo with the 'insults' feature on
by default), but we shouldn't require extensive patching to do so, and
we shouldn't exclude packages from the archive for that reason.

Yet, fortunes-off packages have been and are being removed, against the package maintainer's explicit wishes, for these reasons. This means that
we already do have an effective code of acceptable conduct, decided by
the release team and not the project at large, and I think that is
wrong.

I want us to have a vote on this subject so everyone agrees on what is expected, but I would want the outcome of that vote to make it clear
that, with perhaps a few exceptions as stated above, the code of conduct
does *not* apply to the archive and removing packages for that reason is wrong.

But make no mistake about it: the status quo is not "we have no code of acceptable conduct". The status quo is that we do.

[1] I say 'understanding' because I did not actually check the
communication from the release team that happened when these
packages were being removed, so all I know is second hand
information that may be inaccurate. Even so, that would imply that
there is some confusion about this subject, which is a similar
problem that a vote could solve, too.

--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22

--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 01 Aug 2025 at 11:23:41 +0200, Wouter Verhelst wrote:

Parental controls don't need a separate section. They need you to not
give root access to the child.

No amount of parental-controls integration is going to prevent someone
with root access from bypassing it, because the whole point of root
access is that it's total control over the system, including the ability
to add and remove parental-controls software.

I could see us perhaps add a field to debian/control to say "in
jurisdiction X, this package is considered acceptable for people over Y
years of age", and then add some controls in apt to disallow it to
install packages marked as such

It's perhaps worth mentioning that Flatpak (which does allow installing
apps without root access) has a simple implementation of parental
controls via OARS <https://hughsie.github.io/oars/> metadata in the
apps' Appstream metadata. The actual parental controls bit is the
malcontent package (which I believe was originally developed for Endless
OS, a Flatpak-centric Debian derivative), Flatpak just talks to it.

The quakespasm and crispy-doom packages are examples of .deb packages
that contain non-trivial OARS metadata in their files in
/usr/share/metainfo. An OARS rating is a requirement for Flatpak apps to
be added to Flathub, and Appstream encourages sending all metadata
upstream instead of maintaining it as a distro patch, so lots of other
apps have one, even if the content rating is "there is nothing
potentially objectionable here" (for example see gnome-calculator).

If this is something we want in the apt/dpkg ecosystem (more likely as
an advisory thing than as a "gate", for the reasons above), then reusing
the OARS vocabulary and its encoding into the Appstream metadata seems a
lot more viable than inventing a Debian-specific thing that won't
benefit from work done by other distributions and other packaging
formats.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello

I am not convinced that overly complicated technical solutions to
people problems are a good way to invest time.

Best

--
Salvo Tomaselli

I difensori della morale tradizionale sono raramente persone di cuore. Si è tentati di pensare che essi si servano della morale come di legittimo sfogo
al loro desiderio di fare del male agli altri.
-- Bertrand Russell, Perché non sono cristiano. 1957

http://ltworf.github.io/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)