On Thu, 15 Jun 2023 19:34:32 +0200 Liliana Marie Prikler 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.