On Wed, 02 Jul 2025 15:40:34 +0200 Ludovic Courtès <l...@gnu.org> wrote: > > So yeah, spacecadet, if you really want to continue to package it, > > we would add it to Guix, I don't think there's any policy in Guix > > against it (unless their documentation or so is also part of the > > package and includes political messages that promote any kind of > > discrimination). > > This is entirely correct. However, as a project, we have a code of > conduct and generally work to be inclusive, which is apparently the > exact opposite of what this people are doing. > > I think we can’t ignore it or we’d be sending the wrong signal.
This is a good point, but many people probably don't understand what it
means practically and I'd like to explain that to make sure we don't do
the wrong thing here.
To do that I'd like to add a trigger warning first because unwrapping
what all that means means looking at extremely negative things that are
not technical anymore but human issues (which are at the end of this
post).
The practical consequences and risks that could turn out to be
disastrous, depend a lot on how upstream really behaves.
For a start, I think that how upstream behaves with regard to
contributions is relevant to any downstream in general.
For instance if the maintainers take really bad technical decisions,
that also affect Guix as a downstream.
For instance they could refuse to fix security issues, refuse patches
because "ARM is not important", purposely include code that sabotage
their software when they detect it is running under Debian, include
nonfree software, have bad legal practices, etc.
Then all that affect downstream in some way, forcing the downstream
projects to take decisions and at least to discuss in some way with the
upstream project to hopefully reach some way to make things work for
everybody.
The example I gave are all real and this has led to discussions inside
downstream distributions (especially Debian) and sometimes even to forks
if the matter could not be resolved. These discussions also take time
and energy from the contributors.
Here I didn't verify the allegations against Xlibre, and I'm more
concerned about the general issue: basically software with
extremely toxic maintainership (more on what it means below,
between the trigger warnings).
The problem is that that kind of software makes it in Guix, it would
push Guix users and contributors to interact with its upstream in
some way, to fix this or that issue, especially when it affects Guix
(for instance fix a compilation issue with a newer compiler, etc). And
if upstream is extremely toxic that could have disastrous consequences
for these contributors.
And this happened to me multiple times: I contributed to upstream to
fix issues I had in Guix, and once I was even very strongly pushed by
Guix to do so (with adl-submit) and became (co-)maintainer of the
project because of that. And in these cases the maintainers were nice.
And we definitely don't want to push contributors to interact with
projects that are known to be extremely toxic, so when there are
strong allegations like the ones that were reported earlier in this
thread, if they are true, the risk of having extremely toxic
maintainership is extremely high, especially if there are not
safeguards against toxic behavior.
And the problem here is that if upstream behave in an extremely toxic
way and if a fork is made, it will also push the people who are
responsible of the fork to have to interact with upstream, which again
raises the same issues.
And if the fork is abandoned because upstream is way too toxic, it
creates again the same issues.
And if people go their own ways (like re-implement the project with
extremely toxic maintainership from scratch) instead of simply forking
it, the alternative project will needs to be very robust not to push
people toward the original project if the alternative fails.
So all that are good reasons to stay as far as possible from this mess.
/!\ Trigger warning /!\
This is especially the case because I don't see anyway to give
guarantees that extremely bad things won't happen.
Usually the guarantees are not that great as some maintainers are
difficult to work with, while other are really nice, so it depends a
lot on the maintainers or how well they feel and the interactions
themselves (which depend on the people and on a lot of things). There
are also a lot of different opinion and feelings on that.
But here we are talking about maintainers specifically discriminating
people in very violent ways, during their role as a maintainer, so we
probably all agree that this is way too dangerous, and that this is
bad, and that it needs to be avoided.
I assume we all agree here because the only discussion here was if we
could package the software maintained by such people, not if the
behavior of these people was justified in some way.
And given that I've shown that there is a risk that people contributing
to Guix could be exposed to such maintainers, I think that we should
avoid this risk as much as possible.
Burning contributors or being in part responsible for their suicide
is not a good thing. Having the contributors back and/or giving the
right signal here would help avoiding these extremely bad consequences.
Pushing contributors to interact with extremely toxic upstream would
have the opposite effect. The way the support network of affected people
behave (having their back or the opposite) has huge consequences on the
outcome and/or the well being of contributors (many of which can be
close to burnout already (it's a common issue in FLOSS)).
/!\ End trigger warning /!\
In contrast if an upstream is simply not responsive, don't care about
"ARM support", or even sabotage their software, we can still discuss
with them, or if they don't reply, act accordingly by patching their
software or trying to gather volunteers from many distributions to
fork the software that is not maintained anymore. If upstream includes
nonfree software or has dubious legal practices we can often patch that
away. All these are dealt with.
Discriminatory upstream on the other hand is a problem that looks
different as many of the ways we use to deal with disagreements
with upstream as downstream simply don't work anymore ("send a
patch" is not as simple anymore as it also depends on what individual
sends the patch and not on the patch content or purpose).
And personally what matters to me is not necessary the outcome of
Xlibre or even the specifics on how to deal with software that has
extremely toxic maintainership but rather that we have each other's back
and not engage in direct or indirect discrimination or attacks of each
other when we are in the same boat.
For instance if a way I didn't think of is found to make the
discrimination go away in a reliable way, that would also work for me
(there could be more than one way to do it).
Denis.
pgpEv5J4fCA9m.pgp
Description: OpenPGP digital signature
