Re: [GNU-linux-libre] is this work-group still serving the community?

[Denis 'GNUtoo' Carikli]

On Mon, 4 Oct 2021 05:52:51 -0400
bill-auger <bill-auger@peers.community> wrote:

> unfortunately, the FSDG simply "has no teeth" today; and FSDG
> non-compliance is inconsequential - even if all FSDG distros
> _must_ take some action, in order to remain in compliance, most
> distros do not read, share insights, nor ask questions on this
> list; and the FSF does not enforce the conclusions of the
> work-group, even in cases where the FSF has eventually made
> them explicit (notably, the requirement of applying the accepted
> liberation treatments on the LOSTDNRTFSDG), and not even when
> the recommendation was given as a direct explicit order (the NMAP
> issue) - this has resulted in some very obvious examples of
> deliberate disregard of those recommendations, by multiple
> distros
Probably more than a decade ago, ReactOS was in the list of non GNU
distributions and got removed because had nonfree software in its
"package manager"[1].

At the time I just reported the issue and after some heated
discussions (due to incomprehension), and at the end ReactOS got
removed.

The discussions (and my involvement too) were meant to get the problem
fixed, but instead ReactOS probably chose not to fix it and got removed.

The main issue here would be to make sure that the issues are
deliberate and that this is documented and not due to a lack of time
from the developers, otherwise I fear that we would not have a single
FSDG compliant distribution left as all probably have bugs that need
fixing. In addition the guidelines don't state any time frame for
fixing bugs, so it's probably relative and subjective.

At least Parabola, Replicant and Guix do have bugs that need fixing. 
I guess that Trisquel has some too given that the best way to get things
fixed seems to be to actually send patches with the fix (and you
probably even get help with fixing your patches in that case). So I
wouldn't be surprised if all or almost all the distributions have
pending bugs that no one is working on fixing.

The solution for that is probably to try to get new people on board too
to help with these. An idea for that would be to find way to help
people get involved. 

For instance it could be through physical social events where we help
people getting started and explain them how to best review source code.
It could also be through writing documentation. Though for the later it
probably need to be thought about a bit too as it probably depends a
lot on the context (there are things specific to build systems,
programming languages, hardware, etc).

That however won't work at all if the distribution does want nonfree
software for a reason or another.

[...]
> distros which distribute NMAP did roll it back, but of their own
> volition (or implicitly, in the case of pureos, as their NAMP is
> apparently taken from debian) - that is fine; but then guix
> moved it forward, apparently without asking the FSF if that was
> acceptable (or if they did ask the FSF, no one bothered to share
> that information with this work-group, where the question
> belongs, for the benefit of other distros)
Would it work if we try to send a patch to revert that change? 
What if we try to make Guix maintainers react to that somehow (by
writing to Guix mailing list after having tried the patch) to have at
least a clear statement on their positions?

With such statement we could then escalate much more easily. With the
ReactOS situation I even took a video of the installation of a nonfree
software to prove that the stock package manager was really problematic.

So people could see by themselves what software was being installed and
how it looked like without having to install ReactOS by themselves or
look at the technical infrastructure behind it.

> i have asked for an update multiple times on this mailing list
> (march and april 2021) - i then asked again in july, in the form
> of a formal ticket in FSF licensing department - as of october, i
> have received no response (other than the automated ticket
> confirmation) - therefore, parabola still has the rolled-back
> version and will remain at that version indefinitely, until
> either the FSF "lets us off-the-hook" by accepting the NMAP
> license (and letting us know that they did so), or that version
> of NMAP becomes so ancient that it no longer works on a parabola
> system (whichever event happens first)
If it's not already done somewhere else (like in Debian for instance),
we probably need to fork nmap in the meantime. The question here is if
we could have the resources to do that and/or if forking it would gain
us time as we would share the maintenance with other distributions. Most
distributions already have hosting for git repositories, and some might
be able to create mailing lists. 

The maintenance could work in the lightest way possible: people would
review code and the maintainers of the fork would accept or not that
code. This way if nobody sends patches, the overhead is almost null.
Though it must be clear that the software is maintained even if 0
patches arrives. It would also need people to actually review the code
which might not be trivial to find unless distributions have to patch
nmap anyway.

