On Mon, 12 Jun 2023 01:35:14 +0200 Denis wrote: > Richard Stallman <r...@gnu.org> wrote: > > I think the question at hand is a little different from that. > > I don't think that _some nonzero amount of free software that runs > > on the environment is necessarily enough to outweigh the fact > > that its main use is as a way to run nonfree software. > > But what I'm concerned here is more the long term side effects of a > rule that requires to weight the usefulness of software and use cases
i think though, that no one suggested making a rule about these - as i remember, the original topic of this thread (the original "question at hand") was to determine whether or not the games, which debian has deemed "free" (eg: 'bass'), are also acceptable by the FSDG (a practical concern) - IIRC, it was determined that they are unfit - the discussion then drifted to the broader issue of how (or if) that affects the free game engine's legitimacy (a philosophical concern) i offered only the practical perspective - namely, that these pose no certain impediment to software freedom; so it is of no specific concern per the FSDG - in which case, distros may decide it each for themselves; and a valid argument against them, is simply supply vs. demand (or: workload vs. desirability) - the absence of ready-to-use free games, decimates the demand (desirability) for ready-to-use binaries of the engine; and so the importance of supplying them is very low the other arguments posed, along the lines of encouraging use of the non-free games, are more philosophical or political than practical - that aspect of it has been discussed over the years, more than the practical aspects i can offer one example - about ten years ago, the parabola devs had that discussion and made a decision - they introduced a conflict-inducing meta-package 'your-emu-freedom', which prevents the package manger from installing reverse-engineered emulators for proprietary gaming hardware and 1980s-era home computers - that decision was on the basis that although some free software does exist for those emulators, the vast majority is non-free (illegitimate "rips" of original game ROMs) - given that parabola never distributed any software for those emulators; their presence in the repos has always been a suggestion to acquire software from a third-party - parabola generally recommends against acquiring any software from any third-party (free or not); so the presence of those emulators in the repos was always dubious, and ripe for controversy however, as a "rule", those emulators were not excluded; and the guard package is optional - it was decided not to impose that philosophical/political decision onto users (ie: it does not need to be a rule); but instead, to let each user decide whether these dubious emulators posed a risk to their freedom, with the optional 'your-emu-freedom' meta-package serving as an educational warning and guide of course the option remains to write some new software for those emulators yourself; but practically speaking, that requires learning some specialized esoteric programming language or machine code for those obsolete CPUs - the use-case of playing the many readily available games, is itself very small - the use-case of writing new software for those machines is much smaller, as to be negligible IMHO - i contend that unless the distro offers some free software for use with the free tool, the presence of the free tool suggests its most popular use-case (acquiring some from a third-party which does not follow the FSDG) therefore IMHO, this reduces to the TPPM problem (generally: a free program which primary use-case is to support a third-party curated, and/or primarily non-free class of software) - in other words, the docker example is analogous, but far more relevant than any game machine emulator, due to its popularity and utility - we would be much more productive to focus on offering curated software for those TPPMs - these game engines on their own, are hardly worth this much discussion On Mon, 12 Jun 2023 01:35:14 +0200 Denis wrote: > Since most of the docker images are not FSDG compliant, do we remove > Docker completely? Since Guix can also generate docker images that case seems significantly different; because the tool itself offers an easy way to generate the guest software automatically, with essentially no input nor expertise on part of the user eg: `docker create trisquel-11` or: `guix create docker` with a bit of modification, docker could generate images with software exclusively from the distro repos - that would be the ready-to-use equivalent of "some libre games exist for scummvm, _and_ the distro distributes some of those"; which we now know can not be satisfied - in the case of docker, pip, and the many other TPPMs, it could be satisfied On Mon, 12 Jun 2023 01:35:14 +0200 Denis wrote: > And if we don't cover these use cases in FSDG distributions, it would > give more advantage to non-FSDG compliant solutions and push people > toward them (for efficiency reasons for instance). not to drift off-topic, but i would point out that this is the same argument people gave when the parabola devs (namely: "gnutoo") decided to remove 'pip' from parabola's repertoire; though in this case, gnutoo is employing the same rationale to suggest keeping the controversial tool due to the popularity of 'pip', some users lamented that its exclusion makes parabola less useful to python developers and sysadmins, who may be persuaded to acquire the tool from a third-party, or to use another distro instead FWIW, though i objected loudly at the time, i was in general agreement with the decision to remove it (and the others) - my objections were due to the pain and controversy incited by that move - the discussion of "what to do about TPPMs" is long overdue to be revived on this mailing list i see the FSDG concern of pip and docker as equivalent (TPPMs), and closely related to that of emulators; so the arguments for and against them should apply generally - both pip and docker would need to be treated, to allow them use only FSDG-fitness curated remote repo sources, and IMHO, such repos should exist, in order to justify their inclusion in FSDG distros - the main difference is that the emulators would not need libre treatment (most do not suggest any specific guest software or repos) - only the curated software would be needed, to make those uncontroversial
