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 17:37:39 -0400
John Sullivan <john@wjsullivan.net> wrote:
> > What an exaggeration!  Writing a free game is a lot of work.  The
> > small preparatory task of getting and installing ScummVM would
> > hardly discourage anyone who is prepared to do that work.
> >   
> 
> Says who? If I have an hour to sit down and work on something, I would
> like to spend that hour working on the thing, not downloading and
> building dependencies, and then the next Friday when I have an hour, I
> have to see if the dependencies are updated, and rebuild them
> manually. And dependencies interrelate -- one of the main reasons we
> have distros in the first place. Manually maintaining some things on
> a system while other things are packaged is a notoriously fraught
> thing to do. Packaging is an important and valuable convenience that
> eliminates a lot of yak shaving.
For ScummVM you have to do that anyway. You need to:
(1) Build the IDE for AGI I mentionned.
(2) Find a template for it and audit the license.
(3) Start building a game

Building ScummVM looks really easy compared to building the AGI IDE.
The AGI IDE needs qt4, so you will probably need PureOS for building
and running it. And if you don't have PureOS you might need to use
docker or install PureOS in some other way (Parabola can debootstrap
PureOS, you can also install it in a VM).

> The discussion here is dismissing the relevance and importance of this
> *private* software. This is the dangerous path you go down when
> banning software from endorsed distros just because it doesn't have
> released, packaged free software for it. This private software could
> be released in the future as free -- but even if it isn't,
> facilitating private software experimentation and development is a
> free software value.
As I understand there was no general rule made for that nor about
forcing distros to remove software like wine that has perfectly valid
free software use cases despite also having more nonfree software that
works with it.

So it's up to the distro to assess the value of the software they
package. And as you point out that doesn't remove the rule not to steer
users toward nonfree software, so for instance the package description
could be adjusted not to do that in any case.

I'm unsure if the question of not having any free software for a VM
was addressed but it could make sense not to package VMs that can't run
free software as it would effectively steer users toward nonfree
software, so we don't even need to modify the FSDG for that, just to
clarify it.

So here if we require free software to run in VMs, for ScummVM it would
mean making sure that there is some free software for it. So in
practice you could package a free AGI IDE, and confirm that it
works by building and running a free software program inside ScummVM.

And once done it would enable people to easily write free software
games for ScummVM too, so I don't see any downside here of at least
requiring that.

Packaging the games might not be easy though as I don't know command
lines tools to build them. But at least the distribution could point to
third party repositories of 100% free games, or ship the games with
their source code without rebuilding them themselves.

As for private software I'll explain more why requiring free software
doesn't impact private software below.

> I think so, but I'm not sure. I didn't think the FSF was in the
> business of judging whether this is a good way to write a game or
> not.
Was a decision took by the FSF? By Richard? Or was it took by GNU? Or
did we take it by discussing it? It's unclear to me if any decision was
taken so far.

Richard only told that:
> I conclude that excluding ScummVM will be no loss to free software.
As I understand this is true.

But I'm unsure if it really forces distributions to remove ScummVM nor
to remove similar software. The way to go would probably be to follow
the procedure that are already in place and well understood by
distributions and have software to be removed added here:
https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines

And this page has the following:
> Please do not add a package to this list until it's been discussed on
> the gnu-linux-libre mailing list and/or with RMS. Some corner cases
> can be tricky to decide, and it's good to take time and make sure we
> have the right decision before listing something. Thanks for your
> help with this.

And here that removal could very easily be justified because we're not
sure that free software *can run* inside ScummVM. We're also not sure
that users writing private software can really do that at all. So we
don't need to weight usefulness nor say that this is a bad way to write
games, etc.

If you take a JavaScript VM for instance, users can easily write code
in a text file, and add a license header to it, add a copy of the
license, and it's done.

Here's an example (copy that in hello.js and run with 'gjs hello.js'):
> print("This software is released under the CC-0 License.");
> print("hello world");

So in most cases it's really trivial justify, and the proof can be
added in mails, commit messages, an whatnot. And when it's hard to
justify, then the free software in question becomes really necessary as
it can be used as a basis for other software too, like other free
software or private software.

For ScummVM how do we know running free software in it is even
possible? Do you also need nonfree software to make private software?

For instance we don't know if the templates for AGI games are free or
not since nobody reviewed their license. We don't know if the AGI IDE
still works in FSDG distribution, we didn't review its dependencies,
etc.

There is some amount of efforts required to do all that. And people
attempting to run free software or write private software for it might
find out that it's not possible without even more efforts or not
possible at all because some things are still missing. 

So that would mean that we would consider hypothetical software that
doesn't exist or that isn't audited as a valid substitute for free
software.

In that case all lock down computer hardware (games consoles, iphones,
etc) would be fine because FSDG distributions could hypothetically run
on them (with lots of efforts, that might turn out to be impossible
because nobody managed to break the security of that hardware to run
free software). Formats that can't be read with free software are also
OK because there would be hypothetical software to use them.

To be really complete, a VM that runs nor free nor nonfree software can
also exist (like with Malboge[1]) and writing software for it could be
made a challenge. But then if the first software for it is nonfree it
would steer users toward nonfree software (unless there is a mechanism
to enforce free software without dependencies).

So I see no issues at all with requiring requiring free software to be
able to run inside a VM. And for most cases it's trivial to prove. And
this also guarantee that you can run private software without nonfree
dependencies inside it too.

> This may be a niche thing either way -- these are not super
> popular proprietary games anymore either. But I don't see why people
> who appreciated these games before and now know about free software
> might not also be interested in working on free games to share, or
> even just free bits to play around with on their own to learn. The
> state of free software gaming is terrible, and many of us are still
> playing free software games from 30+ years ago. So purging any
> working free game framework just because it doesn't already have free
> games for it seems like a bad idea to me, anyway.
There is also the fact that ScummVM can run almost everywhere[2] so if
you write a program for it it can run on almost everywhere.

References:
----------
[1]https://en.wikipedia.org/wiki/Malbolge
[2]most GNU/Linux distributions, Nonfree OS (Windows, Windows XP,
   Windows 95, Mac OS, mac OSX, iOS), Snap, Flatpak, various game
   consoles (Playstation 3, viita, PSP, Dreamcast, Nintendo DS, 3DS,
   Wii, Siwtch), Android (32 and 64bit ARM, x86), some non-fsdg OS
   (KolibriOS, Haiku, Amiga, Morphos, RiscOS, Atari).

Denis.

pgpRZkpfrgG3r.pgp
Description: OpenPGP digital signature