Re: [GNU-linux-libre] Parabola packaging
Thank you, Richard. This is precisely why I continue to support the FSF. While it’s easy for some outsiders (which I am in this dialog, at least) to follow these conversations and wonder at all the fuss or at the occasional difficulty in reaching consensus, I maintain that not having the FSF would be detrimental. - GNUian On Tue, Jul 4, 2023 at 7:07 PM Richard Stallman wrote: > > The point of a free distro is that _it checks for you_, so if you > only install what it recommends, you are safe from nonfree software. > > The other benefit of a free distro is that, by recommending it, > we never give users the impression that we think some nonfree program > is acceptsable to recommend. > > >
Re: [GNU-linux-libre] Parabola packaging
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > if (OS, container, software, etc) contains non-free software > then don’t use it > else-if (OS, container, software, etc) is free AND allows non-free software > to run > then use > AND don’t install supported non-free software That is an adequate way to protect _yourself_ from running nonfree, but it requires you to check everything yourself. That is hard work, and (being human) sometimes you will neglect to check and end use the offered nonfree softwasre. The point of a free distro is that _it checks for you_, so if you only install what it recommends, you are safe from nonfree software. The other benefit of a free distro is that, by recommending it, we never give users the impression that we think some nonfree program is acceptsable to recommend. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)
Re: [GNU-linux-libre] is the license of 'bass' acceptable?
On Tue, 4 Jul 2023 20:34:25 -0400 bill-auger wrote: > if that is the path forward, let us begin so to begin that debate, i need only to quote my previous message > gnutoo and i believe that per its explicit wording, it is non-free and add that, now jason concurs: its words, however confusing, make it non-free > ruben suggested that the wording is confusing, and that GNU has previously > established a precedent, which accepts a license with the same confusing > requirement, and so it should be acceptable OTOH, the rationale for accepting the OFL license makes perfect sense to me also - the 'bass' license does appear to afford that same interpretation - i would not hesitate to change my vote to "yay", if that is the only way to prevent this matter from remaining resolved for years to come (and by "resolved", i mean decided _and_ duly treated in all FSDG distros, which could be painful if those OFL fonts are under scrutiny, or simply never done) so again: > how shall we resolve this? if this were only an FSDG concern (no changes would need to made to the GNU licenses list), we could resolve it by consensus on this list (currently: "get rid of 'bass'" has favor) - but if the "nays" have it, then we _must_ revisit the SIL OFL decision and probably overturn it, demoting its status on the GNU licenses list, and opening a can of worms where we need to ask all of the distros to remove them, however painful removing them is likely to be - we have not a good track record of convincing distros to follow the work-group's recommendations; so i am not enthusiastic about going down that long and arduous path in any case, AFAIK the status of the SIL OFL would be a decision which only RMS can make, and that discussion, if any is necessary, probably belongs on a different mailing list - after that is decided, the unenviable task of convincing distros to purge those fonts from the system, would fall back upon us so, how do we proceed? - have we hit a brick wall on this already? - are there any more opinions or votes for "yay"?
Re: [GNU-linux-libre] is the license of 'bass' acceptable?
On Tue, 4 Jul 2023 17:03:21 -0700 Jason wrote: > Is it time to revisit the established precedent for the SIL Open Font > License? i dont know - that is exactly where the discussion left off - RMS suggested that; and AFAIK RMS is the one who made the previous determination, and only RMS could make the decision to overturn it - so its not clear where that leaves us at all i dont believe that any new information has come to light since that time; so there is probably nothing that any of us could do, other than debate the merits or flaws of the previous determination - if that is the path forward, let us begin however, i do believe that it may open a much larger can of worms though - probably 80% of all free fonts have that license
Re: [GNU-linux-libre] is the license of 'bass' acceptable?
On Tue, 4 Jul 2023 15:24:21 -0400 bill-auger wrote: > On Tue, 4 Jul 2023 15:05:27 -0400 bill-auger wrote: > > may we return to the original topic? > > ill do that one better - i changed the subject and will recap > > so far: > > gnutoo and i believe that per its explicit wording, it is non-free The license holds: > You may charge a reasonable copying fee for this archive I'm thinking of https://www.gnu.org/philosophy/selling.html which holds that > The one exception is in the case where binaries are distributed > without the corresponding complete source code. Those who do this > are required by the GNU GPL to provide source code on subsequent > request. Without a limit on the fee for the source code, they would > be able set a fee too large for anyone to pay—such as a billion > dollars—and thus pretend to release source code while in truth > concealing it. So in this case we have to limit the fee for source > in order to ensure the user's freedom. In ordinary situations, > however, there is no such justification for limiting distribution > fees, so we do not limit them. And so, in cases where distribution fees are not being limited, you should also be able to charge a distribution fee that's *un*reasonable, which makes this a non-free license. The license goes on to say: > You may not charge a fee for the game itself. This includes > reselling the game as an individual item. A program where you cannot charge for copies is also non-free. To me, both of those items plus what's stated in the preamble, tell me that the people were intending the copies be distributed gratis. > ruben suggested that the wording is confusing, and that GNU has > previously established a precedent, which accepts a license with > the same confusing requirement, and so it should be acceptable > > RMS threw us a curve-ball, and suggested that the previously > established precedent should be reviewed or revised first > > how shall we resolve this? Is it time to revisit the established precedent for the SIL Open Font License? pgpy6VXm7MXcJ.pgp Description: OpenPGP digital signature
[GNU-linux-libre] is the license of 'bass' acceptable?
On Tue, 4 Jul 2023 15:05:27 -0400 bill-auger wrote: > may we return to the original topic? ill do that one better - i changed the subject and will recap so far: gnutoo and i believe that per its explicit wording, it is non-free ruben suggested that the wording is confusing, and that GNU has previously established a precedent, which accepts a license with the same confusing requirement, and so it should be acceptable RMS threw us a curve-ball, and suggested that the previously established precedent should be reviewed or revised first how shall we resolve this?
Re: [GNU-linux-libre] Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines"
On Tue, 4 Jul 2023 16:24:24 +0200 Denis wrote: > One of the issue is also that the discussion has been conflating several > points together like running nonfree games, running free games, if > games are important or not, how to write games, etc. agreed - i remind everyone once again, the topic of this thread: "Adding some scummvm game(s) to the List ..." On Tue, 4 Jul 2023 16:24:24 +0200 Denis wrote: > - We don't know any free games. disagreed - we are yet to determine if the license of 'bass' is or is not acceptable - that is the only reason why scummvm is being discussed in the first place; but the discussion went completely off the rail 2 months ago - discussion of scummvm itself is relatively trivial; and it apparently caused one participant to unsubscribe - we should drop that topic for now, and complete the job we came here to do this discussion has exhausted my patience as well we must not leave issues hanging like that - it is a fundamental problem with this work-group today - there are already five other issues more important than bass or scummvm which are left undecided since years ago - four of them, i consider to be critical - "the List" itself deserves a long discussion of its own we need to strive for consensus on these issues, or we are doing nothing of importance on this mailing list - so i ask again, may we return to the original topic? "is the license of 'bass' acceptable?"
Re: [GNU-linux-libre] Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines".
On Sat, 17 Jun 2023 22:10:36 -0400 Richard Stallman wrote: > When you say what the hypothetical rule would "require", I am not sure > what that means. Who would the requirement be placed on? On the free > distros? On the GNU Project leaders? The free distros. > Are you talking about what we, the people in this discussion, ought to > do in future cases of programs that people ask us to think about? > > I would call that a duty, not a rule. We have no need to specify > in detail or rigidly how we will deal with these cases. What I'm interested is also how precisely we justify the advise to remove ScummVM because the same rationale would also likely be applied to other packages as well, to produce advises. And that would at least impact people that read these these advises, distributions that follow them, and the reputation of the FSDG criteria. Denis. pgpqggeSz67yD.pgp Description: OpenPGP digital signature
Re: [GNU-linux-libre] Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines".
On Mon, 19 Jun 2023 22:55:29 -0400 Richard Stallman wrote: > > but then ruben offered an example of one libre game which does > > exist for ScummVM, which would resolve ScummVM's loneliness > > problem, if it has one > > I don't think that is the right way to understand this issue. > It's a judgment call, not a logic problem. > > The question is not whether ScummVM false into the category of "0 free > games need it" or "1 or more free games need it". > > The question is whether the free games that need ScummVM are > significant enpugh to change the judgment from "basically this is a > way of running old nonfree games" to "this makes senss in the Free > World." > > There is no sharp line between the two. If there is "1 or more free games [that] need it", it's also possible to reduce the steering toward nonfree software by hiding ScummVM somehow as a dependency of these games. So in that case, it can be justified as reducing the steering toward nonfree software, and given ScummVM specificities (whitelist of games/programs checksums), applying the same logic to similar cases would probably not cause significant issues. Denis. pgpf01tS3l3Um.pgp Description: OpenPGP digital signature
Re: [GNU-linux-libre] Packaging JavaScript games
On Wed, 14 Jun 2023 06:30:04 -0400 bill-auger wrote: > i could have mentioned that there are a few examples of popular web > "apps" which have done this; but their user-friendliness is not great > - the 'element-web' package comes to mind - as i remember, the only > way to use it (and i had to deduce this myself), is to open a web > browser and browse explicitly to the file-system path, like: > file:///use/share/web-apps/package-name/webapp.html - not very > user-friendly One issue here would be to understand how this webapp.html page is created. If it's simply an HTML page created by hand it there is only the usability issue left. If not, packaging it properly might require significant effort, especially if there is a lot of dependencies (like some javascript minifier, some CSS compiler, etc). > unfortunately, i suspect that the problem of disposable software > would remain, for the more complex javascript applications - > regardless of which files you have locally installed, it is likely > that they are designed to constantly pull novel ephemeral scripts > from the network and execute them blindly - so those local files may > not always be a complete solution - they may be only boot-strapping > your way back to the original problem (merely "kicking the can down > the road" a step) Another point of view would be to find and package software that is not disposable, like the one I mentioned (Joan Jump) which is under a free license and currently doesn't have other dependencies than a web server and browser. This makes solving the problem much more doable since there is only usability to take care of (and it's not easy to fix but it looks doable with a bit of effort / thinking / trial and error). > also, it is not such a great idea for any package to install, > configure, and launch a web server automatically - that machine may > not have any firewall for example - i would be looking for solutions > such as 'element-web', which can launch exclusively from the local > file-system, via the file:// protocol; and only then, collaborate > with a server, local or remote - though, i suspect that many > javascript applications, as written, would offer at least some > resistance to that use-case Daemons have the same issue, but they typically use somewhat reserved TCP/UDP ports. And they usually don't need extra configuration in the client to work (like disabling fingerprint tracking, etc). Another way could be to patch the html file to have everything built in (like the JavaScript, the fonts, etc). Once done the browser configuration issue would need to be solved (for instance by shipping a profile just for that game, and finding a way to not disrupt the current browser usage). Denis. pgpguVb3frmJq.pgp Description: OpenPGP digital signature
Re: [GNU-linux-libre] Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines"
On Fri, 23 Jun 2023 23:21:30 -0400
Richard Stallman wrote:
> I am leaning toward making a statement in the appropriate place:
>
> ScummVM is obsolete technology, and hardly used for anything except
> running old nonfree games, so it contributes nothing significant to
> the Free World. People who want to develop free games have much
> better platforms to choose from. Therefore, we urge free distros to
> omit it, and to explain why they do so.
I'd prefer a statement like that, as it avoid judging the use case
("ScummVM is obsolete technology"):
We don't know if it is possible to run fully free software
games/programs inside ScummVM: so far nobody has managed to build
and/or review the source code of supposedly free software
games/programs for ScummVM under free distributions. In addition,
unless the ScummVM source code is modified, it can only run games
approved by its developers, so its source code would need to be
modified anyway to be able to run modified versions of free
games/programs.
Therefore, until we can confirm that there are really free
games/programs for ScummVM, we urge free distros to omit
ScummVM, and to explain why they do so.
Here a free game/program would also serve implicitly as a proof that
it's possible to write your own code that runs inside ScummVM.
Denis.
pgpP15tWxpOCR.pgp
Description: OpenPGP digital signature
Re: [GNU-linux-libre] Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines"
On Thu, 15 Jun 2023 23:07:34 -0400 Richard Stallman wrote: > Is there an actively maintained _libre_ replacement for ScummVM? I don't see the point of having a libre replacement for ScummVM unless there is free software that can run in it. If the goal is to have games/programs similar to what runs inside ScummVM we likely have alternatives to it (that are not drop in replacements). Renpy seems to be a game engine aimed at similar kind of programs/games. It probably has a lot of nonfree games made for it too but it also has free games/programs (like the renpy tutorial) and it has information on how to make your own game/program too. The downside is that it runs on less operating systems than ScummVM[1]. References: --- [1]For instance for a non-profit seeking to distribute tutorials on how to combat harassment at work for instance, the number of operating systems supported can be relevant. And this isn't incompatible with FSDG compliance and the promotion of free software and free operating systems / distros. Denis. pgpzM1SrTJdtd.pgp Description: OpenPGP digital signature
Re: [GNU-linux-libre] Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines"
On Fri, 16 Jun 2023 22:20:46 -0400 Richard Stallman wrote: > We have found no reason to consider ScummVM's inclusion in free > distros to be a good thing, but there remains the question of whether > its inclusion is harmful enough to state a position or rule, and if > so, what that should say. A rule not to include it would be the > strongest possible response, but a software response might be better. > > I thimk that a stated recommendation to omit ScummVM might be a good > measure to take now. > > It could refer to the documentation's promotion of nonfree games, that > you cited, and say that at least that promotion should not be in the > distro. Similar to Guix's decision on ScummVM, I think that the rationale could be that: - We don't know any free games. - As far as we know, ScummVM has a checksum whitelist, so: - If there is a free game whose checksum is in ScummVM it could be OK. But we'd need to point users to that game in the package description for instance. - If people package an FSDG compliant game, they'd have to add its checksums to ScummVM (at package build time for instance). - If instead some people manage to write a hello world for ScummVM and that the rationale is that ScummVM can (also) be used to write games, then a patch would need to be made to enable scummVM to load any game written by the user. And how to write a game would need to be documented too. So the current situation is that ScummVM steers users toward nonfree games/software, because we can't direct them to at least a single games/software or use case that is FSDG compliant with ScummVM. And so we have everything we need here to get ScummVM removed either in the short or longer term without having to decide which use cases are more important than other. And I think judging use cases is very important to avoid because: - It is incredibly hard to weight use cases right. For instance some people might remove virtual machines like qemu because it is mainly used to run nonfree OS, while for other people it's used for very different things like virtualization. Here this example is exaggerated on purpose to explain better the issue, but in practice it would likely be way less obvious and at the end discriminate less well known use cases. This in turn could lead to users having difficulties meeting their use cases with FSDG compliant distributions and/or fragmentation of users. - Because it can potentially have nasty side effects, if the logic that works well for one case is applied to another. For instance if a programming language interpreter has more nonfree software than free software written / distributed for it, it should be removed if we follow the same rules than with games. If it's not removed people might think that the process of removing software is being abused and biased negatively toward games and be shocked by the decisions. And if the language is removed, instead people needing that language could also be shocked by the decision. So I think it's better not to open this can of worms of judging what use cases are more important than others, especially because in the long run I don't see how to avoid the collateral damage that result from deciding on use cases. And here that collateral damage might not be visible but it would be very real as the community would likely be less healthy and diverse and smaller. One of the issue is also that the discussion has been conflating several points together like running nonfree games, running free games, if games are important or not, how to write games, etc. Here I'm assuming this is the case because some responses conflated two or more issues together. And that doesn't help seeing things clearly and it also tend to misrepresent people's position, which doesn't help to calm down the discussion. Denis. pgpixiZdeWD0J.pgp Description: OpenPGP digital signature
Re: [GNU-linux-libre] Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines"
On Thu, 15 Jun 2023 23:07:48 -0400 Richard Stallman wrote: > > > Guix is supposed to build everything from sources, right? > > It usually does. People in guix-devel report already > > pointed that the games was missing source code, so I added more > > infos about that. > > Guix is supposed to be entirely free software. > How can they justify the inclusion of these games, > they being nonfree? They will remove the games (if they didn't already) because they are not built from source. As for ScummVM they will wait a bit before removing it to leave some time to people (something like 1 to 5 years) to come up with some free games. They also found where to patch ScummVM to add new checksums, so if draci historie is packaged (a game with source code that needs packaging and/or a licensing review), it would also solve the problem too for Guix and ScummVM would be kept in the long run. Denis. pgp9G6IB9RuVo.pgp Description: OpenPGP digital signature
