[GNU-linux-libre] Proposal on how to deal with flexible and rigid rules with packages, Was: Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines".

[Denis 'GNUtoo' Carikli]

On Wed, 12 Jul 2023 22:02:27 -0400
Richard Stallman <rms@gnu.org> wrote:
>   > Here we already have everything we need to reach a conclusion
>   > about ScummVM without bringing in rationale that are too much
>   > subjective.  
> 
> That may be so now for ScummVM, but if you're proposing the goal of
> using a rigid rule to eliminate all judgment about cass and their
> consequences, that is misguided as explained it my other messages.
> Such rigidity could lead to clearly wrong results.
Here I'm trying to find ways where the distributions would be able to
deal with software like ScummVM in ways that are not controversial
(that doesn't end up in heated discussions), and that are simple enough
to deal with. 

I'm not necessarily for or against flexible or rigid rules, I'm just
trying to find a context to make all that work. And in some context
rigid rules work but not flexible and in other context it's the
opposite.

If the idea is to adapt what to do based on the precise package, I have
a proposal:
- If the package is an absolute no-go (like there are 0 use cases with
  free software and it's not meant for reverse engineering), then it's
  easy to justify that and just remove it. I think we don't need to
  discuss that case as that is already handled by FSDG distributions.

- If the package has use cases with free software, but still somewhat
  steers users toward nonfree software, then it would be a good idea to
  advise the distributions remove that package and set requirements to
  add it back in a way that doesn't steer users anymore toward nonfree
  software.

For the later I don't see any issue unless you think that for some
reasons the name of the package is problematic. 

But in that case "rename the package" could be added to the list of
requirements to be advised for. And if the name of the software itself
is problematic, we could add "fork it and change the name" or "patch
it to change the name" in the list of advises on how to deal with that
package.

> First, suppose that next month we discover one game that uses ScummVM
> and is indeed free software.  Would that alter the fact that ScummVM
> has little use except to promote nonfree software?  Should we have
> rules that require us to change policy and encourage distros to
> include it, because of that one free game?
> 
> No.  We should continue to urge distros not to include it, even if its
> actual utility in the free world is tiny rather than exactly zero.
Given the (little) importance of ScummVM, I don't think we need to urge
distributions to package it at all even if it didn't steer users toward
nonfree software. 

It should rather be the people who care about ScummVM or that newly
found free software game that was discovered that would need to deal
with it, if they want ScummVM.

And for dealing with it, if ScummVM can be modified in a way that
doesn't steer users toward nonfree software, I see no issues with
advising distributions to either remove ScummVM completely, or of
advising them to set requirements for people that want ScummVM to
do the modifications that reduce the steering toward nonfree software.

Here:
- We have less probability of creating controversy, flame wars, all of
  which have impact on people's health and so on the distribution
  health.
- It makes FSDG distributions and the free software movement stronger
  by enabling more collaboration with groups of people having different
  needs (gaming, advocacy via games, etc). And that in turn can bring
  more contributors (because new contributors that find these use case
  important join, or don't leave the project with a big disagreement).
  And in turn that covers more use cases that attract more people.
- It explains clearly in a positive way why it was removed.

> Second, consider all the programs that use third-party package
> managers that include nonfree software.  Each of these programs would
> be excluded from free distros right now if we applied our rules
> rigidly.
With what I propose here we could tell that we need time to advise what
to do with each one of them. And so I see no issues. It would also make
the current situation more clear.

> The fact is, we have made an arbitrary exception for them,
> because we could not take on the matter of fixing those problems.
>
> That was not right, but we never built up the will to do any better.
>
> We should stop making that exception and fix these problems instead.
> But that will take some years.  We should continue the exception, for
> each package manager, until we have fixed it.
What I propose here is compatible with having a temporary exception for
these programs until we find a better solution: we could just tell
people that we need time to look into them to advise the proper way to
fix them.

The fact that GNU is discussing that to try to find ways to address
the issue one third party repository at the time is also consistent
with all that.

> The drawbacks of a strict rule are more bearable on a small scale.  We
> can and should be strict in rejecting nonfree software from within a
> package.  But strictness about third-party package managers would be a
> mistake.  We have to be flexible so we can make a plan to fix those
> problems, over time, but not be unreasonably rstrictive until then.
What bothered me is that the flexible rule was about removing not
fixing programs. This is what makes all the difference here.

A flexible rule about removing makes it look like a court of justice
that advise to remove this or that program and people might find it
unfair and authoritarian that there is a advise on this program and not
that one and so on, or that "I have a perfectly valid use case with
100% free software" and are mad about the software being removed
without any way to bring it back.

And if we look at the case where (some) distributions don't follow the
advises anyway, we're still way better off with the list of requirements
because if the argument is really about the 100% free software use
case, a valid way to follow the advise would be to fix the program
and this way only the nonfree software use cases would be prevented.

So here people would be happy about the recommendation anyway or wound't
have griefs against it unless their goal is to run nonfree software, but
then then could not take the 100% free use case as an excuse anymore,
so it would filter out heated discussions like that and not worsen the
community health.

But if the idea was only to remove things, without a list of
requirements to bring them back, I'd have preferred some simple rigid
rule instead because there is less side effects (especially on the
distributions, contributors and users health). 

And if we look at actual practices:
- And we already have rigid rules in place for non-controversial
  software with 0 free software use case and that works fine.
- Some software (linux-libre, browsers based on Firefox, etc) already
  do modifications that aims to not steer users toward nonfree software.

So what I propose also works fine with our existing practices.

Denis.

pgp9FWJOLEYC2.pgp
Description: OpenPGP digital signature