From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Cc: Maxime Devos <maximedevos@telenet.be>, guix-devel@gnu.org
Subject: Re: FSDG issues of SCUMMVM-based games
Date: Sun, 18 Jun 2023 10:19:06 +0200 [thread overview]
Message-ID: <b2b6c03be0d176e3a62e3a127296decd26afa8d0.camel@gmail.com> (raw)
In-Reply-To: <20230616174126.3e16c6c7@primary_laptop>
Am Freitag, dem 16.06.2023 um 17:41 +0200 schrieb Denis 'GNUtoo'
Carikli:
> 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.
Mono is (afaik) indeed completely free software, but not easy to
bootstrap. The downloader does skirt around our quality controls, but
I'd argue it does so on any FSDG-abiding distribution.
> > 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).
I've tracked the checksum to the header in which it was declared, and
it says
/* MD5 of (the beginning of) the described file.
Optional. Set to NULL to ignore. */
const char *md5;
(Comment reformatted to fit into a mail)
In the case of draci, it appears to be used to distinguish different
language versions. I'd hazard a guess that this is actually pointless
in Guix – you can load different language versions via Guix shell – so
you can just null them all.
> > 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.
Didn't you say that a hello world for scummvm exists?
> 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.
My argument isn't that we ought to remove wine because it's quite often
used to run nonfree software. My argument is to apply the same
principles we use to justify not only wine, but also game engines,
where only the engine but none of the assets are free (some of which
are included in Guix). Indeed, we may not have access to the same
tools as the game developers did back then, but you can still run the
games on any machine of your choosing for any purpose, and if you don't
mind experimenting a little, you can also run modified versions. As of
right now, practical limitations require you to modify the binaries
directly, but there are no theoretical limitations: You can study the
engines as implemented in ScummVM to create your own games for them.
Cheers
next prev parent reply other threads:[~2023-06-18 8:19 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-06 4:59 FSDG issues of SCUMMVM-based games Liliana Marie Prikler
2022-08-06 6:36 ` Tobias Geerinckx-Rice
2022-08-06 14:41 ` Tobias Geerinckx-Rice
2022-08-07 12:52 ` Christine Lemmer-Webber
2022-08-06 15:24 ` Maxime Devos
2022-08-06 17:00 ` Liliana Marie Prikler
2023-06-15 16:30 ` Denis 'GNUtoo' Carikli
2023-06-15 17:34 ` Liliana Marie Prikler
2023-06-16 15:41 ` Denis 'GNUtoo' Carikli
2023-06-18 8:19 ` Liliana Marie Prikler [this message]
2023-06-18 19:07 ` Denis 'GNUtoo' Carikli
2023-06-20 4:30 ` Liliana Marie Prikler
2023-06-20 8:00 ` Efraim Flashner
2023-06-21 1:27 ` Denis 'GNUtoo' Carikli
2023-06-21 8:38 ` Giovanni Biscuolo
2023-07-23 8:10 ` Liliana Marie Prikler
2023-11-24 18:54 ` Denis 'GNUtoo' Carikli
2023-11-24 19:52 ` Liliana Marie Prikler
2022-08-24 12:53 ` Nicolas Goaziou
2022-08-24 18:44 ` Liliana Marie Prikler
2022-08-24 20:24 ` Vagrant Cascadian
2022-08-24 21:31 ` Maxime Devos
2022-08-24 20:24 ` zimoun
2022-08-24 21:48 ` Maxime Devos
2022-08-24 22:08 ` Tobias Geerinckx-Rice
2022-08-25 19:26 ` Tobias Geerinckx-Rice
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b2b6c03be0d176e3a62e3a127296decd26afa8d0.camel@gmail.com \
--to=liliana.prikler@gmail.com \
--cc=GNUtoo@cyberdimension.org \
--cc=guix-devel@gnu.org \
--cc=maximedevos@telenet.be \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).