> frozen software is acceptable for LTS distros; but it violates
> the expectations of rolling distro users, and would violate the
> parabola policy of maintaining feature parity with arch, if
> parabola policy did not grant the FSDG precedence over other
> policies (and the desires of users) - so, guix users have been
> enjoying the latest NMAP software (as rolling distro users
> expect) for most of this year, while parabola users are being
> penalized for parabola's loyalty to the FSDG - great system we
> have going here, aint it folks?
The issue here is that the more issue like that we'd have the less
relevant FSDG becomes as every distro would be pushed really strongly to
add back nonfree software or non-FSDG compliant software. And the
burden increases a lot on the distributions that do everything they can
to follow the FSDG until they finally give up. 

In the contrary, the more distributions are united and help each other,
the less burden there is. 

And in some cases nonfree software are a huge pain so there is also
burden in having nonfree software. In Replicant for instance the
devices we currently support, the hardware enforces the bootloader
signatures. And the nonfree bootloader is a huge pain for a lot
of reasons. We'd rather replace it by a free software version of u-boot
for instance.

> it saddens me deeply; but this work-group is effectively
> defunct; and is practically of no concern to the FSF or FSDG
> distros - "evidence to support that claim?", you ask? - ok:
> 
> 1) the only distros which i have seen participating in this
>    work-group, since after after the hyperbola review in 2018,
>    are parabola, proteanos, replicant, and some others which are
>    waiting for review - the linux-libre team, though not a
>    distro, deserves an honorary mention for participating
As far as I know there is no obligation to participate in
GNU/Linux-libre and personally I wasn't even sure for a very long time
(years) that it was the right mailing lists for questions about the
FSDG in general as Replicant is not a GNU/Linux distribution and it
doesn't use linux-libre either.

I found out only very recently (months ago) that it was the right place
while discussing with people to try to find places to discuss about the
questions I had. Before I even asked some questions to the FSF legal
team directly.

So maybe we need to make it clear that the decisions for the Guidelines
are in practice taken in this mailing list, and that it's not just a
space to discuss things between the GNU/Linux distributions that are
FSDG compliant.

Ideally FSDG (instead of gnu-linux-libre) could be somehow in the name
of the mailing list, and if it's not possible to retrofit that, we could
probably have a description that explains what it is about.

> 2) some of those distros in wait, have passed community review,
>    but have been waiting since early 2018 for their "brief final
>    review" from the FSF
> 
> 3) one of the distros per (2) has gotten no response to inquiries
>    since 2019
> 
> 4) the other distro per (2), had enough time to decide to cancel
>    the project, rather than to have a next LTS release
Could we the community somehow take over for that? We could probably
handle it like free software project by starting with people that know
how to review distributions and enable more and more people to take the
final decision. The ability to directly push code or agree to code
being pushed often work like that.

In the community of FSDG distributions developers, we have people that
do work to fix freedom issues, so we probably have the people that know
best how to do it in practice.

> 5) other than the one message regarding NAMP, the FSF has given
>    no input on this mailing list, nor taken any action WRT the
>    FSDG, since 2018, although asked to do so repeatedly, for each
>    of multiple important topics
In my case the community also had the answers to my questions and so I
took the rough consensus as guidelines that should be applied in
practice.

> 6) even that one NMAP issue was left dangling, with no discussion
>    nor resolution, for nearly a year now - not so much as a
>    "please wait a bit longer", when asked repeatedly for an
>    update
Here as I understand, there are two issues which could be separated.
The FSF lawyers probably need to review that license, and if it's not
obvious that the license is free or nonfree we cannot do much about it.
For instance I'm not a lawyer and I don't know many lawyers who
contribute to FSDG distributions, or other lawyers with the kind of
knowledge that the FSF has.

However we can take mostly consensual decisions on what to do with a
license whose status is unknown, and actually send patches to not have
any excuse not to enforce the decisions.

Note that I had to review many licenses for my work on FSDG
distributions, and simple clauses like forbidding reverse engineering
or commercial usage makes it nonfree so theses cases are trivial. The
same applies to many weak free software licenses that are somewhat
similar, these are easy. If the license is too complex I would need to
ask to the FSF lawyers who probably have the best expertise on that
topic. 

And I do ask for help with legal questions when it is necessary, at
least for Replicant. For instance in order to create Replicant I even
asked them about the situation where the author of a work told me what
license that work was under through mail, and that legal question was
crucial to make the audio work on the very first device supported by
Replicant.

> 7) although the NMAP issue has not been resolved (or the FSF is
>    neglecting to tell us that it is resolved), the FSF is not
>    enforcing the standing recommendation to freeze it, further
>    cementing my lament, that FSDG compliance is optional
Same as above, we could take over here, and the decisions that were
taken by rough consensus were justified and so I don't see why we
cannot manage to do it in this way. If the FSF then really wants to
intervene they can also do it since it's a public mailing list.

