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

[Denis 'GNUtoo' Carikli]

On Sun, 31 Oct 2021 21:03:22 -0400
bill-auger <bill-auger@peers.community> wrote:

> ive read both licenses and they both appear to be lacking some
> of the four freedoms, very explicitly - the key to this issue is:
> "who decides what is libre or not?" - IMHO, such decisions
> reduce to nothing more or less than: "does it offer all four
> freedoms?" - i prefer the latter; because it has an objective
> answer, and the criteria come directly from the FSF
In cases that aren't crystal clear, legal expertise can also help, and
AFAIK FSF lawyers also have that expertise.

In some cases we need to understand what the license really does in
order to understand if it offers all 4 freedoms.

> the FSDG work-group does not need to make such decisions, and
> neither do distros - the evidence and liberation procedures are
> usually so clear, that they never get discussed outside of each
> distro - for the most part, it is simply amortizing the
> work-load of discovering the relevant objective facts about, and
> liberation procedures for, some contentious programs; then
> presenting them to the FSF for final decisions, if necessary
> 
> rather than each distro repeating the same auditing work and
> deciding for itself what "libre" means; it would be more
> efficient if a collaborative team audited contentious software
> for all distros, and presented the results to the FSF for the
> final decision, binding upon all distros - IMHO, it would be more
> respectable as well; because it demonstrates a base-line
> consensus among the FSDG distros, regarding the minimal
> liberation procedures
We probably don't want the FSF to verify all the work we do as it would
increase even more their work load. And in some cases we might
need to fix things fast (because it broke the boot or that we need to
fix a security issue) and we might not want to wait until somebody from
the FSF reviewed all the details of our work.

Though I really like the idea of sharing the work between the
distributions.

The question would also be how to share it practically speaking. 

For instance for Linux, there is the linux-libre project which
removes nonfree software but it also goes beyond that (so Replicant
doesn't want to use it as-is for instance). In any case distributions
can reuse it if they want to.

Right now it's available as released tarballs, git repositories, and
even deblob scripts. So if you don't need or want to modify it, it's
reusable by all FSDG distributions very easily.

I wonder if something like that which creates the deblob procedure in
various forms (scripts, already deblobbed tarballs or git repositories)
and for each versions (linux-libre even covers RC releases) could scale
for many projects (if it's automatized it could probably scale).

Or maybe we need to get there step by step? 

In Parabola for instance if we have our deblob instructions in an
mksource() function in the package definitions. But that content could
also be moved to scripts to enable other distributions to reuse them.

The next step could be to move these scripts in git (and tag them with
the upstream release version) and release them as scripts too and
release deblobbed tarballs too like with linux-libre git.

Alternatively we could also make some standard to encode our work of
analyzing the packages source code (if there isn't already).

As part of my work on Replicant 11 (which is funded by NLnet) I also
need to find and remove nonfree software, and I was also pointed to
automatic tools to detect licenses (ScanCode and Ruby Licensee) by
someone working at the FSFE, and I want to try them.

I've also tried some manual (like looking for specific things,
or grepping for anti-reverse engineering clauses) and semi-automatic
ways to do that (auto-detecting projects wide licenses).

Maybe there are already tools that generate some parsable output of
licenses analysis for projects as SPDX isn't used everywhere and
AFAIK it doesn't have all the free software licenses either (as there
is some political contention about that).

> thats not to mention, that these are among the grunt-work for
> any distro - its not the fun or sexy stuff that any dev perfers
> to spend time on - people should be eager to pool their efforts
> on these boring administrative chores
We probably also need to make sure that the collaboration will all gain
us time instead of making few people do more work (often to make sure
that your work could be reused more broadly you need to put in more
work) and other just waiting to reuse it and having these individual
burn out.

> in contrast, jean is arguing that it is better for each distro to
> decide for itself, which programs are libre (or that some
> distros may be "more than 100% libre") - that is purely anarchic
> though, which makes the FSDG meaningless (as it would for any
> conventions, guidelines, or standards) - and it results in each
> distro doing redundant work
You probably meant anomie here as Anarchy seems to be pretty well
organized (with rules to counter things like systemic bias like sexism,
rules to enable self-rule, to take collective decisions, etc), and it
seems to be pretty close to what we want to organize here (making the
distributions take collective decisions and work together).

> i believe that most FSDG issues are purely objective questions
> with clear answers and solutions, requiring no re-interpretation
> of the FSDG; so any conflicting interpretation would be easily
> proven erroneous
>
> eg: which licenses? 
>     which files do each license apply to?
>     are these two licenses compatible?
> 
> in most cases, there should be no disagreement about such
> obvious properties
I think that there is still a lot of subjectivity in some corner
cases, but I completely agree with your conclusion as it would make no
sense to decide that per-distribution or even per contributor.

Instead having different people discuss the corner cases could help us
come to better conclusions and we'd probably all learn in the process
as well and become better at it.

Denis.

pgpfgpVRFz7pq.pgp
Description: OpenPGP digital signature