On Mon, 12 Jun 2023 17:37:39 -0400 John Sullivan <j...@wjsullivan.net> wrote: > > What an exaggeration! Writing a free game is a lot of work. The > > small preparatory task of getting and installing ScummVM would > > hardly discourage anyone who is prepared to do that work. > > > > Says who? If I have an hour to sit down and work on something, I would > like to spend that hour working on the thing, not downloading and > building dependencies, and then the next Friday when I have an hour, I > have to see if the dependencies are updated, and rebuild them > manually. And dependencies interrelate -- one of the main reasons we > have distros in the first place. Manually maintaining some things on > a system while other things are packaged is a notoriously fraught > thing to do. Packaging is an important and valuable convenience that > eliminates a lot of yak shaving. For ScummVM you have to do that anyway. You need to: (1) Build the IDE for AGI I mentionned. (2) Find a template for it and audit the license. (3) Start building a game
Building ScummVM looks really easy compared to building the AGI IDE. The AGI IDE needs qt4, so you will probably need PureOS for building and running it. And if you don't have PureOS you might need to use docker or install PureOS in some other way (Parabola can debootstrap PureOS, you can also install it in a VM). > The discussion here is dismissing the relevance and importance of this > *private* software. This is the dangerous path you go down when > banning software from endorsed distros just because it doesn't have > released, packaged free software for it. This private software could > be released in the future as free -- but even if it isn't, > facilitating private software experimentation and development is a > free software value. As I understand there was no general rule made for that nor about forcing distros to remove software like wine that has perfectly valid free software use cases despite also having more nonfree software that works with it. So it's up to the distro to assess the value of the software they package. And as you point out that doesn't remove the rule not to steer users toward nonfree software, so for instance the package description could be adjusted not to do that in any case. I'm unsure if the question of not having any free software for a VM was addressed but it could make sense not to package VMs that can't run free software as it would effectively steer users toward nonfree software, so we don't even need to modify the FSDG for that, just to clarify it. So here if we require free software to run in VMs, for ScummVM it would mean making sure that there is some free software for it. So in practice you could package a free AGI IDE, and confirm that it works by building and running a free software program inside ScummVM. And once done it would enable people to easily write free software games for ScummVM too, so I don't see any downside here of at least requiring that. Packaging the games might not be easy though as I don't know command lines tools to build them. But at least the distribution could point to third party repositories of 100% free games, or ship the games with their source code without rebuilding them themselves. As for private software I'll explain more why requiring free software doesn't impact private software below. > I think so, but I'm not sure. I didn't think the FSF was in the > business of judging whether this is a good way to write a game or > not. Was a decision took by the FSF? By Richard? Or was it took by GNU? Or did we take it by discussing it? It's unclear to me if any decision was taken so far. Richard only told that: > I conclude that excluding ScummVM will be no loss to free software. As I understand this is true. But I'm unsure if it really forces distributions to remove ScummVM nor to remove similar software. The way to go would probably be to follow the procedure that are already in place and well understood by distributions and have software to be removed added here: https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines And this page has the following: > Please do not add a package to this list until it's been discussed on > the gnu-linux-libre mailing list and/or with RMS. Some corner cases > can be tricky to decide, and it's good to take time and make sure we > have the right decision before listing something. Thanks for your > help with this. And here that removal could very easily be justified because we're not sure that free software *can run* inside ScummVM. We're also not sure that users writing private software can really do that at all. So we don't need to weight usefulness nor say that this is a bad way to write games, etc. If you take a JavaScript VM for instance, users can easily write code in a text file, and add a license header to it, add a copy of the license, and it's done. Here's an example (copy that in hello.js and run with 'gjs hello.js'): > print("This software is released under the CC-0 License."); > print("hello world"); So in most cases it's really trivial justify, and the proof can be added in mails, commit messages, an whatnot. And when it's hard to justify, then the free software in question becomes really necessary as it can be used as a basis for other software too, like other free software or private software. For ScummVM how do we know running free software in it is even possible? Do you also need nonfree software to make private software? For instance we don't know if the templates for AGI games are free or not since nobody reviewed their license. We don't know if the AGI IDE still works in FSDG distribution, we didn't review its dependencies, etc. There is some amount of efforts required to do all that. And people attempting to run free software or write private software for it might find out that it's not possible without even more efforts or not possible at all because some things are still missing. So that would mean that we would consider hypothetical software that doesn't exist or that isn't audited as a valid substitute for free software. In that case all lock down computer hardware (games consoles, iphones, etc) would be fine because FSDG distributions could hypothetically run on them (with lots of efforts, that might turn out to be impossible because nobody managed to break the security of that hardware to run free software). Formats that can't be read with free software are also OK because there would be hypothetical software to use them. To be really complete, a VM that runs nor free nor nonfree software can also exist (like with Malboge[1]) and writing software for it could be made a challenge. But then if the first software for it is nonfree it would steer users toward nonfree software (unless there is a mechanism to enforce free software without dependencies). So I see no issues at all with requiring requiring free software to be able to run inside a VM. And for most cases it's trivial to prove. And this also guarantee that you can run private software without nonfree dependencies inside it too. > This may be a niche thing either way -- these are not super > popular proprietary games anymore either. But I don't see why people > who appreciated these games before and now know about free software > might not also be interested in working on free games to share, or > even just free bits to play around with on their own to learn. The > state of free software gaming is terrible, and many of us are still > playing free software games from 30+ years ago. So purging any > working free game framework just because it doesn't already have free > games for it seems like a bad idea to me, anyway. There is also the fact that ScummVM can run almost everywhere[2] so if you write a program for it it can run on almost everywhere. References: ---------- [1]https://en.wikipedia.org/wiki/Malbolge [2]most GNU/Linux distributions, Nonfree OS (Windows, Windows XP, Windows 95, Mac OS, mac OSX, iOS), Snap, Flatpak, various game consoles (Playstation 3, viita, PSP, Dreamcast, Nintendo DS, 3DS, Wii, Siwtch), Android (32 and 64bit ARM, x86), some non-fsdg OS (KolibriOS, Haiku, Amiga, Morphos, RiscOS, Atari). Denis.
pgpodrbQTE3o1.pgp
Description: OpenPGP digital signature
