Re: [GNU-linux-libre] Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines".

[bill-auger]

On Mon, 12 Jun 2023 01:35:14 +0200 Denis wrote:
> Richard Stallman <rms@gnu.org> wrote:
> > I think the question at hand is a little different from that.
> > I don't think that _some nonzero amount of free software that runs
> > on the environment is necessarily enough to outweigh the fact
> > that its main use is as a way to run nonfree software.  
> 
> But what I'm concerned here is more the long term side effects of a
> rule that requires to weight the usefulness of software and use cases

i think though, that no one suggested making a rule about these - as i
remember, the original topic of this thread (the original "question at hand")
was to determine whether or not the games, which debian has deemed "free" (eg:
'bass'), are also acceptable by the FSDG (a practical concern) - IIRC, it was
determined that they are unfit - the discussion then drifted to the broader
issue of how (or if) that affects the free game engine's legitimacy (a
philosophical concern)

i offered only the practical perspective - namely, that these pose no certain
impediment to software freedom; so it is of no specific concern per the FSDG -
in which case, distros may decide it each for themselves; and a valid argument
against them, is simply supply vs. demand (or: workload vs. desirability) - the
absence of ready-to-use free games, decimates the demand (desirability) for
ready-to-use binaries of the engine; and so the importance of supplying them is
very low

the other arguments posed, along the lines of encouraging use of the non-free
games, are more philosophical or political than practical - that aspect of it
has been discussed over the years, more than the practical aspects

i can offer one example - about ten years ago, the parabola devs had that
discussion and made a decision - they introduced a conflict-inducing
meta-package 'your-emu-freedom', which prevents the package manger from
installing reverse-engineered emulators for proprietary gaming hardware and
1980s-era home computers - that decision was on the basis that although some
free software does exist for those emulators, the vast majority is non-free
(illegitimate "rips" of original game ROMs) - given that parabola never
distributed any software for those emulators; their presence in the repos has
always been a suggestion to acquire software from a third-party - parabola
generally recommends against acquiring any software from any third-party (free
or not); so the presence of those emulators in the repos was always dubious,
and ripe for controversy

however, as a "rule", those emulators were not excluded; and the guard package
is optional - it was decided not to impose that philosophical/political
decision onto users (ie: it does not need to be a rule); but instead, to let
each user decide whether these dubious emulators posed a risk to their freedom,
with the optional 'your-emu-freedom' meta-package serving as an educational
warning and guide

of course the option remains to write some new software for those emulators
yourself; but practically speaking, that requires learning some specialized
esoteric programming language or machine code for those obsolete CPUs - the
use-case of playing the many readily available games, is itself very small -
the use-case of writing new software for those machines is much smaller, as to
be negligible IMHO - i contend that unless the distro offers some free software
for use with the free tool, the presence of the free tool suggests its most
popular use-case (acquiring some from a third-party which does not follow the
FSDG)

therefore IMHO, this reduces to the TPPM problem (generally: a free program
which primary use-case is to support a third-party curated, and/or primarily
non-free class of software) - in other words, the docker example is analogous,
but far more relevant than any game machine emulator, due to its popularity and
utility - we would be much more productive to focus on offering curated
software for those TPPMs - these game engines on their own, are hardly worth
this much discussion


On Mon, 12 Jun 2023 01:35:14 +0200 Denis wrote:
> Since most of the docker images are not FSDG compliant, do we remove
> Docker completely? Since Guix can also generate docker images 

that case seems significantly different; because the tool itself offers an easy
way to generate the guest software automatically, with essentially no input nor
expertise on part of the user

eg:
  `docker create trisquel-11`
or:
  `guix create docker`

with a bit of modification, docker could generate images with software
exclusively from the distro repos - that would be the ready-to-use equivalent of
"some libre games exist for scummvm, _and_ the distro distributes some of
those"; which we now know can not be satisfied - in the case of docker, pip,
and the many other TPPMs, it could be satisfied


On Mon, 12 Jun 2023 01:35:14 +0200 Denis wrote:
> And if we don't cover these use cases in FSDG distributions, it would
> give more advantage to non-FSDG compliant solutions and push people
> toward them (for efficiency reasons for instance).

not to drift off-topic, but i would point out that this is the same argument
people gave when the parabola devs (namely: "gnutoo") decided to remove 'pip'
from parabola's repertoire; though in this case, gnutoo is employing the same
rationale to suggest keeping the controversial tool

due to the popularity of 'pip', some users lamented that its exclusion makes
parabola less useful to python developers and sysadmins, who may be persuaded
to acquire the tool from a third-party, or to use another distro instead

FWIW, though i objected loudly at the time, i was in general agreement with the
decision to remove it (and the others) - my objections were due to the pain and
controversy incited by that move - the discussion of "what to do about TPPMs" is
long overdue to be revived on this mailing list

i see the FSDG concern of pip and docker as equivalent (TPPMs), and closely
related to that of emulators; so the arguments for and against them should
apply generally - both pip and docker would need to be treated, to allow them
use only FSDG-fitness curated remote repo sources, and IMHO, such repos should
exist, in order to justify their inclusion in FSDG distros - the main difference
is that the emulators would not need libre treatment (most do not suggest any
specific guest software or repos) - only the curated software would be needed,
to make those uncontroversial