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

[Denis 'GNUtoo' Carikli]

On Mon, 12 Jun 2023 06:30:36 -0400
bill-auger <bill-auger@peers.community> wrote:

> 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 misunderstood then.

> 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

That makes things much simpler because having a general rule meant that
at some point it would probably apply to other less clear cases, and
that could cause issues. And having some rules that would apply only to
games would also not be very consistent unless it was very well
justified.

Especially if we had to weight usefulness of software use cases for
software that we don't know in depth.

If it's distribution specific, there are probably less costly ways to
revert or revisit decisions. And distributions can try different
approaches. So that doesn't put all the eggs in the same basket and we
could probably observe the long term benefits or issues.

And in this case it also enable people to do the work in specific
distributions to have their 100% free software use cases covered.

> 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,
Recently, I've updated a bit the documentation about that[1] as that
documentation assumed that the mere existence of an application or game
under free licenses was enough to make a free emulator OK. The existence
of a non-FSDG distribution that run on a game console was also making
the free emulators OK.

So I've changed the article make the emulators OK only if we have 100%
free software without nonfree dependencies or FSDG distributions for it.

To do that I also documented if there were known free tools to build
programs for the emulators, or what work was missing (reviewing
software like the games under free licenses mentioned before, what was
missing to make FSDG distros work on gaming consoles, etc).

I've also added well know emulators (like qemu) that have no issues as
it's also good to remind people that some emulators are perfectly fine.

So maybe that article needs to be improved a bit, at least to explain
that the way to go would be to package applications for the emulators
inside Parabola (or other FSDG distributions).

> 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
What is interesting here is that in most cases the problematic
emulators also lack proof that 100% free software can run on them. So
that is probably enough to blacklist them anyway.

> 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
That is very good as it can help protect users. I would have no issue
if things like your-emu-freedom were installed by default.

> 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)
The way to go here is indeed probably to review applications and games
that are under free licenses to make sure that they can be built and
run with 100% free software. If they are packaged the emulator could
even be a bit hidden when possible by for instance making a script or
.desktop files to launch the game inside the emulator directly, so
users would just see the emulator as a dependency like any other
dependency and not directly interact with it.

> 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
I agree. I've started looking into docker a bit but it'll probably take
time until I manage to understand how to run a public docker image
repository (I can run one locally but I need to learn how to enable
people to download images unauthenticated while also requiring some
authentication to push images).

> 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`
What I was pointing out is that there is a part of subjectivity.

With docker things are not that easy[2]. Beside using Guix to create
docker images of packages (this is relatively easy to do), there is
also the option to run Guix services in docker but probably very few
services (like SSH) work fine.

Users can also download PureOS images[3] (from docker hub, which
also contain nonfree images), or make their own Trisquel and Parabola
images with the debuerreotype or parabola-docker programs.

But compared to the amount of nonfree images available or the
wide spread usage of non-FSDG distros used in Dockerfiles, that's very
small. Yet that small use case can also be extremely useful to some
people. So there is a subjectivity part here.

And in the case of docker I think that we should keep it in some form
(for instance it could be patched to not use docker hub by default).

> 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
So far that works great with Guix, but not with other distributions yet.

Fedora has managed to run a docker images repository that also work in
Flatpak, so maybe there would be some way to do something similar and
make some FSDG compliant distributions graphical packages available to
other distributions in the same way.

> 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
It is not the same arguments, as in Parabola, docker has been patched
not to refer to docker hub by default. It's not patched yet in other
FSDG distributions though.

So docker is configured not to refer to any third party repositories by
default. The user then has to specify the full URL of the image (like
with 'docker pull registry-1.docker.io/pureos/byzantium'). 

But the ability to download and run images from docker hub or any
other existing repository still exist. So beside the fact that it
downloads the software before running it, it's more similar to Wine
than pip.

For pip, my rationale about doing something about it in the long run was
this part of the FSDG:
> The system should have no repositories for nonfree software and no
> specific recipes for installation of particular nonfree programs. Nor
> should the distribution refer to third-party repositories that are
> not committed to only including free software; even if they only have
> free software today, that may not be true tomorrow. Programs in the
> system should not suggest installing nonfree plugins, documentation,
> and so on.
But maybe I understood it wrong, and having a discussion about that
would be a good way to understand what strategies are best to get the
problem fixed in the long run.

As for pip being removed, the discussions about third party package
managers were not very calm due to various misunderstandings, so maybe
it would have been better to discuss strategies that are compliant with
the FSDG in a more calm way and come up with better solutions, like to
have a plan to patch these, that are consistent with the FSDG.

That also assumes that I understood the FSDG right, and that's not
necessarily a given here as I was pointed later on that there were
multiple ways to understand that part of the FSDG.

Note that at the time, I understood the outcome of the discussion in
Parabola about third party package manager as a choice between
deliberately not respecting the FSDG and removing all applications with
third party package managers regardless of the freedom of the
repositories.

So to me only removing the ones that referred to repositories containing
nonfree software looked way better than officially choosing not to
respect the FSDG or removing everything that refereed to third party
repositories.

Though I'm open to revisit our strategies about that as the current
state of affairs is far from optimal. We also need more collaboration
in general to be able to take better decisions (like collaborating on
patching instead of removing or never fixing).

Another way would be, if I was wrong about the FSDG, to inform users
that none of the third party repositories are vetted by the
distribution, and still try to document at least 100% free repositories
somewhere (like on the Libreplanet wiki, in some FSF/GNU article,
on distributions wiki, etc). 

This way users will know they are on their own (like when they download
software from websites that have nothing to do with the distribution)
and this can also work for people that want to run only free software
assuming that we find good ways to make sure that users are informed as
this issue is not necessarily obvious for everybody.

> 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 think we need to do that indeed. First to make sure we understood the
FSDG right, and to find good ways to fix the problem in the long run
with less controversy.

References:
-----------
[1]https://wiki.parabola.nu/Emulator_licensing_issues
[2]https://libreplanet.org/wiki/Group:Software/FSDG_distributions/DistroExecutionEnvironments#Running_distributions_in_a_virtual_execution_environments
[3]https://libreplanet.org/wiki/Group:Software/research/ExternalRepositories/DockerRegistries#Review_of_images_on_non-fsdg_compliant_registries

Denis.

pgpYfOgehesrc.pgp
Description: OpenPGP digital signature