Re: [GNU-linux-libre] third party package managers
On Tue, 1 Aug 2023 01:58:10 -0400 bill-auger wrote: > On Mon, 31 Jul 2023 17:39:02 +0200 Denis wrote: > > A way to find out here would be to understand if FSDG compliant > > distributions users really use third party software, and what kind of > > software they use. > so deleting them from parabola may not reveal any new information - a > distro like trisquel would need to run that experiment probably, i have not emphasized that as a motive yet - this is another good reason to ask distros to eject these _now_, before any work is done - that would reveal which ones are desirable to users, and which ones no one cares about, the information needed to know which of the dozens to prioritize - i dont know any other way to determine that, other than guessing
[GNU-linux-libre] third party package managers
On Mon, 31 Jul 2023 17:39:02 +0200 Denis wrote: > PureOS probably doesn't need to ship CPU microcode updates. that was why i mentioned it - that package is not part of pureos - it is kept on a puri.sm server; so it never conflicted with the FSDG puri.sm does have a desire to liberate the remaining blobs; but they are a special case as a hardware vendor _and_ a distro - other distros are not likely to ever liberate hardware On Mon, 31 Jul 2023 17:39:02 +0200 Denis wrote: > For Puri.sm hardware, Puri.sm can easily ship them in their Coreboot > images instead, which are not part of PureOS. > > Though I wonder if/they update their Coreboot image. Maybe they have > some way to do it that is outside PureOS. yes it looks like they have an coreboot/firmware update script, also not part of pureos - i found some information: https://puri.sm/faq/what-is-the-difference-between-libreboot-and-my-librems-coreboot-firmware/ https://puri.sm/projects/coreboot/ On Mon, 31 Jul 2023 17:39:02 +0200 Denis wrote: > I think the key disagreement we have is if programming language > repositories are useful or not. > > If we assume that they are useless, then they could indeed be removed > and the problem would also go away. of course it is useful; but it is only a convenience for the distro to distribute the package manager - they are very easy to acquire from the same third-party - so regardless of utility, removing them from distros is not a huge problem for anyone On Mon, 31 Jul 2023 17:39:02 +0200 Denis wrote: > I assume that they are badly needed, and that many users can't live > without them and so they need fixing. i think what youre really getting at, is that people will use them anyways, whether the distro provides it or not; so it is better to use a more freedom-respecting version from the distro my counter-argument there, is that we do not know yet, if anyone would use a libre-only version of pip or whatever - i looked at ruby one time - roughly half of all packages were not licensed - that means a libre-only version would be only half as useful a typical webby application setup will install about 100 dependencies - if any one of them is unavailable, that is a total deal-breaker for that person's use-case - most likely, the user will try to install some webby thing, but some dependencies will not be available - so that user, rather than decide not to install that webby thing, will instead stop using the libre-only version, and install the upstream version anyways that really puts in doubt how much liberation effort the TPPMs deserve - let alone to curate new libre-only repos, which maybe no one would use, because it is likely to be missing _something_ for every application On Mon, 31 Jul 2023 17:39:02 +0200 Denis wrote: > A way to find out here would be to understand if FSDG compliant > distributions users really use third party software, and what kind of > software they use. IMHO that was the most interesting goal of our experiment to remove pip and rubygems - only a few people complained about pip - in reality, more people objected before it was done, than who complained afterward - people complained about rubygems, but only because it prints a warning message to the shell, not because they wanted it back users of FSDG distros definitely use third-party software - typically applications (AUR packages, appimages, flatpacks); so that concern (who would miss them and why) could be considered as two broad categories: (language library TPPMS, and application TPPMS) the language TPPMS are normally used for installing an enormous number of packages; so they are notably worse - also the language TPPMS are normally used by the more tech savvy people, who would have no trouble installing the upstream's package manager if the distro does not provide it the application TPPMS are normally used by non-technical users, for installing a relatively small number of packages (though instide you will probably find much more than a single application) - i see that more often with LTS distro users, to get a newer version of an application which is in the distro repos as an older version for that reason alone, i would focus first on those (docker, flatpack, appimange, etc) - those are probably more desirable overall - i doubt if any parabola users would complain; because they can get all those applications from the AUR, so deleting them from parabola may not reveal any new information - a distro like trisquel would need to run that experiment so again, that work would be done primarily for other distros - parabola does not really need third-party application installers for twi reasons - A) parabola's application are the newest they can be - B) the AUR is a much better source for anything else, because the application gets built from source, and parabola has a native tool to build them easily - i would much rather tell parabola users never to use a flatpak or similar, but to grab a PKGBUILD from the AUR instead, or mak
Re: [GNU-linux-libre] emulators and other hosts of foreign applications
[[[ 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. ]]] > concentional generic VM - it is a scripted "game engine" - their "guest" I take your point, but I don't think that detail requires our attention. Let's not get lost in a tangent about that. -- 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] emulators and other hosts of foreign applications
While emulators are primarily used to play non-free games, people do make their own games for the hardware that these emulators emulate. The category is called homebrew, homebrew games, or homebrew roms. The concept of homebrew games is largely absent from this discussion. You can find these games by searching for the system name and homebrew. The freedom of homebrew games vary. Some are free. Some have missing licensing information. Some are nonfree. The authors tend to be much more approachable and willing to liberate their creations in my experience with license activism. Homebrew games are available for ScummVM, GameBoy, Sega Genesis, NES, SNES, etc. Best, Michael McMahon | Web Developer, Free Software Foundation GPG Key: 4337 2794 C8AD D5CA 8FCF FA6C D037 59DA B600 E3C0 https://fsf.org On 7/31/23 10:02, bill-auger wrote: On Mon, 17 Jul 2023 05:08:50 +0200 Denis wrote: So if we want to go the non-rigid way, defining requirements for each program like ScummVM can also work I think. agreed, "programs like scummvm" is a better as a recommendation, not only to mention that one example, which has known libre use-cases to focus such a warning on scummvm is missing its own target by a mile - many other programs of it's sort, but much more popular, are used almost exclusively for running non-free games
Re: [GNU-linux-libre] Parabola packaging
note the subject of this thread "Parabola packaging" - it seems that every thread on the mailing list has derailed onto a discussion of scummvm - i can not imagine why people are so fixated on this antique - fond memories? - jaded history? - i dunno - i do not see this as such important software - the same example could be made, probably as fittingly but more effectively, of its more popular modern successors please do mind the thread subjects though - people in the future will never be able to follow these recent discussion cleanly
Re: [GNU-linux-libre] emulators and other hosts of foreign applications
On Mon, 24 Jul 2023 21:22:50 -0400 Richard wrote:
> In theory, could be. In practice, usually not. With a VM or
> interpreter which people use to write new programs, there will be lots
> of new and free programs you can run on it. With an emulator there
> usually will not be. Thus, the ScummVM issue will tend to arise for
> emulators like ScummVM.
>
> The point is that this issue NORMALLY arises for emulators.
i do understand that point - scummvm is not an emulator though, nor a
concentional generic VM - it is a scripted "game engine" - their "guest"
programs are mainly configuration and data, with very little or no extra
executable code generally - generally what code there is, is rather trivial,
based on event hooks - the game "author" only writes bits like:
[door]
onActivate: playSound('creak')
[bomb]
onActivate: playSound('fuse')
onCollision: playSound('boom')
the "engine" does most of the work of the application, not merely hosting
external code like an emulator or VM
with modern game engines, the "author" rarely even needs to type -
configuration like "door.onActivate: playSound('creak')" can simply be selected
with a mouse from a menu - games are created more like a drag-and-drop
GUI-builder than a text editor and compiler
Re: [GNU-linux-libre] emulators and other hosts of foreign applications
On Mon, 17 Jul 2023 04:58:54 +0200 Denis wrote: > In the past some operating systems were removed. i know this; but that the past was so long ago, this story is but a legend, handed down to me by the elders - it simply could not happen today - that is all i want to do, is get it back to _some_ state of efficacy
Re: [GNU-linux-libre] emulators and other hosts of foreign applications
On Mon, 17 Jul 2023 05:08:50 +0200 Denis wrote: > So if we want to go the non-rigid way, defining requirements for each > program like ScummVM can also work I think. agreed, "programs like scummvm" is a better as a recommendation, not only to mention that one example, which has known libre use-cases to focus such a warning on scummvm is missing its own target by a mile - many other programs of it's sort, but much more popular, are used almost exclusively for running non-free games
Re: [GNU-linux-libre] emulators and other hosts of foreign applications
On Sat, 15 Jul 2023 22:19:12 -0400 Richard wrote: > > if it is intended to be vague, then obviously it can not have an explicit > > warning about any one specific program, only about the general indirect > danger > > of software with certain properties (in this case, software hosts with no > known > > libre clients) > > I can't see how you reach that conclusion because vague and specific are opposites - it loses cohesion to mix them On Sat, 15 Jul 2023 22:19:12 -0400 Richard wrote: > > that is why i was applauding a call for precision, > > To say, "We urge free distros not to include program XYZ" is entirely > precise. yes, but no other part of the FSDG is nearly so precise - it is quite odd for the only precise part to be the only optional part - i wish it was actively maintained and changed to be more and more precise as any confusions arise for a recent example, we had a great (and unproductive) discussion earlier this year about what qualifies as a "complete distro" - opinions varied wildly; because the FSDG and the FSF offer no real "guidance" on how to interpret it's vague criteria - that vagueness is not helpful - it is a waste of evryone's time
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, 25 Jul 2023 19:23:54 -0400 Richard wrote: > - the FSDG has never done anything like that > > That won't stop us! i was not suggesting that as an flaw - i was suggesting that as a virtue - it does not have warnings or optional suggestions now - it has only criteria - only "the distro must"s and "the distro should"s - nothing like "you could, but only if you want to" i dont believe that maintainers need such optional suggestions, nor care much for politicizing their projects (and care less to be "urged" to do so) - that is probably a large part of why most do not read this mailing list, and probably why riccardo objected so loudly of course, distros can do anything optional, if they want to - that should go without saying - the most i would do about this "urge", would be to send an email to each distro, offering the suggestion and rationale for it, _one_ time - or maybe establish a new wiki page for incoming distros to read some suggestions for how to portray software freedom (if they want to)
Re: [GNU-linux-libre] the straw that broke the camel's back
On Tue, 25 Jul 2023 14:07:03 +0200 Ricardo wrote: > This is certainly a more convenient position to take when the > alternative is to acknowledge defects in (or lack of) a > consensus-finding process — not just in how free distributions cooperate > (or rather *don’t*), but in any top-down decision. Unfortunately, this > is a common pattern in GNU and the wider community of free > distributions. im not sure what was the context of that; but i think i agree fully with that statement when i wrote that the FSF should be the leadership, that is mainly because distros can not agree on some of the most essential things like "is foo libre or not?"; and we are currently not allowed to do so by consensus it would be ideal to form a consensus perhaps with "guidance" from the top; as long as the community would be mature enough to accept the consensus, _whatever_ that is, and work to change the opinions of those in disagreement
Re: [GNU-linux-libre] the straw that broke the camel's back
On Mon, 17 Jul 2023 04:36:02 +0200 Denis wrote:
> Ricardo also seems to have perceived the Recommendation as
> authoritarian ("ban") and subjective ("arbitrary rules and personal
> interpretations of these rules").
FWIW, i have absolutely no problem with a strict and authoritative rules - i
can simply take those or leave them at face value; precisely because they can
not be taken subjectively - but i have a huge problem with weak subjective
guidelines - distros could simply accept the FSDG trophy, then go off and
guide themselves, strongly/weakly, subjectively/objectively, its all the same
if the shared guidelines are weak and subjective
On Mon, 17 Jul 2023 04:36:02 +0200 Denis wrote:
> In distributions with many maintainers and without clear leadership,
> recommendations like that might also lead to different interpretation
> across different maintainers.
or to splinter their community by forking a new distro, is another danger - it
is not clear if that is ever a good idea - eg: is debian plus devuan a benefit
to the debian community overall, or did it actually harm overall? -
unity/solidarity is quite important for a small community
the FSF should be our primary leadership for the most fundamental shared
concerns (eg: "is bass libre?", "is nmap libre?", and so on) - anything
optional or subjective should default to the distros - that separation avoids
_all_ controversy
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, 17 Jul 2023 04:10:23 +0200 Denis wrote: > It's not. There is the example of phoronix-test-suite that was accepted > in 2 FSDG distributions (Parabola and Guix) but rejected in the FSD > because it used a repository that contained nonfree tests. > > Parabola and Guix removed or blocked the nonfree tests, but as this > entry shows, the FSD deals with upstream, not distributions > modifications, even if it has a warning for some wine packages that > suggest nonfree fonts with it. that is exactly where i see them meeting - the FSD rejected it for some reason "A", but probably did not document "A" - then distros patched it for the same reason "A", and documented the process and rationale - why on earth would we not want to preserve and share those evaluations before others re-do it on their own > So it's better to stick to the topic here. i agree - just saying - i think we could make that work - we actually tried once
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, 17 Jul 2023 04:11:44 +0200 Denis wrote: > Anyway there are still some differences that doesn't enable to use the > FSD like that yet. im not aware of any; but that would be a good discussion to have - i see them as very well-aligned with significant overlap - maybe only some minor adjustments would be needed to make them meet squarely
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, 17 Jul 2023 04:16:40 +0200 Denis wrote: > On Wed, 12 Jul 2023 22:02:53 -0400 Richard Stallman wrote: > > > I'm not sure, we probably need to promote this list to FSDG > > > distributions contributors in general to make sure that people are > > > here. > > > > I'd like to have the people directly involved on this list, plus > > a few experts like you. NOT to get a lot of people -- it would > > mean more unhelptul arguments. > I had in mind FSDG distributions maintainers. In Parabola and Guix that > would mean potentially everybody that can push packages. > > They often have specific responsibilities like to read/suscribe to > certain mailing lists for instance. > > So telling them that this list do exist and what is it for, and that we > would need at least 1 person per distribution (but not necessarily > everybody) to keep an eye on the list would be useful I think. yes - this has been discussed often over the years - one of the amendments drafted addresses this concern directly - not many are willing to participate now; but hopefully that can change somehow the amendment would not require anyone to participate; but would suggest it strongly, by giving distro maintainers a greater stake in the decision making process
Re: [GNU-linux-libre] is the license of 'bass' acceptable?
On Mon, 17 Jul 2023 02:28:36 +0200 Denis wrote: > On Tue, 4 Jul 2023 15:24:21 -0400 bill-auger wrote: > > gnutoo and i believe that per its explicit wording, it is non-free > At the beginning I thought it was but then when I sent that mail I > didn't read all the license so you think it is acceptable then? - i would be satisfied with any conclusion to this - "its fine - forget it" would surely be the easiest one
Re: [GNU-linux-libre] Third-Party Package Managers
On Mon, 31 Jul 2023 01:03:01 -0400 bill-auger wrote: > the actual code-base may not mention a single word about licensing, and even > if > licensed properly, the code-base could actually be under a different license > or > multiple licenses i guess what i am really getting at, is that even if it is acceptable to patch the clients per this lax approach, or if GNU hosts repos filtered on the basis of the license metadata alone, there should still be a prominent warning about using them, such as: "WARNING: We make no attempt to verify the actual licenses of the software in this repo. We simply trust the random anonymous person who initially published them to the pip repos, as did the pip repo admins." this weakness is worth considering, because distros and the FSD _do_ make the effort to verify the licenses of all software (or we assume that they do) - although the FSD now adds entries automatically from debian's database, we can assume that someone in debian has verified the licenses at some point - im quite sure that we can not assume so for most of these unrestricted "world-writable" repos - i do not suppose that the FSD would want to add entries automatically from github, based on github's license detector, or based on anything less reliable; only to to add a warning to every page: "... but we dont _actually_ check this stuff :p" - i doubt that we should be so lax either; but we surely should discuss it before doing it the "filter the search feature" proposal was added with this doubt in mind; and the assumption that a prominent warning would be supplied (eg: in the client, upon first use) - the "maintain libre repos as a GNU project" proposal was added with the assumption that all packages would be curated (and scrutinized) manually, as the FSD does, not imported automatically based on the metadata supplied by 'RandomJavascriptFan42' and her cat "oops, did you press the 'MIT' button? - bad kitty! - oh well, it worked" so it is important to ask: is that lax approach acceptable without a prominent warning? - indeed, is it acceptable at all, knowing how likely the information is to be wrong? maybe this (finally) illustrates why i have been hesitant to do anything about these, other than delete them? - i would really like to see these uncertainties clarified before jumping down this rabbit hole - but again, we have no authority here to answer those questions today - there is every indication that this will become yet another undecided FSDG grey-area, left dangling forever; because not a single problem discussed in the past five years has been resolved i am done discussing these things for the sake of nothing - IIRC, the backlog of undecided issues is already six deep - no more please - most of those are simply due to the inability or unwillingness to decide which programs are libre and which are not - so shall we let 'RandomJavascriptFan42' and her cat be our authority on these _hundreds_ _of_ _thousands_ more programs - is that really a step forward? - well maybe - right or wrong, at least they would be decisive!!! - five years with zero resolutions is itself the worst of all the FSDG's woes - i want to resolve all of those dangling issues before i would be confident that this new endeavor has a chance of succeeding most of those outstanding issues, though controversial, are themselves not terribly important to most distros - they have all been discussed at length and would be very easy to decide, either by a vote or by a simple (long overdue) "yes" or "no" from the FSF - most distros would not be affected by the resolution either way - most of those outstanding issues could be decided to my satisfaction by a coin flip; but the ability to decide _any_ issues at all is critical for the legitimacy of the FSDG and this work-group - lets flip some coins then? - that methodology is not much less reliable than the TPPM metadata - _anything_ conclusive would be a huge boon at this point and please dont ask "what are those unresolved issues?" - i am only interested in answering the fundamental existential question: "is it possible to decide any FSDG issues at all, ever?" - if the answer is "yes", then id be happy to blow the dust off of those old records and replay them - but im quite sure that the answer is "no we can not - the old victrola, she is broken" - we just tried to play the new hit single: "Is Bass Libre?"; and it produced nothing but noise did i imagine that? - nah, i think you all heard it too and the saddest part ... we have all the tools needed to fix that old victrola and get this party rockin' again; but the landlord will not let us - this is the lamest techno-party i have ever attended; and i am late for the door, folks :)
