unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>
Cc: Maxime Devos <maximedevos@telenet.be>, guix-devel@gnu.org
Subject: Re: FSDG issues of SCUMMVM-based games
Date: Sun, 18 Jun 2023 21:07:30 +0200	[thread overview]
Message-ID: <20230618210730.25c01473@primary_laptop> (raw)
In-Reply-To: <b2b6c03be0d176e3a62e3a127296decd26afa8d0.camel@gmail.com>

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

On Sun, 18 Jun 2023 10:19:06 +0200
Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:
> 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)
Thanks a lot. That means that we could easily patch ScummVM to ignore
checksums and at least fix this specific issue. It probably needs to be
done for each game engine we care about though.

> > > 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?
I don't know. There is a template for AGI games but the license is
strange too, and it also requires some software to build it, and I've
no idea if it's compatible with QT AGI, and I've also no idea if QT
AGI works, doesn't have nonfree dependencies, etc. 

So that makes things way more complicated because here it probably
requires a lot of work to confirm that it's possible or not possible to
develop programs that run inside ScummVM with 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).
Ah OK, I slightly misunderstood because I didn't think about the other
games with non-FSDG compliant assets, so I've no idea about these
yet, especially because it would depend a lot on the details.

For instance in some engines, it might be trivial to make them start
/ work a bit with FSDG compliant game data, or at least data that the
user can easily make, and on some other it might not be possible
without a lot of effort. Some engines might require code, other other
only data, etc. I've also don't have their package description in mind.

And in the FSDG there is also an exception for licenses like CC-BY-ND
for non-functional data like game graphics, but I fear that the engines
you're referring to are mainly meant to work with non-re-distributable
data.

> 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.
The same logic also applies to software under free licenses that lacks
corresponding source code: users can experiment with it, modify the
assembly code, and so on. 

But the amount of effort required to do that is huge compared to "the
preferred form of modification" of that software (typically source
code, commented assembly, with a build system that works and enable
users to do some small change and rebuild the code, etc).

Some firmwares are in this case, but they are considered nonfree until
their source code is produced somehow (for instance by reconstructing
it, and with some automatic reverse engineering tools, etc).

Another issue here is that it is way easier to reason on software that
exists and facts that are known or very likely to be true rather than
hypothetical software that require unknown or big amount of work. Here
it could turn out to be a huge amount of work just to manage to run free
code inside ScummVM.

That can also be compared to freeing firmwares under free licenses that
lack source code where there is some work and research needed to make
them useful for people wanting to use 100% free software.

In contrast if I take gjs, this program is free software:
> print("This software is released under the CC-0 License");
> print("hello world");
and it can run with 'gjs hello.js'. So weather or not gjs is reused by
other programs as a dependency, as-is it's ultra useful as anybody can
either write free software or software that isn't public (that's a
valid use case too). And making sure of that is trivial.

Denis.

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

  reply	other threads:[~2023-06-18 19:08 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
2023-06-18 19:07           ` Denis 'GNUtoo' Carikli [this message]
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=20230618210730.25c01473@primary_laptop \
    --to=gnutoo@cyberdimension.org \
    --cc=guix-devel@gnu.org \
    --cc=liliana.prikler@gmail.com \
    --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).