Re: FSDG issues of SCUMMVM-based games

[Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>]

[-- Attachment #1: Type: text/plain, Size: 5036 bytes --]

On Thu, 15 Jun 2023 19:34:32 +0200
Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:
> I don't think we need to be that harsh on ScummVM itself, it being a
> virtual machine.  
>
> Compare it to Wine: the tools to create Windows binaries with free
> software only are limited (albeit existing if we discount the
> necessity for system headers), but it still serves a purpose by
> enabling you to run said programs without resorting to a Windows
> machine.
About wine, the first time GUix's wine starts it asks you to download
and install mono for you (and in my case I didn't manage to skip that),
but if that's 100% free (it's most likely the case), everything should
be OK because:
- We have an FSDG compliant toolchain for Wine in Guix
- Wine in Guix should also be 100% free software
- The guix build --target=x86_64-w64-mingw32 hello works fine in
  Guix's Wine
- The package description also don't steer users toward nonfree
  software.

So just with that have at least 1 valid use case that don't steer users
toward getting and installing nonfree software at all, and that use
case is not incompatible with the package description, so for me It's
hard to find something wrong with that here, especially when the use
case is of strategic importance for free software (shipping software to
people used by nonfree OS can help spread free file formats and
protocols).

> The only limiting factor here is your point (2), i.e. it being able to
> run arbitrary games compiled for the VM.  I don't think that weird
> checksums ought to be enforced if they're not baked into the program
> itself.
The draci-historie build tutorial said that the checksums were backed
in ScummVM and that you needed to add your own checksum inside ScummVM
source code and recompile it to run a modified version of the game.

Maybe that changed since then, but that is probably not very likely to
have happened, and this checksum mechanism also likely applies to all
programs or games meant to run inside ScummVM.

And if we had at least one 100% free program that run inside ScummVM
(something without nonfree dependencies, that we can rebuild or modify)
then we'd be able to easily find out about the checksums.

If someone knows good tools to work with ARJ archives, we could also
try it by modifying existing games very slightly (like by adding
something new inside the ARJ archive).

> Even if no such toolchain exists for ScummVM, you need ScummVM as a
> testbed to write one :)
Assuming that some way around the checksums is found, the issue here is
that no such toolchain exist yet, so testing it won't work right now.

And assuming that draci-historie turn out to be a dead end, getting a
free toolchain probably requires significant work in research, or in
packaging.

In contrast, many other VMs (qemu, java, gjs, etc), they already
have valid use cases and/or it's trivial to make a free software hello
world.

So there is no such burden on the potential user to have to provide
development tools that don't exist yet for that VM.

And here the rationale doesn't try to weight uses cases (like wine has
many nonfree games and very few known 100% free software, so wine
should be removed[2]), only to make sure that there is at least a single
use case that works with 100% free software.

> > I've looked a bit at another game (draci-historie[2]) that has some
> > source code published. This game is not packaged nor redistributed
> > by Guix but it looks way better than the other freedom wise and it
> > can teach us how ScummVM games are made.
> > 
> > Its probably not good enough as-is as its source code also also
> > relies on a tarball that contains executable to build the game and I
> > also didn't manage to build it with Guix yet (I've attached a file
> > with my attempt) but maybe it's possible to get it to build and
> > maybe we can build a 100% free software version of it.
> You might be able to bootstrap parts of it with fpc, i.e. the Free
> Pascal Compiler.  I'm not sure whether you'll encounter the necessity
> for Borland Pascal, as we package version 3.2.2, which is somewhat
> newer than the mentioned 2.4.
I'm unsure of why it fails exactly. I've an error message[1] that comes
from the Pascal code, but I don't know Pascal and the comments aren't
in English. 

Though I could indeed try a different compiler version and see if it
works, or try to build it in some FHS container.

References:
-----------
[1]cannot save palettes used in programs
   /tmp/guix-build-draci-historie-1+2.drv-0/source/build/gfx/outro/outpal1.pcx
[2]In my opinion weighting use cases is a can of worms because the
   importance of use cases is subjective, and if all FSDG distros go
   this route, it could prevent valid use cases that are or turn out to
   be strategic for free software. And since the use cases are
   prevented, people might even not be able to see the problem that was
   created by going this route.

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]