Re: FSDG issues of SCUMMVM-based games
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 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
Hi again, On Tue, 20 Jun 2023 06:30:26 +0200 Liliana Marie Prikler 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. pgpVkcUvYwhG5.pgp Description: OpenPGP digital signature
Re: FSDG issues of SCUMMVM-based games
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
Liliana Marie Prikler 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 signature.asc Description: PGP signature
Re: FSDG issues of SCUMMVM-based games
On Tue, 20 Jun 2023 06:30:26 +0200 Liliana Marie Prikler 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. pgp1puW4qmk7v.pgp Description: OpenPGP digital signature
Re: FSDG issues of SCUMMVM-based games
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 רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: FSDG issues of SCUMMVM-based games
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
On Sun, 18 Jun 2023 10:19:06 +0200 Liliana Marie Prikler 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. pgptxZctL0xvQ.pgp Description: OpenPGP digital signature
Re: FSDG issues of SCUMMVM-based games
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 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
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. pgpAh_A6KkrN5.pgp Description: OpenPGP digital signature
Re: FSDG issues of SCUMMVM-based games
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
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 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 0xe913 cfea - 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 no
Re: FSDG issues of SCUMMVM-based games
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.
Re: FSDG issues of SCUMMVM-based games
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
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. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: FSDG issues of SCUMMVM-based games
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. Mos
Re: FSDG issues of SCUMMVM-based games
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
On 2022-08-24, Liliana Marie Prikler wrote: > Am Mittwoch, dem 24.08.2022 um 14:53 +0200 schrieb Nicolas Goaziou: >> Liliana Marie Prikler 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 signature.asc Description: PGP signature
Re: FSDG issues of SCUMMVM-based games
Am Mittwoch, dem 24.08.2022 um 14:53 +0200 schrieb Nicolas Goaziou: > Hello, > > Liliana Marie Prikler 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
Hello, Liliana Marie Prikler 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
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 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
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 DateTimeName - -- - 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
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. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: FSDG issues of SCUMMVM-based games
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 signature.asc Description: PGP signature
Re: FSDG issues of SCUMMVM-based games
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 signature.asc Description: PGP signature
FSDG issues of SCUMMVM-based games
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: ScummVM
ng0 writes: > ng0 transcribed 3.2K bytes: >> Hi, >> >> I haven't checked the source code repo yet for licenses included except the >> obvious stated ones. >> Last week I wrote on IRC that it contains proprietary engines (or something >> along this lines). >> Memory served me wrong, there's only stable and unstable engines. This is >> from my current build log. >> Now, last time I started scummvm was maybe over 10 years ago so I don't know >> if anything of this >> requires the original disks etc and if that is okay by GFSDGL. I have some >> backups of my original >> floppies, so I'll test ScummVM later today and see what works and how it >> works (I didn't read their >> Manual or website so far). Or if it works at all. At least it build without >> issues now. > > Update: I tried "Day of the Tentacle" and "Mystery House", both worked. > I'll give one of my Indiana Jonesand Monkey Island games a try tonight. Beneath a Steel Sky is a cyberpunk ScummVM game: https://en.wikipedia.org/wiki/Beneath_a_steel_sky And it's distributed in Debian... I think it's even in Debian main? http://metadata.ftp-master.debian.org/changelogs/main/b/beneath-a-steel-sky/beneath-a-steel-sky_0.0372-6_copyright
Re: ScummVM
ng0 transcribed 3.2K bytes: > Hi, > > I haven't checked the source code repo yet for licenses included except the > obvious stated ones. > Last week I wrote on IRC that it contains proprietary engines (or something > along this lines). > Memory served me wrong, there's only stable and unstable engines. This is > from my current build log. > Now, last time I started scummvm was maybe over 10 years ago so I don't know > if anything of this > requires the original disks etc and if that is okay by GFSDGL. I have some > backups of my original > floppies, so I'll test ScummVM later today and see what works and how it > works (I didn't read their > Manual or website so far). Or if it works at all. At least it build without > issues now. Update: I tried "Day of the Tentacle" and "Mystery House", both worked. I'll give one of my Indiana Jonesand Monkey Island games a try tonight. > Here's the list/output: > > Engines (builtin): > SCUMM [all games] > Access > ADL > AGI > AGOS [all games] > Lord Avalot d'Argent > Beavis and Butthead in Virtual Stupidity > Blade Runner > CGE > CGE2 > Chewy: Esc from F5 > Cinematique evo 1 > Magic Composer > Cinematique evo 2 > Lost Eden > Macromedia Director > Dungeon Master > Dragon History > Drascula: The Vampire Strikes Back > Dreamweb > Full Pipe > UFOs > Gobli*ns > Groovie [all games] > Hopkins FBI > Hugo Trilogy > Kyra [all games] > Labyrinth of Time > The Last Express > Lure of the Temptress > MacVenture > MADE > MADS > Mohawk [all games] > Mortevielle > Neverhood > Parallaction > The Journeyman Project: Pegasus Prime > Plumbers Don't Wear Ties > The Prince and The Coward > Flight of the Amazon Queen > SAGA [all games] > SCI [all games] > The Lost Files of Sherlock Holmes > Beneath a Steel Sky > Sludge > Broken Sword > Broken Sword II > Broken Sword 2.5 > Teen Agent > TestBed: the Testing framework > Tinsel > Starship Titanic > 3 Skulls of the Toltecs > Tony Tough and the Night of Roasted Moths > Toonstruck > Touche: The Adventures of the Fifth Musketeer > TsAGE > Bud Tucker in Double Trouble > Voyeur > WAGE > Wintermute > World of Xeen > Z-Vision > > WARNING: This ScummVM build contains the following UNSTABLE engines: > Lord Avalot d'Argent > Blade Runner > Chewy: Esc from F5 > Lost Eden > Macromedia Director > Dungeon Master > Groovie [Groovie 2 games] > The Last Express > MacVenture > Mohawk [Where in Time is Carmen Sandiego?] > The Prince and The Coward > SAGA [SAGA 2 games] > Sludge > TestBed: the Testing framework > WAGE > World of Xeen > > -- > A88C8ADD129828D7EAC02E52E22F9BBFEE348588 > https://n0.is -- A88C8ADD129828D7EAC02E52E22F9BBFEE348588 https://n0.is signature.asc Description: PGP signature
ScummVM
Hi, I haven't checked the source code repo yet for licenses included except the obvious stated ones. Last week I wrote on IRC that it contains proprietary engines (or something along this lines). Memory served me wrong, there's only stable and unstable engines. This is from my current build log. Now, last time I started scummvm was maybe over 10 years ago so I don't know if anything of this requires the original disks etc and if that is okay by GFSDGL. I have some backups of my original floppies, so I'll test ScummVM later today and see what works and how it works (I didn't read their Manual or website so far). Or if it works at all. At least it build without issues now. Here's the list/output: Engines (builtin): SCUMM [all games] Access ADL AGI AGOS [all games] Lord Avalot d'Argent Beavis and Butthead in Virtual Stupidity Blade Runner CGE CGE2 Chewy: Esc from F5 Cinematique evo 1 Magic Composer Cinematique evo 2 Lost Eden Macromedia Director Dungeon Master Dragon History Drascula: The Vampire Strikes Back Dreamweb Full Pipe UFOs Gobli*ns Groovie [all games] Hopkins FBI Hugo Trilogy Kyra [all games] Labyrinth of Time The Last Express Lure of the Temptress MacVenture MADE MADS Mohawk [all games] Mortevielle Neverhood Parallaction The Journeyman Project: Pegasus Prime Plumbers Don't Wear Ties The Prince and The Coward Flight of the Amazon Queen SAGA [all games] SCI [all games] The Lost Files of Sherlock Holmes Beneath a Steel Sky Sludge Broken Sword Broken Sword II Broken Sword 2.5 Teen Agent TestBed: the Testing framework Tinsel Starship Titanic 3 Skulls of the Toltecs Tony Tough and the Night of Roasted Moths Toonstruck Touche: The Adventures of the Fifth Musketeer TsAGE Bud Tucker in Double Trouble Voyeur WAGE Wintermute World of Xeen Z-Vision WARNING: This ScummVM build contains the following UNSTABLE engines: Lord Avalot d'Argent Blade Runner Chewy: Esc from F5 Lost Eden Macromedia Director Dungeon Master Groovie [Groovie 2 games] The Last Express MacVenture Mohawk [Where in Time is Carmen Sandiego?] The Prince and The Coward SAGA [SAGA 2 games] Sludge TestBed: the Testing framework WAGE World of Xeen -- A88C8ADD129828D7EAC02E52E22F9BBFEE348588 https://n0.is signature.asc Description: PGP signature