> frankly, when the FSDG recommendation comes directly from FSF
> chief licensing officer, that is more like an "order", than a
> "recommendation"; and if that order was made publicly, distros
> which dispute it, should be obligated to dispute it publicly, on
> _this_ mailing list, before taking _any_ contrary action
> 
> if distros are to decide for themselves, which software and
> licenses are libre; then the FSDG has no credibility
It depends on how it's done. If the decisions are well explained, for
instance on this mailing list and decided through rough consensus, I
don't see why this would be an issue, quite the opposite.

The advantage of having the people involved in the distribution also be
involved in taking decisions could enable these people to learn more
about the FSDG and be better distributions maintainers and actually get
it more enforced than less. And sharing ideas about how to technically
implement the decisions is also crucial to get things done in my
opinion.

> - if the FSDG is to reclaim any credibility, and if this work-group
> is to reclaim any efficacy, we need to drastically improve
> cross-distro communication and participation in this work-group,
> and (or at least) for the FSF to complete their "brief final
> reviews" in a timely manner, to make some difficult decisions
> when necessary, and to "show it's teeth" when prudent
> 
> unfortunately, we, the community, can not do this on our own -
> as a pre-condition to alleviating this group's dysfunction, the
> FSF would firstly need to "grease their squeaky wheels", as they
> say, and help us to reform the FSDG process, so that distros
> have some incentive to remain in compliance and to participate in
> the work-group
As I've seen in the threads I was involved in we have all the skills
necessary to review source code and take decisions for the FSDG and we
see it from the distribution point of view, so where it should actually
be enforced.

Since some of the decisions also have to take into account the reality
of working on such distributions (you probably saw how Replicant was
different for instance) distributions do need to be involved.

The FSF expertise would also be very welcome as well, especially when
we need or want to do things that are outside of the ordinary.

> if the FSF has not enough time to manage the FSDG work-group
> properly, then it should grant more authority to the work-group
> volunteers, or at least to a committee of elected representatives
> of endorsed distros - the changes in early 2018 were an excellent
> step in that direction; but it stopped far too short apparently
What if the FSF has not enough time to do that either? Could we try to
come up with something that works by ourselves and only have the FSF
intervene only if they feels it's necessary to do so?

> several of us have discussed this over the years, are willing to
> participate in such a committee if necessary, and have _begged_
> both donald and RMS to do _something_ (_anything_) to resolve
> this dysfunction; but still our hands are tied by bureaucracy -
> there are even some proposed amendments to the FSDG drawn out,
> which would help, and everyone who has seen them is in general
> agreement that something of their essence should be ratified;
> but there is literally (and ironically) no point in posting them
> on this mailing list, until there is some indication that the
> gears are turning
We could just try to do it and see how they would react. Maybe they
would react positively. Maybe they are too busy. But in any case it
could get things moving in one way or another because if nothing
happens from the FSF we'd be the one moving things.

We just need to be super careful not to mess things up more than they
already are.

Assuming that we already have good guidelines to review distributions,
If we need to add a distribution, we could for instance produce a very
clear review of it and then simply ask the maintainers of the gnu.org
website to do the changes to add the distribution. We could also add
our sign-off to it in order to prevent huge mistakes from slipping in.

If needed we could also improve the review guidelines along the way,
for instance to add more things to check for.

To remove a distribution we could probably try to get patches merged
and try to get statements from that distribution for why they are not
merged and somehow force them to discuss that. And if they want to keep
nonfree software we could also ask the gnu.org website maintainers to
remove them.

Now the question here would also be to understand who is legitimately
representing distributions. The FSF has a quite neat process for
that that Replicant is part of: the distribution itself can choose
who represents the distribution and how. For instance for Replicant we
have a steering committee of 3 people that can vote to decide things on
behalf of Replicant. But the distributions could probably also have
other systems, for instance votes, consensus, etc.

We probably also need to get some expertise on how to do something like
that in general from the people who are already doing that and that
have interest in making the FSDG guidelines trive (else it could also
be risky if we ask people that are against the FSDG guidelines).

References:
-----------
[1]While the GUI looked like a graphical package manager the underlying
   looked more like that:
   wget https://[...]/software.exe;chmod +x software.exe;./software.exe.

Denis.

pgp_Qsekye8Gq.pgp
Description: OpenPGP digital signature