gnu-linux-libre
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: bill-auger
Subject: [GNU-linux-libre] is this work-group still serving the community?
Date: Mon, 4 Oct 2021 05:52:51 -0400

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

[yes, here i go - banging my head on this brick wall, AGAIN]

the practical (if not hypocritical) effect today, is that FSDG
compliance and participation in this work-group, are required
only to become endorsed initially, then both are optional
afterward; although the FSF has confirmed that the FSDG is
intended to be binding, perpetually

the recent (january 2021) NMAP roll-back is a clear example
(but long-time readers of this list are aware of others) -
according to the FSD, the license of the NMAP program is
unacceptable; and the entry was hidden, with this excuse on the
discussion page:

> "This software has failed the license review due to a defect in
>  the official license. We hid the page to prevent accidental
>  downloads of non-free code while we investigate the issue."

the roll-back recommendation on this mailing list, was given as a
temporary solution "until we get things resolved"; although
strictly speaking, if it needed to be hidden from the FSD "while
we investigate the issue". then FSDG distros should have been
asked to delete it "until we get things resolved"

so, the current FSDG recommendation has been in direct
contradiction with the FSD entry for 10 months now, on a factor
which is identical and essential to both - if there is any
single factor, about which the FSF should _never_ be
self-contradictory, it is that one (what are the four freedoms,
and which licenses are known to offer them, and which are known
not to) - as the FSF licensing department oversees both projects,
the FSD and FSDG should always agree on which licenses are
acceptable

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)

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)

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?

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

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

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

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

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

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

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

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

sorry to go on about that at such length; but the only valid
reason to interact with any defunct work-group, is to try
invigorating it - we really need to re-kindle this old
discussion - the current situation is very discouraging, and
should have been resolved years ago - "discouraging" is too kind
of a word actually - it has been so long now, that participation
in this work-group has become "disgusting" and "embarrassing",
IMHO



reply via email to

[Prev in Thread] Current Thread [Next in Thread]