FSDG issues of SCUMMVM-based games

FSDG issues of SCUMMVM-based games

[Liliana Marie Prikler]

Hi Guix,

The packages
- drascula,
- lure,
- queen, and
- sky
all share issues that make me question whether they should be in Guix.

1. Their license explicitly prohibits selling of the games themselves
and may thus be qualified as non-free.
2. The "sources" consist of binaries that are installed as-is.

Given the above, I think we ought not distribute them.  Note that this
is not a statement on SCUMMVM itself, but only the packages built with
it.

WDYT?

Re: FSDG issues of SCUMMVM-based games

[Tobias Geerinckx-Rice]

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

Hi Liliana,

Liliana Marie Prikler 写道：
> The packages
> - drascula,

[…]

> 1. Their license explicitly prohibits selling of the games 
> themselves
> and may thus be qualified as non-free.

Yep, it's pretty explicit, and I agree that it's an unreasonable 
restriction that makes the software non-free.

> 2. The "sources" consist of binaries that are installed as-is.

Wow, you weren't kidding.  Of the 1145(!) or 63 MiB(!) of files, 
literally not one is source code.

At best, the archive contains 3 ‘text’ files: one with only 
numbers, one with only asterisks, and one with only blank lines.

> - lure,
> - queen, and
> - sky

I didn't check these, but I believe you if you say they're just as 
bad.

I see no way to keep these in Guix.

Thanks!

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: FSDG issues of SCUMMVM-based games

[Tobias Geerinckx-Rice]

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

I've sent an e-mail to the FSF licencing department asking for 
their guidance on the matter.  I erred on the side of netiquette 
caution and didn't CC this list.

Either the inclusion of [a subset of] Drascula in Trisquel[0] is a 
similar oversight, or we're missing some legal subtlety.

I'm hoping for the latter, as I'd hate to see old art become less 
accessible.

Kind regards,

T G-R

[0]: https://packages.trisquel.info/hu/nabia/all/drascula/filelist

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: FSDG issues of SCUMMVM-based games

[Christine Lemmer-Webber]

I thought I remembered that "Beneath a Steel Sky" was released by its
authors under GPLv2 to some applause back in the day.  I remember that's
why I installed and played it...

It's mentioned here at least:
  https://en.wikipedia.org/wiki/Beneath_a_Steel_Sky#Freeware_release_and_Remastered_edition

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> [[PGP Signed Part:Undecided]]
> Hi Liliana,
>
> Liliana Marie Prikler 写道：
>> The packages
>> - drascula,
>
> […]
>
>> 1. Their license explicitly prohibits selling of the games
>> themselves
>> and may thus be qualified as non-free.
>
> Yep, it's pretty explicit, and I agree that it's an unreasonable
> restriction that makes the software non-free.
>
>> 2. The "sources" consist of binaries that are installed as-is.
>
> Wow, you weren't kidding.  Of the 1145(!) or 63 MiB(!) of files,
> literally not one is source code.
>
> At best, the archive contains 3 ‘text’ files: one with only numbers,
> one with only asterisks, and one with only blank lines.
>
>> - lure,
>> - queen, and
>> - sky
>
> I didn't check these, but I believe you if you say they're just as
> bad.
>
> I see no way to keep these in Guix.
>
> Thanks!
>
> T G-R
>
> [[End of PGP Signed Part]]

Re: FSDG issues of SCUMMVM-based games

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 870 bytes --]

On 06-08-2022 06:59, Liliana Marie Prikler wrote:

> 2. The "sources" consist of binaries that are installed as-is.

The credits of ScummVM state that the source code is available for 
Drascula[0]

[0] https://docs.scummvm.org/en/latest/help/credits.html: Emilio de Paz 
Aragón from Alcachofa Soft for sharing the source code of Drascula: The 
Vampire Strikes Back with us and his generosity with freewaring the game.

Maybe that only covered the engine and not the game bytecode though ...

I don't think bytecode falls under the 'non-functional data' exception 
of the FSDG, because code (the sprites, backgrounds and sound are 
another matter).

As such, I agree they should not be distributed (unless the actual 
sources are found, but even then there is (1.)), as per the first 
sentence of ‘(guix)GNU Distribution’.

Greetings,
Maxime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

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

Re: FSDG issues of SCUMMVM-based games

[Liliana Marie Prikler]

Am Samstag, dem 06.08.2022 um 17:24 +0200 schrieb Maxime Devos:
> On 06-08-2022 06:59, Liliana Marie Prikler wrote:
> 
> > 2. The "sources" consist of binaries that are installed as-is.
> 
> The credits of ScummVM state that the source code is available for 
> Drascula[0]
> 
> [0] https://docs.scummvm.org/en/latest/help/credits.html: Emilio de Paz
> Aragón from Alcachofa Soft for sharing the source code of Drascula:
> The Vampire Strikes Back with us and his generosity with freewaring the
> game.
> 
> Maybe that only covered the engine and not the game bytecode though
While that does mean that ScummVM folks have the source, it is not what
they distribute:

Archive:  /gnu/store/wn9043a134dai59shxss6byrlfj2pp9x-drascula-1.0.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
 32847563  05-11-2008 08:38   Packet.001
    46080  05-11-2008 08:38   drascula.doc
     2871  08-31-2008 03:29   readme.txt
---------                     -------
 32896514                     3 files

