On Fri, 16 Jun 2023 22:20:46 -0400 Richard Stallman <r...@gnu.org> wrote: > We have found no reason to consider ScummVM's inclusion in free > distros to be a good thing, but there remains the question of whether > its inclusion is harmful enough to state a position or rule, and if > so, what that should say. A rule not to include it would be the > strongest possible response, but a software response might be better. > > I thimk that a stated recommendation to omit ScummVM might be a good > measure to take now. > > It could refer to the documentation's promotion of nonfree games, that > you cited, and say that at least that promotion should not be in the > distro.
Similar to Guix's decision on ScummVM, I think that the rationale could
be that:
- We don't know any free games.
- As far as we know, ScummVM has a checksum whitelist, so:
- If there is a free game whose checksum is in ScummVM it could be
OK. But we'd need to point users to that game in the package
description for instance.
- If people package an FSDG compliant game, they'd have to add its
checksums to ScummVM (at package build time for instance).
- If instead some people manage to write a hello world for ScummVM
and that the rationale is that ScummVM can (also) be used to write
games, then a patch would need to be made to enable scummVM to load
any game written by the user. And how to write a game would need to
be documented too.
So the current situation is that ScummVM steers users toward nonfree
games/software, because we can't direct them to at least a single
games/software or use case that is FSDG compliant with ScummVM.
And so we have everything we need here to get ScummVM removed either in
the short or longer term without having to decide which use cases
are more important than other.
And I think judging use cases is very important to avoid because:
- It is incredibly hard to weight use cases right.
For instance some people might remove virtual machines like qemu
because it is mainly used to run nonfree OS, while for other people
it's used for very different things like virtualization.
Here this example is exaggerated on purpose to explain better the
issue, but in practice it would likely be way less obvious and at the
end discriminate less well known use cases.
This in turn could lead to users having difficulties meeting their
use cases with FSDG compliant distributions and/or fragmentation of
users.
- Because it can potentially have nasty side effects, if the logic that
works well for one case is applied to another.
For instance if a programming language interpreter has more nonfree
software than free software written / distributed for it, it should be
removed if we follow the same rules than with games.
If it's not removed people might think that the process of removing
software is being abused and biased negatively toward games and be
shocked by the decisions. And if the language is removed, instead
people needing that language could also be shocked by the decision.
So I think it's better not to open this can of worms of judging what
use cases are more important than others, especially because in the
long run I don't see how to avoid the collateral damage that result
from deciding on use cases.
And here that collateral damage might not be visible but it would be
very real as the community would likely be less healthy and diverse and
smaller.
One of the issue is also that the discussion has been conflating several
points together like running nonfree games, running free games, if
games are important or not, how to write games, etc.
Here I'm assuming this is the case because some responses conflated
two or more issues together.
And that doesn't help seeing things clearly and it also tend to
misrepresent people's position, which doesn't help to calm down the
discussion.
Denis.
pgpixiZdeWD0J.pgp
Description: OpenPGP digital signature
