[GNU-linux-libre] FSDG interpretations Was: review of uruk

[Denis 'GNUtoo' Carikli]

On Tue, 28 Mar 2023 21:49:18 -0400
bill-auger <bill-auger@peers.community> wrote:
> indeed, most of the review could be done now, and i think that it
> should be; but IMHO this distro should not be able to pass review
> on the face of it, due to the current circumstances - the FSDG
> status of pureos is contingent on the resolution of two major
> long-standing unresolved conflicts - i am not comfortable
> bringing in another with the same contingencies, until those
> conflicts get resolved
FSDG distributions can have bugs, but bugs also need to be fixed
somehow. So if a distribution doesn't want to fix an FSDG compliance
bug (it happened to ReactOS for instance), then it probably can be
removed.

And from my experience of contributing to various FSDG distributions,
if a distribution ships big number of packages or software components,
asking the current maintainers to fix all the FSDG compliance bugs at
once is probably not going to work because doing that would probably
require multiple people working full time on most FSDG compliant
distributions. 

For instance there is a lot of third party package managers, and fixing
all the issues can take a very long time. And many distributions have
FSDG compliance bugs that are open for years.

But maintainers usually welcome help, so if we provide them with fixes
that are really good and work out of the box, they usually accept them.

If they don't accept fixes because they don't want the FSDG compliance
issue to be fixed, then that is probably sufficient to get the
distribution removed.

Apart from that there are sometimes different interpretations of the
FSDG and these are more tricky, but there are things we probably didn't
try yet and that we might need to try to fix that.

Here a way forward would be to understand the goal and the spirit of the
FSDG and try to foresee the consequences of interpreting it in this or
that way, see how that affect distributions, users, and so on.

As I understand, anyone is able to send suggestions for modifications
of the FSDG.

But at the end we (all the parties interested in the FSDG) and/or
GNU/the FSF might also need time to reflect about all that and at the
end to propose drafts for wider review like it's being done for the GNU
ethical repository criteria, and like it was done through the
Libreplanet wiki before for the FSDG and/or RYF.

This mailing list might also be a good idea to discuss such proposal
with a focus on modifications of the criteria text (for instance to
clarify a point and with this clarification choose a given
interpretation), before proposing it to GNU and/or the FSF. And I don't
remember any attempt of that.

All I recall is discussions that were more focused about specific
packages of specific distributions (like Chromium in Guix and PureOS)
or more general questions (like is Guix and PureOS debootstrap
package OK) that didn't try to foresee all the consequences of multiple
proposed interpretations of the FSDG and try to weight them all and so
on.

The discussion on debootstrap only came up to a general consensus of
what was the right thing to do in this case, but without trying to
understand the consequences on other things like programming language
package managers.

And the discussion about Chromium might have had parts of what I'm
proposing here, but it wasn't the main focus of the discussion. 

If I recall well the various discussions, the main focus was if Chromium
was compliant or not, not the consequences of the interpretation of the
FSDG nor the consequence of specific modifications to it for clarifying
the situation with software or packages with either:
- An unknown license: Here there might be too many licenses involved
  and way too many dependencies to be able to understand the license.
- A known license that is impossible or very hard to check due to a big
  amount of source code, and no clear way to understand which files are
  under which licenses.

Other software or distributions or use cases would also be affected by
a decision on that.

For instance Replicant doesn't have precise licensing since it doesn't
have any packages definitions. Its source code consists of a directory
with many git repositories inside that are compiled together in various
binaries that are then aggregated in an installable image. A list of
license is then generated during the build and users can see the
licenses content in the settings menu. 

So here taking a decision on Chromium will also have an impact on
Replicant.

Distribution images such as installers, docker images, etc could also
be affected here. Though there could easily be an exception for
software merely aggregated together, especially if it's trivial to see
the license of each individual package.

Many software written in recent programming languages like go, rust, or
JavaScript with nodeJS also have way too many dependencies. So it might
be hard to either know or check the license in some cases. Here too a
decision affecting Chromium would have consequences.

A way forward could be to propose some modifications to the FSDG here,
in this mailing list, and to try to see if the proposal is a good or
bad idea, to try to improve it if it makes sense, etc.

For instance if I want to make sure that Replicant isn't excluded
because "small system distribution" is subjective, I could for instance
propose:
  We make an exception to this requirement for small system
  distributions, which are distros designed for devices with limited
- resources, like a wireless router for example.
+ resources, like a wireless router or a smartphone with limited
+ storage space for example.

Or:
  We make an exception to this requirement for small system
  distributions, which are distros designed for devices with limited
- resources, like a wireless router for example.
+ resources, like a wireless router for example, and for non-GNU
+ distributions that are not self-hosting.

And we would discuss the implications of the two proposals and see if
it doesn't add bugs or loopholes, or prevent new uses cases.

For instance what if PureOS (that is also a distribution for
smartphones) stops being self-hosted? Are we preventing embedded
software? Or small distributions for big computers (that could be
useful to improve performance in supercomputers, reduce resources
consumption, etc)?

And also does it really makes sense to modify the FSDG just for that
because no smartphones currently have 16GiB of RAM and 200+ GiB of
storage?

So here you or any other person interested could do something like that
for the issues you want to get solved, and at the end, it could be
reused to propose the final modification, with a summary of the
rationale, and a link to the thread to GNU and/or the FSF and see if
they accept the modification.

This way they could also participate in this mailing list too, at any
time (including after we'd propose the modification to them, or before
that too, or both).

What do you think of this approach?

Denis.

pgpwp5GTKmmAk.pgp
Description: OpenPGP digital signature