Also note the difference between freeware and free software.

Cheers

Re: FSDG issues of SCUMMVM-based games

[Denis 'GNUtoo' Carikli]

[-- Attachment #1.1: Type: text/plain, Size: 7852 bytes --]

Hi,

About the license it's still unclear if it's free or not as some people
pointed on the gnu-linux-libre mailing[1] list that it's a bit similar
to the open font license, but that is a license for fonts not code
though. So I've looked at the other aspects (missing source code, etc).

On Sat, 6 Aug 2022 17:24:52 +0200
Maxime Devos <maximedevos@telenet.be> wrote:
> As such, I agree they should not be distributed (unless the actual 
> sources are found, but even then there is (1.)), as per the first 
> sentence of ‘(guix)GNU Distribution’.

For the lack of missing source code I've looked a bit more in depth
about Drascula and the other games mentioned and here's what I found
below.

Drascula:
---------
The file used by ScummVM is Packet.001.

Apparently it's an ARJ archive:
> $ file Packet.001
> Packet.001: ARJ archive data, v7, slash-switched, created 11 dec
> 1980+18, original name: PACKET.ARJ, os: MS-DOS

And binwalk can manage to extract the files from it:
> $ binwalk -e Packet.001

There might be way better tools to do that but I don't know them.

That extracted 1146 files.

One of these files is DRASCULA.COM, and it's safe to assume that it
should be a dos executable because many of these games were also
released for DOS. There are other .COM files too.

File also seems to think that DRASCULA.COM is a dos executable (file is
not 100% reliable).
> $ file DRASCULA.COM 
> DRASCULA.COM: DOS executable (COM), start instruction 0xeb3a9043
> 6f6d7069

I've no idea what most of the files are for but here's their extensions:
> $ ls | sed 's#.*\.##' | sort -u
> ALD
> ALG
> ALS
> arj (that could be the header of the Packet.001 file)
> BIN
> CAL
> CFG
> COM
> DEV
> DRV
> EPA
> EXE
[GSAVE* (GSAVE00, GSAVE01, .. GSAVE10)]
> RCT
> VOC

So:
- We lack the source code for DRASCULA.COM
- If people re-make ARJ archives without any of the executables, and
  that the game still works, then still have issues about the other
  files that might contain code that lack corresponding source code.
  More on that below (in the part about draci-historie).

Lure:
-----
The files used by ScummVM are: Disk1.vga Disk2.vga Disk3.vga
and Disk4.vga I don't know much more about the format.

I've also found an executable without source code (Lure.exe) in one of
the source pacakge, but Guix probably has a mechanism to take care of
that to republishing modified source code without Lure.exe.

queen:
------
The file used by ScummVM is queen.1c, but I don't know more.

sky:
----
The following 3 files are used by ScummVM:
- sky.cpt: Targa image data - Map - RLE 487 x 608 x 1 +353 +412 - 1-bit
           alpha
- sky.dnr: DOS executable (COM), start instruction 0xe9130000 cfea0000
- sky.dsk: data

File seems wrong with sky.cpt, and I've no idea if file is write with
sky.dnr.

There are also deeper issues:
------------------------------
- All these files are not built from source, so it's complicated to
  understand the provenance of what's inside. And so it's probably
  safer not to ship them (unless we build everything from source)
  because we're unsure that there is some corresponding source code
  inside. 
- Even if there was complete source code inside, we need to be able to
  modify that source code somehow, so doing that might require a lot of
  work to research or build the tools for that.
- ScummVM might contain checksums (See the "4. Play the recompiled
  game" of the draci-historie build documentation [3]) but if someone
  manages to build a game for ScummVM, it could be added as a
  dependency of ScummVM and its checksum could be added inside ScummVM
  at compilation time. 

Also if:
- There are no free programs for ScummVM (a hello world under
  a free license would could count as a free program) (we don't know if
  it's the case or not)
- ScummVM needs to be patched to run modified games (this is very
  likely)
- We don't know if it's possible to build a game for ScummVM
  with only free software (the game doesn't necessarily need to be
  public but free software tools would need to exist to build it).

Then it would clearly steers users toward nonfree software. 

Though here we don't know if there are free programs or not but we also
cannot tell users that scummVM is usefull with a specific free program
or show them a use case that doesn't require nonfree software, so we
might also have a problem with that.

A way forward:
--------------
A possibility here could be to remove ScummVM and the games that run in
it. Another would be to find a 100% free program for ScummVM (that
doesn't have nonfree dependencies for being modified or rebuilt) or to
find a way to make your own program for ScummVM 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.

For the licenses the website has the following:
> In 2006, I (Robert Špalek) released the source codes under the GNU
> GPL2 license.
> [...]
> The game has been released under the GNU GPL license version 2,
> hence you can download it for free including full source codes. The
> new game engine is a part of ScummVM and its source codes are thus
> also a part of it. The old game engine was written in Borland Pascal
> and Turbo Assembler, and only runs on MS-DOS. It can be downloaded
> below. Besides the game player you can also download the source codes
> of the game scripts written in our proprietary game programming
> language, and source images, sounds, and animations. 

So I'm unsure about the license of the executable, game data, etc.

The interesting thing is that it has some draci-historie specific
scripting language and a compiler for it. So we can safely assume that
the other games most likely have a way to script things and that the
games are complex enough to have scripts.

And these scripts may need to be compiled here (I've no idea how
scripts look like for the other games).

A way forward would be to try to build this draci-historie game if we
really want to have ScummVM games and to patch ScummVM to use the
checksums from the newly built game.

There is also an IDE (QT AGI Studio)[4] and some templates[5] for the
AGI game engine supported by ScummVM, but all that require some work
because (a) the IDE depends on QT4, and (b) the template license is a
bit similar to the games license[6], and (c) if scummVM still has
checksums, then users need to build their own version anyway (d) nobody
knows if that can work with 100% free software unless people audit or
package the software and try to see if it works.

References:
-----------
[1]This gnu-linux-libre mailing list is at nongnu.org. Despite its name,
   this mailing list is meant for discussions about all FSDG compliant
   distributions(even the ones without GNU or linux-libre like
   Replicant), about the list of software to exclude from FSDG
   distributions, about adding new distros in the list, etc.
[2]https://www.ucw.cz/draci-historie/index-en.html
[3]https://www.ucw.cz/draci-historie/src/doc/compiling-the-game.txt
[4]https://agistudio.sourceforge.net/#requirements
[5]https://github.com/nbudin/agikit-project-template
[6]https://github.com/nbudin/agikit-project-template/blob/main/README-original.txt

Denis.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: draci-historie.scm --]
[-- Type: text/x-scheme, Size: 6540 bytes --]

;;; Copyright © 2023 Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
;;;
;;; This file is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; This file is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with this file.  If not, see <http://www.gnu.org/licenses/>.

(use-modules (gnu packages compression)
	     (gnu packages pascal)
	     (gnu packages python)
	     (guix build-system gnu)
	     (guix build-system trivial)
	     (guix download)
	     (guix gexp)
	     (guix packages)
	     ((guix licenses) #:prefix license:))

;; Serious issues to address:
;; (1) Is the Data GPLv2 ? Is it redistributable? What the dh-en-2012.zip
;;     binaries?
;; (2) compiling-the-game.txt[1] has a section "4. Play the recompiled
;;     game" that explains that the game built is incompatible with
;;     ScummVM unless scummVM is patched with the md5 of the game binary.
;;     [1]https://www.ucw.cz/draci-historie/src/doc/compiling-the-game.txt
;; (3) Actually make it work
;; (4) Patch scummVM and test the game

;; TODO:
;; - Also pakcage licenses and license declarations too
;; - identify and remove the binaries that are not used by the build
;;   system.
;; - Make sure only data that can be edited with free software
;;   tools remains.
;; - Make a cleaned-up tarball and get that mirrored instead of the
;;   binaries we don't use.
;; - Convert that into a function that makes a package for a given
;;   language.
(define-public draci-historie-dubbing-en
  (package
   (name "draci-historie-dubbing-en")
   ;; There are no versions in the release.
   (version "1+1")
   (source (origin
            (method url-fetch)
            (uri
	     (string-append
	      "https://www.ucw.cz/draci-historie/binary/dh-en-2012.zip"))
	    (sha256
	     (base32
	      "08xffj4648nxp3mjxwf54z1y4nk1718jrnkib2ikj5h509cn4z40"))))
	    (build-system trivial-build-system)
	    (arguments
	     (list #:modules '((guix build utils))
		   #:builder 
		   #~(begin
		       (use-modules (guix build utils))
		       (let* ((destination
			       (string-append
				(assoc-ref %outputs "out")
				"/share/draci-historie-dubbing-en/"))
			      (source (assoc-ref %build-inputs "source"))
			      (unzip (search-input-file %build-inputs "/bin/unzip")))
			 (invoke unzip source "-d" "source")
			 (copy-recursively "source" destination)))))
	    (native-inputs (list unzip))
	    (home-page "https://www.ucw.cz/draci-historie/index-en.html")
	    (synopsis "TODO")
	    (description "TODO")
	    (license license:gpl2))) ;; Is the Data really GPLv2(+?) ???

;; TODO: also pakcage licenses and license declarations too
(define-public draci-historie-data
  (package
   (name "draci-historie-data")
   ;; There are no versions in the release.
   (version "1+1")
   (source (origin
            (method url-fetch)
            (uri "https://www.ucw.cz/draci-historie/source/new-gfx.zip")
	    (sha256
	     (base32
	      "09z7kipd1vpd7si4lmpqr1xfb0vc3jfnwllv9zvxiyqrr44n56py"))))
	   (build-system trivial-build-system)
	   (arguments
	    (list #:modules '((guix build utils))
		  #:builder 
		  #~(begin
		      (use-modules (guix build utils))
		      (let* ((gfx (string-append (assoc-ref %outputs "out") "/share/gfx/"))
			     (source (assoc-ref %build-inputs "source"))
			     (unzip (search-input-file %build-inputs "/bin/unzip")))
			(invoke unzip source)
			(copy-recursively "gfx" gfx)))))
	   (native-inputs (list unzip))
	   (home-page "https://www.ucw.cz/draci-historie/index-en.html")
	   (synopsis "TODO")
	   (description "TODO")
	   (license license:gpl2))) ;; Is the Data really GPLv2(+?) ???

;; TODO: also pakcage some the documentation in doc/ and package
;; licenses and license declarations too
(define-public draci-historie
  (package
   (name "draci-historie")
   ;; There are no versions in the release.
   (version "1+2")
   (source (origin
            (method url-fetch/zipbomb)
            (uri "https://www.ucw.cz/draci-historie/source/new-sources.zip")
            (sha256
             (base32
              "1a7qxigbzmh7v85r83zc9hc347qwrq4iyia044vq87cy8n1z1whb"))))
   (build-system gnu-build-system)
   (arguments
    (list
     #:tests? #f ; No target
     #:make-flags #~(list "-d") ;; debug
     #:parallel-build? #f ;; debug
     #:phases 
     #~(modify-phases
	%standard-phases
	(add-after
	 'unpack 'fix-build
	 (lambda _
	   (substitute* "Makefile"
			(("^DIR=/.*")
			 (string-append
			  "DIR="
			  (getcwd)
			  "/build\n")))
	   ;; TODO: Add support for more LANGS an AUDIO (see doc/compiling-the-game.txt)
	   (substitute* "Makefile"
			(("^LANGS=.*") "LANGS=en\n"))
	   (substitute* "Makefile"
			(("^AUDIO=.*") "AUDIO=\n"))
	   (substitute* (find-files "scripts" ".py$")
			(("#!/usr/bin/python")
			 (string-append "#!" (which "python2"))))))
	(add-after
	 'fix-build 'unpack-gfx
	 (lambda _
	   (let* ((gfx
		   (string-append
		    #$(this-package-native-input "draci-historie-data")
		    "/share/gfx/")))
	     (mkdir-p "build")
	     (copy-recursively gfx "build/orig-gfx"))))
	(add-after
	 'unpack-gfx 'unpack-english
	 (lambda _
	   (let* ((dubbing-en
		   (string-append
		    #$(this-package-native-input "draci-historie-dubbing-en")
		    "/share/draci-historie-dubbing-en/")))
	     (mkdir-p "build/orig-exe/en")
	     (copy-recursively dubbing-en "build/orig-exe/en"))))
	(add-before
	 'build 'clean-source
	 (lambda _
	   ;; Turbo Pascal configuration files
	   (for-each delete-file (find-files "." ".*\\.tp"))
	   (invoke "make" "clean_all")))
	(add-after
	 'build 'build-dubbing
	 (lambda _
	   (invoke "make" "dubbing_all")))
	 (delete 'configure))))
   (native-inputs (list draci-historie-data
			draci-historie-dubbing-en
			fpc python-2.7 zip))
   (home-page "https://www.ucw.cz/draci-historie/index-en.html")
   (synopsis "TODO")
   (description "TODO")
   (license license:gpl2))) ; I didn't fin mentions of "or later"

(list draci-historie)

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

Re: FSDG issues of SCUMMVM-based games

[Liliana Marie Prikler]

Am Donnerstag, dem 15.06.2023 um 18:30 +0200 schrieb Denis 'GNUtoo'
Carikli:
> Also if:
> - There are no free programs for ScummVM (a hello world under
>   a free license would could count as a free program) (we don't know 
>   if it's the case or not)
> - ScummVM needs to be patched to run modified games (this is very
>   likely)
> - We don't know if it's possible to build a game for ScummVM
>   with only free software (the game doesn't necessarily need to be
>   public but free software tools would need to exist to build it).
> 
> Then it would clearly steers users toward nonfree software. 
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.  Even if no such toolchain exists for ScummVM, you
need ScummVM as a testbed to write one :)

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.

> 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.

Cheers

Re: FSDG issues of SCUMMVM-based games

[Denis 'GNUtoo' Carikli]

[-- 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 --]

Re: FSDG issues of SCUMMVM-based games

[Liliana Marie Prikler]

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

Re: FSDG issues of SCUMMVM-based games

[Denis 'GNUtoo' Carikli]

[-- 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 --]

Re: FSDG issues of SCUMMVM-based games

[Liliana Marie Prikler]

Am Sonntag, dem 18.06.2023 um 21:07 +0200 schrieb Denis 'GNUtoo'
Carikli:
> [...]
> > 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.
I see we're hitting a recurring pattern of not knowing things.  This is
not aided by my personal disinterest for ScummVM, but I have to weigh
that disinterest against the potential interest of thousands of users
who are likely to only discover this argument to have taken place after
we've reached a conclusion.

Note, that this discussion started IIRC a year ago and we have
practically known about actually existing FSDG violations since then. 
My approach here is quite simple and pragmatic: Remove the games which
obviously violate the FSDG (that is all the games currently depending
on ScummVM as far as I know), but keep ScummVM for now to allow folks
to experiment.  If in some one to five years we still find no practical
way of using ScummVM with only free software, that might be a reason to
remove it then.

WDYT?

Re: FSDG issues of SCUMMVM-based games

[Efraim Flashner]

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

On Tue, Jun 20, 2023 at 06:30:26AM +0200, Liliana Marie Prikler wrote:
> Am Sonntag, dem 18.06.2023 um 21:07 +0200 schrieb Denis 'GNUtoo'
> Carikli:
> > [...]
> > > 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.
> I see we're hitting a recurring pattern of not knowing things.  This is
> not aided by my personal disinterest for ScummVM, but I have to weigh
> that disinterest against the potential interest of thousands of users
> who are likely to only discover this argument to have taken place after
> we've reached a conclusion.
> 
> Note, that this discussion started IIRC a year ago and we have
> practically known about actually existing FSDG violations since then. 
> My approach here is quite simple and pragmatic: Remove the games which
> obviously violate the FSDG (that is all the games currently depending
> on ScummVM as far as I know), but keep ScummVM for now to allow folks
> to experiment.  If in some one to five years we still find no practical
> way of using ScummVM with only free software, that might be a reason to
> remove it then.
> 
> WDYT?

This sounds like a sensible resolution to me.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

Re: FSDG issues of SCUMMVM-based games

[Denis 'GNUtoo' Carikli]

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

On Tue, 20 Jun 2023 06:30:26 +0200
Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:
> Note, that this discussion started IIRC a year ago and we have
> practically known about actually existing FSDG violations since then. 
> My approach here is quite simple and pragmatic: Remove the games which
> obviously violate the FSDG (that is all the games currently depending
> on ScummVM as far as I know), but keep ScummVM for now to allow folks
> to experiment.  If in some one to five years we still find no
> practical way of using ScummVM with only free software, that might be
> a reason to remove it then.
> 
> WDYT?
That looks perfectly fine to me. It leaves some time to people to try to
fix ScummVM itself in a better way (like by packaging games built from
source like Draci Historiae, removing the checksums, making a hello
world, etc), and at the end ScummVM would get removed if it's not fixed.

Denis.

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

Re: FSDG issues of SCUMMVM-based games

[Giovanni Biscuolo]

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

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

[...]

> Note, that this discussion started IIRC a year ago and we have
> practically known about actually existing FSDG violations since then. 
> My approach here is quite simple and pragmatic: Remove the games which
> obviously violate the FSDG (that is all the games currently depending
> on ScummVM as far as I know)

I totally agree with this simple and pragmatic solution, but the FSDG
violation is not that games are distributed with a non-free license
(IMHO the license of some or all games have the same legal effect of the
SIL Open Font License v.1.1, that is considered free [1])

AFAIU the violation comes from the absence of the source code (or just
the build tools?) to compile the game to ScummVM bytecode (other issues
with the way games are compiled and distributed can be patched, AFAIU)

IMO when removing teh games is very inportant to mention the motivation,
since it will be useful for potential similar use cases.

> but keep ScummVM for now to allow folks to experiment.  If in some one
> to five years we still find no practical way of using ScummVM with
> only free software, that might be a reason to remove it then.

Yes, keeping ScummVM is not a clear FSDG violation AFAIU

Thanks all for the heads on!

[1] albeit very poorly worded: https://www.gnu.org/licenses/license-list.html#SILOFL

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: FSDG issues of SCUMMVM-based games

[Liliana Marie Prikler]

Am Mittwoch, dem 21.06.2023 um 10:38 +0200 schrieb Giovanni Biscuolo:
> > Note, that this discussion started IIRC a year ago and we have
> > practically known about actually existing FSDG violations since
> > then. 
> > My approach here is quite simple and pragmatic: Remove the games
> > which obviously violate the FSDG (that is all the games currently
> > depending on ScummVM as far as I know)
> 
> I totally agree with this simple and pragmatic solution, but the FSDG
> violation is not that games are distributed with a non-free license
> (IMHO the license of some or all games have the same legal effect of
> the SIL Open Font License v.1.1, that is considered free [1])
I don't think the exception the FSF makes here for fonts holds for
actual software, but I might be mistaken.  Also note that we only
bundle ScummVM with guix pack style tarballs, but not in the packages
themselves.

> AFAIU the violation comes from the absence of the source code (or
> just the build tools?) to compile the game to ScummVM bytecode (other
> issues with the way games are compiled and distributed can be
> patched, AFAIU)
> 
> IMO when removing teh games is very inportant to mention the
> motivation, since it will be useful for potential similar use cases.
I've pushed the removals to master, pointing to the lack of
corresponding source as the fact we can all agree on.  This comes in
just in time as Adam Faiz (hi there!) has packaged openquest [1], which
will hopefully soon give us a free as in freedom game to play with
ScummVM and compare other submissions against :)

Cheers

[1] https://issues.guix.gnu.org/issue/64787

Re: FSDG issues of SCUMMVM-based games

[Denis 'GNUtoo' Carikli]

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

Hi again,

On Tue, 20 Jun 2023 06:30:26 +0200
Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:
> If in some one to five years we still find no practical way of using
> ScummVM with only free software, that might be a reason to remove it
> then.
With lot of help from anthk_ #hyperbola I finally found a practical way
to use it, and even without recompiling it, so we can keep ScummVM.

We need 3 repositories:
- https://jxself.org/git/inform.git GPLv3+
- https://jxself.org/git/devours.git AGPLv3+
- https://jxself.org/git/informlib.git (devours submodule) AGPLv3+

Here's how to do it:
> $ git clone https://jxself.org/git/inform.git
> $ cd inform
> $ gcc src/*.c -o inform
> $ git clone --recursive https://jxself.org/git/devours.git
> $ cd devours
> $ sed 's#inform#../inform#g' -i build.sh 
> $ ./build

That creates the devours.z5 file.

We can then start scummvm:
> $ scummvm glk:devours

And we can then choose "add game" and add the game in the current
directory and accept the warnings.

Then pressing start starts the game.

Denis.

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

Re: FSDG issues of SCUMMVM-based games

[Liliana Marie Prikler]

Am Freitag, dem 24.11.2023 um 19:54 +0100 schrieb Denis 'GNUtoo'
Carikli:
> Hi again,
> 
> On Tue, 20 Jun 2023 06:30:26 +0200
> Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:
> > If in some one to five years we still find no practical way of
> > using
> > ScummVM with only free software, that might be a reason to remove
> > it
> > then.
> With lot of help from anthk_ #hyperbola I finally found a practical
> way
> to use it, and even without recompiling it, so we can keep ScummVM.
> 
> We need 3 repositories:
> - https://jxself.org/git/inform.git GPLv3+
> - https://jxself.org/git/devours.git AGPLv3+
> - https://jxself.org/git/informlib.git (devours submodule) AGPLv3+
> 
> Here's how to do it:
> > $ git clone https://jxself.org/git/inform.git
> > $ cd inform
> > $ gcc src/*.c -o inform
> > $ git clone --recursive https://jxself.org/git/devours.git
> > $ cd devours
> > $ sed 's#inform#../inform#g' -i build.sh 
> > $ ./build
> 
> That creates the devours.z5 file.
> 
> We can then start scummvm:
> > $ scummvm glk:devours
> 
> And we can then choose "add game" and add the game in the current
> directory and accept the warnings.
While we do already have a free ScummVM game from what I know, one more
can't hurt. Do you perhaps want to package these up? :)

Re: FSDG issues of SCUMMVM-based games

[Nicolas Goaziou]

Hello,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> The packages
> - drascula,
> - lure,
> - queen, and
> - sky
> all share issues that make me question whether they should be in Guix.
>
> 1. Their license explicitly prohibits selling of the games themselves
> and may thus be qualified as non-free.
> 2. The "sources" consist of binaries that are installed as-is.
>
> Given the above, I think we ought not distribute them.  Note that this
> is not a statement on SCUMMVM itself, but only the packages built with
> it.
>
> WDYT?

For the record, I added these games because I agree with Debian
packagers on the topic. See
<https://metadata.ftp-master.debian.org/changelogs//main/d/drascula/drascula_1.0+ds4-1_copyright>.

Regards,
-- 
Nicolas Goaziou

Re: FSDG issues of SCUMMVM-based games

[Liliana Marie Prikler]

Am Mittwoch, dem 24.08.2022 um 14:53 +0200 schrieb Nicolas Goaziou:
> Hello,
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
> > The packages
> > - drascula,
> > - lure,
> > - queen, and
> > - sky
> > all share issues that make me question whether they should be in
> > Guix.
> > 
> > 1. Their license explicitly prohibits selling of the games
> > themselves and may thus be qualified as non-free.
> > 2. The "sources" consist of binaries that are installed as-is.
> > 
> > Given the above, I think we ought not distribute them.  Note that
> > this is not a statement on SCUMMVM itself, but only the packages
> > built with it.
> > 
> > WDYT?
> 
> For the record, I added these games because I agree with Debian
> packagers on the topic. See
> <
> https://metadata.ftp-master.debian.org/changelogs//main/d/drascula/drascula_1.0+ds4-1_copyright
> >.
This statement seems to contradict itself.
> The data included in the source package represents the preferred form
> for modifications.
> If they were licensed under the G P L it would fail the "preferred
> form of modification" requirement
As far as I'm concerned, "preferred form of modification" should not be
dependant upon the license in question.  Speaking of the license in
question, it's prohibition of selling is nowhere mentioned.

Cheers

Re: FSDG issues of SCUMMVM-based games

[Vagrant Cascadian]

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

On 2022-08-24, Liliana Marie Prikler wrote:
> Am Mittwoch, dem 24.08.2022 um 14:53 +0200 schrieb Nicolas Goaziou:
>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>> 
>> > The packages
>> > - drascula,
>> > - lure,
>> > - queen, and
>> > - sky
>> > all share issues that make me question whether they should be in
>> > Guix.
>> > 
>> > 1. Their license explicitly prohibits selling of the games
>> > themselves and may thus be qualified as non-free.
>> > 2. The "sources" consist of binaries that are installed as-is.
>> > 
>> > Given the above, I think we ought not distribute them.  Note that
>> > this is not a statement on SCUMMVM itself, but only the packages
>> > built with it.
>> > 
>> > WDYT?
>> 
>> For the record, I added these games because I agree with Debian
>> packagers on the topic. See
>> <
>> https://metadata.ftp-master.debian.org/changelogs//main/d/drascula/drascula_1.0+ds4-1_copyright
>> >.
> This statement seems to contradict itself.
>> The data included in the source package represents the preferred form
>> for modifications.
>> If they were licensed under the G P L it would fail the "preferred
>> form of modification" requirement
> As far as I'm concerned, "preferred form of modification" should not be
> dependant upon the license in question.

Is it Functional Data:

  https://www.gnu.org/distros/free-system-distribution-guidelines.html

  "For example, some game engines released under the GNU GPL have
  accompanying game information—a fictional world map, game graphics,
  and so on—released under such a verbatim-distribution license. This
  kind of data can be part of a free system distribution, even though
  its license does not qualify as free, because it is non-functional."


> Speaking of the license in question, it's prohibition of selling is
> nowhere mentioned.

It is mentioned in the above link:

"2) You may charge a reasonable copying fee for this archive, and may
    distribute it in aggregate as part of a larger & possibly commercial
    software distribution (such as a Linux distribution or magazine coverdisk).
    You must provide proper attribution and ensure this Readme and all
    associated copyright notices, and disclaimers are left intact.
 .
 3) You may not charge a fee for the game itself. This includes reselling the
    game as an individual item."

You cannot sell the game itself, but you can charge "a reasonable
copying fee" and distribute it commercially... while slightly confusing
and seemingly contradictory at a passing glance, those two clauses alone
do not appear to violate any of the four freedoms to me:

  https://www.gnu.org/philosophy/free-sw.html#four-freedoms


I'm not really sure you have the right to "sell" most software in GNU
Guix, but you're free to distribute it and even charge for the
distribution of it, and use it in products that you sell to customers.

Most licenses do not give you ownership of the software; they roughly
give you permission to use, study, modify, and share it under the terms
of that license. If you do not own it, I am not sure you can sell it...


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: FSDG issues of SCUMMVM-based games

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 5985 bytes --]


On 24-08-2022 22:24, Vagrant Cascadian wrote:
> Is it Functional Data:
>
>    https://www.gnu.org/distros/free-system-distribution-guidelines.html
>
>    "For example, some game engines released under the GNU GPL have
>    accompanying game information—a fictional world map, game graphics,
>    and so on—released under such a verbatim-distribution license. This
>    kind of data can be part of a free system distribution, even though
>    its license does not qualify as free, because it is non-functional."

SCUMMVM, among other things, interprets the bytecode of the games (see: VM).

A long time ago, I looked at the Debian package of one of the games, and 
there appeared to be only a single 'game' file IIRC, presumably this 
includes the bytecode.

Bytecode is code and hence functional, if 'functional' is interpreted in 
the narrow sense of 'it does a practical job'.

As such, I do not think this falls under 'non-functional data'

---

That paragraph also appears inconsistent to me. The world map, game 
graphics, sounds ... are one of the most important components of the 
game. If someone wants to modify the game, I consider it more likely 
they have to modify the world map and maybe add some graphics and sounds 
than that they have to change the engine. Seems pretty 'functional' to 
me. It also does a practical job: entertaining the user.

As such, it appears to me that if the ‘meh, it's non-functional data’ is 
non-free, then the game is effectively non-free ---- software does not 
just consist of code, the non-code parts are sometimes as important as 
the code or more important -- they belong together, as a whole.

Myself, being able to code but not good at art, I would rather have a 
non-free game engine with free non-functional data than the free game 
engine with non-free non-functional data that the FSDG refers to, at 
least I would with a sufficient amount of work (*) be able to replace 
the non-free engine, but don't ask me to replace the artwork ...

(*) and some assistance, depending on the size and complexity.

---

Another thing I would like to note is that, even if it were 
non-functional data, according to (guix)Software Freedom everything in 
Guix is free software:

> The GNU operating system has been developed so that users can have
> freedom in their computing.  GNU is “free software”, meaning that users
> have the four essential freedoms
> (https://www.gnu.org/philosophy/free-sw.html): to run the program, to
> study and change the program in source code form, to redistribute exact
> copies, and to distribute modified versions.  Packages found in the GNU
> distribution provide only software that conveys these four freedoms.
(I'm interpreting 'GNU operating system' and 'GNU distribition' as 
'Guix' here.)

That paragraph, and the web page referred to there does not make an 
exception for non-functional data -- if it's software, the 4 freedoms 
should apply, this is usually code but the freedoms and the reasons for 
them apply to software in general, not for code in specific.

To me, it appears that the SCUMMVM games cannot be in Guix, because of 
that rule.

It is, however, contradicted by the following paragraph, which is also a 
bit misleading:

>    In addition, the GNU distribution follow the free software
> distribution guidelines
> (https://www.gnu.org/distros/free-system-distribution-guidelines.html).
> Among other things, these guidelines reject non-free firmware,
> recommendations of non-free software, and discuss ways to deal with
> trademarks and patents.
I consider it contradictory in the sense that it adds exceptions to the 
'software must be free' claimed by the the previous paragraph, without 
being explicit that there are exceptions (see: non-functional data). I 
consider it misleading in the sense that the phrasing implies it just 
adds a bit of rules (on top of the 4 freedoms thing) and advise on 
potential legal problems, even though it also carves out a few 
exceptions (see: non-functional data).

> You cannot sell the game itself, but you can charge "a reasonable
> copying fee" and distribute it commercially... while slightly confusing
> and seemingly contradictory at a passing glance, those two clauses alone
> do not appear to violate any of the four freedoms to me:
>
>    https://www.gnu.org/philosophy/free-sw.html#four-freedoms
While initially I thought of it as 'a no-selling clause -> 
non-commercial only -> non-free', after your explanation I agree -- it 
does not appear to have the potential problems referred to in 'Free 
software can be commercial' and there is no explicit 'The freedom to 
sell software.'.

> I'm not really sure you have the right to "sell" most software in GNU
> Guix, but you're free to distribute it and even charge for the
> distribution of it, and use it in products that you sell to customers.
>
> Most licenses do not give you ownership of the software; they roughly
> give you permission to use, study, modify, and share it under the terms
> of that license. If you do not own it, I am not sure you can sell it...
Agreed, though myself I am considering this from another perspective -- 
everything in Guix is gratis ('free' in the commerce sense), usually it 
appears that upstream _wants_ it to be available at zero-cost though 
maybe I'm projecting here, so to me attempts to sell the software would 
appear to be a scam to me, with some exceptions (*).

Some scams being illegal, maybe this one would be too, and hence no 
right to 'sell' the software ...

(*) E.g., sometimes you can 'buy' a license to the software but what it 
really means is that you are paying the developers to keep working on 
that software -- in case of tome4, it's even explicitly named a donation 
instead of buying. I do not recall an example where it was phrased as 
buying though ...

Greetings,
Maxime.



[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

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

Re: FSDG issues of SCUMMVM-based games

[zimoun]

Hi Liliana,

(I have no opinion about this topic.)


Your quote is:

>> The data included in the source package represents the preferred form
>> for modifications.
>> If they were licensed under the G P L it would fail the "preferred
>> form of modification" requirement

but from the mentioned link [1], the quote includes a _but_:

--8<---------------cut here---------------start------------->8---
                                                                       If they
 were licensed under the G P L it would fail the "preferred form of
 modification" requirement, but its BSD-like license grants you all the
 necessary rights to modify, use and distribute them.
 .
 While there likely was, once upon a time, a custom set of tools to create this
 game data, those tools do not exist any more.  The original creators of the
 game are in the same situation as Debian's users when it comes to
 modifications.
 .
 Also, the reason for requiring the "preferred form for modification" is to not
 put the creator of the software/data in a "monopoly" situation. This isn't the
 case here.
--8<---------------cut here---------------end--------------->8---


> As far as I'm concerned, "preferred form of modification" should not be
> dependant upon the license in question.  Speaking of the license in
> question, it's prohibition of selling is nowhere mentioned.

My understanding of the Debian argument is:

 1. the licence is BSD-like respecting the Debian Free Software Guidelines

 2. point #3 of DFSG [2] says «The license must allow modifications and
 derived works, and must allow them to be distributed under the same
 terms as the license of the original software.»

 3. considering game data, all people are equals – from original author
 to users – because the tool set for modifying these game data does not
 exist anymore

Therefore, drascula is part of the ’main’ Debian archive, scummvm too.

Tobias wrote [3]:

        Either the inclusion of [a subset of] Drascula in Trisquel[0] is
        a similar oversight, or we're missing some legal subtlety.

so maybe some legal subtlety is indeed missed.  Let wait an answer by
FSF licensing department… if any. :-)
 

1: <https://metadata.ftp-master.debian.org/changelogs//main/d/drascula/drascula_1.0+ds4-1_copyright>
2: <https://www.debian.org/social_contract#guidelines>
3: <https://yhetil.org/guix/87iln5a0u9@nckx>


Cheers,
simon

Re: FSDG issues of SCUMMVM-based games

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 2262 bytes --]


On 24-08-2022 22:24, zimoun wrote:
> My understanding of the Debian argument is:
>
>   1. the licence is BSD-like respecting the Debian Free Software Guidelines
>
>   2. point #3 of DFSG [2] says «The license must allow modifications and
>   derived works, and must allow them to be distributed under the same
>   terms as the license of the original software.»
>
>   3. considering game data, all people are equals – from original author
>   to users – because the tool set for modifying these game data does not
>   exist anymore
>
> Therefore, drascula is part of the ’main’ Debian archive, scummvm too.

I remember (3). I find this an interesting argument.

As far as I know, the 4 freedoms and the whole 'free software!' thing 
was not a goal in itself, but rather a means to  a goal, a response to 
'many times some people and organisations have imposed impractical 
restrictions on software, causing problems (example: this situation in 
19NN, that situation in 20??, ...) -- can we identify the problems and 
generalize until we have a set of rules (4 freedoms) that need to be 
respected to avoid the problems?'.

As far as I know, drascula situation is not comparable (see: 'all people 
are equals') to the old problems. Yet, I cannot say it's free software 
(without the tools, it's effectively a binary instead of source code 
until, if ever, the tools are reinvented) (see some of my other 
responses in this thread).

As such, do the 4 freedoms need some refinement to accept drascula, do 
we have to weaken our requirement of 'only free software' for special 
situations like this one, or do we remove drascula, or is there somehow 
a fourth option I'm not thinking of?

Myself, I do not know the answer. However, I cannot help with the first 
option, the second sounds iffy to me (the exception would need to be 
worded really well, or it would be a 'case-by-case' matter which could 
take a long time to decide case-by-case, and in both cases it doesn't 
seem to fit in 'GNU: free software!').

As such, for me, only the third (removing drascula) is practical for me, 
but there are other people here too which could perhaps, say, do the 
first or something ...

Greetings,
Maxime.


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

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

Re: FSDG issues of SCUMMVM-based games

[Tobias Geerinckx-Rice]

I got an auto-reply with a ticket number from the FSF, but no answer yet.

I was aware of and unimpressed by Debian's rationalisations on the matter.

Still, this isn't as clear-cut as (say) the Realtek drivers, so IMO we can afford to wait as long as is needed.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

Re: FSDG issues of SCUMMVM-based games

[Tobias Geerinckx-Rice]

In a strange coincidence (I mean, I assume they don't troll our lists...?), I just got a friendly reply to assure me we've not been forgot.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.