On Mon, 29 May 2023 16:43:03 -0400 bill-auger <bill-auger@peers.community> wrote: > of course, the option exists to write a new game for the engine; but > i do not consider that to be a use-case, worthy of distro support - > that option is trivial - the option to "write your own software" > always exists, with or without an existing engine, framework, > toolkit, etc I think writing a new game is a perfectly valid use case.
Otherwise there would also be no point in packaging very useful development tools like compilers for other CPU architectures that are often (but not always) not used at all by users or by the distribution to build other packages. So another point of view here could be to treat ScummVM as a development tool, but this doesn't change things much as the same question pops up again but in a different form: is it possible to write a hello world program with free software and run it in ScummVM? We have an example with wine: Some time ago, I've validated that GNU hello can run in Parabola's Wine, and that program was built with 'guix build --target=x86_64-w64-mingw32 hello', so if that's not a sufficient proof here we start having way bigger issues: - The question of what software is or isn't useful starts popping up. For instance is Wine notepad application useful? Do we keep Emacs because it can be seen as a development tool? What if people use tools for things they are not intended to and rely on that? A GNU hello package can for instance be used as a test case for a toolchain and also as an example of well made package. - Then if we require something like VLC to run on wine, we'd have to find an FSDG compliant binary for it. So we'd need to make sure it doesn't bundle nonfree system libraries and be prepared to make our own binaries if there are these libraries. At the end of the day that would probably require to maintain a build system for these binaries. - The question of usefulness pops up again if we only have applications that also run fine on GNU/Linux (like VLC). But in another hand making releases and (automatic) testing of portable software without nonfree software can be useful. - Strategically being able to ship FSDG compliant software on top of nonfree OS is also something we probably should not loose. In some cases the usefulness of software like GNU Taler is directly tied to our capacity to write and distribute free software for these nonfree OS as well. - It also brings the use case of FSDG distributions, I think that we should also in general support the use case of writing code or learning programming languages, etc, even if at the end that code isn't packaged or if it's not useful. So if we assume that a hello world is good enough, the next question would be here again to understand what to do if we don't know if there is any free software for it that works (either games or a hello world). Assuming that things are fine because nobody did the investigation work is not a good idea. Assuming the opposite also doesn't work. So the only option left is to accept that we don't know and then decide what to do when we don't know. There is also a perception of risk that can go into the equation and enable distributions to take different decisions based on the risk of nonfree software. The issue here is that this is also subjective as not everybody has the same knowledge about where nonfree software can hide. And here I don't see anything in the FSDG criteria that could tell all the distributions to remove software if there is some uncertainty because nobody did the work of auditing that software. So I guess that until something is decided it would be up to the individual distributions to make their own policies about that. > as a related side note: the "List of software that does not respect > the Free System Distribution Guidelines" is currently highly > contentious - it is effectively a FSDG criteria; but it is very > out-dated and inaccurate now - it has not been maintained since about > 10 years ago - i for one, believe that it should be actively > maintained; but as things stand today, no changes will be made There is a chicken and egg issue here, if nobody cares to update it because it's unmaintained, it indeed won't work. So a way out of that is precisely to propose modifications to it. And that's precisely what I tried to do but I missed part of the license that makes the case less clear, so the software I chose were probably not the best one to start this process again. Denis.
pgp9k2Kb2TFse.pgp
Description: OpenPGP digital signature