Re: [GNU-linux-libre] Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines".

[Felipe Sanches]

> "why does the distro make this program available? for what
task is it useful?" - the only answer to give is: "it's only known use is for

playing non-free games; but this distro has none of those available"

Well... another valid reply could be:

"It creates a runtime environment equivalent to the one that was used on those proprietary games, but you can use your creativity to program other games to run on that same kind of environment. The technical aspects of such runtime may lead to an interesting creative-coding challenge in which one can experience the quirks and limitations of the platform in which those games were originally developed. To some extent, it also has historical value, as it helps one to better grasp how game development worked in that era."

Em qua., 7 de jun. de 2023 às 17:13, Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> escreveu:

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.