Re: [GNU-linux-libre] SGML nonfree?
On Fri, 19 Apr 2024 10:23:38 +0200 Simon wrote: > Interesting, the debian/copyright file of sgml-data includes that too: > > Would it make sense to open a Debian bug report about it, cc'ing > debian-legal for discussion/interpretation? It seems like an unclear > license at best. from what i know abut debian packaging, the debian/copyright file is not automated - it must be written by the package maintainer; which means that the package maintainer has presumably read the license and considers it to be in accordance with debian's policy - it may not be; but i would not expect that bug report to be considered to be a bug, unless you can demonstrate precisely how it conflicts with debian's policy (ie: demonstrate that the packager made an error) - even if the packager could point to a prior decision made by the legal team WRT that license, it could not influence this work-group - that license is not complicated; so it is a matter of opinion in any case, asking for debian's opinion would not be informative in the context of this work-group; because debian does not participate this work-group - debian has its own set of guidelines which may differ where this license is concerned - OTOH, the pureos maintainers are also members of debian - perhaps their opinion would be constructive in this context - they would be obligated to treat or delete this software, if the FSF deems that license unacceptable; but debian has no relation or obligation to the FSDG
Re: [GNU-linux-libre] SGML nonfree?
i think the FSF would consider that non-free - the wording which would make it non-free is very similar to the old unicode license, which according to the parabola bug tracker, the FSF decided was non-free because of that wording https://labs.parabola.nu/issues/674 parabola has been patching ruby for 9 years, only to replace that one file with the old unicode license WRT this mailing list, i found only these two mentions of it; but neither had a follow-up with a definitive decision https://lists.nongnu.org/archive/html/gnu-linux-libre/2013-05/msg0.html https://lists.nongnu.org/archive/html/gnu-linux-libre/2014-10/msg0.html
Re: [GNU-linux-libre] [dyne:bolic] Beta release: dynebolic 4.0.0
On Tue, 16 Apr 2024 14:17:01 +0200 Set wrote:
> That's odd. My experience with KDE is that it is comparable to xfce
> when the setup is minimal. Maybe some Akonadi stuff slipped in. I'll
> make sure we look into that.
it is probably because you have a relatively powerful graphics card and more
than average amount of RAM - a very common developer myopia: designing for
the dev box specs (which are usually much higher than the average machine),
rather than targeting the lowest common denominator - historically,
dynebolic has been known to be very lean, and able to run on the slowest
computers - an audio workstation should be lean, to avoid high-performance
eye-candy from impeding the audio processing - even XFCE is a relatively
heavy DE compared to others available - the original dynebolic used fluxbox,
for example - have a gander at this chart for a comparison:
https://l3net.files.wordpress.com/2014/02/cmp-all4.png
that chart is about 10 years old now - probably the ones heavier than LXDE
have grown significantly, but LXDE and those lighter than LXDE have not grown -
'razorqt' is what is known today as 'LXQT' (also not as light as people may
think)
On Tue, 16 Apr 2024 14:17:01 +0200 Set wrote:
> > trisquel and parabola direct to the mozzarella website instead - it
>
> Good catch, thank you! Any hints to documentation describing how to
> achieve this would be very helpful.
i attached a patch file - those are the changes we make to iceweasel,
in order to support mozarella and to hide mozilla's automated
recommendations of add-ons
>From 275785d94093d5c2dd46739484a2744642df357f Mon Sep 17 00:00:00 2001
From: grizzlyuser
Date: Tue, 17 Jan 2023 21:59:51 +0100
Subject: [PATCH 3/5] FSDG: Remove some references to AMO
* addons.mozilla.org (AMO) is a third-party repository, not compatible
with the FSDG, because it is not committed to only including free
software, see [1]. The work to remove the references to it from
Iceweasel right now is far from being complete.
* Remove URLs to services.addons.mozilla.org as one of these URLs is
used to fetch recommendations from AMO after the click on Extensions
button from the toolbar.
* Disable abuse reporting functionality as it uses the API on the same
hostname. Sanity check during build preparation should verify this
hostname is not available in the sources, and make it clear the patch
needs reworking when that check fails.
* Remove AMO URL to fetch langpacks. These are for Firefox, and Parabola
has Iceweasel langpacks anyway.
* Remove some AMO URLs from mobile.js. There's no Android version of
Iceweasel AFAIK, but these are some steps towards total removal of
references to AMO.
* Remove some AMO related preferences from vendor.js.in and patch them
directly in the sources, to avoid the rotting and to get notified
quickly when Mozilla introduces any changes to them in the future.
[1] https://labs.parabola.nu/issues/2409#note-4
---
browser/app/profile/firefox.js| 12 ++--
mobile/android/app/geckoview-prefs.js | 8
modules/libpref/init/all.js | 8
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/browser/app/profile/firefox.js b/browser/app/profile/firefox.js
index 801816dc41..9c2562ff23 100644
--- a/browser/app/profile/firefox.js
+++ b/browser/app/profile/firefox.js
@@ -33,12 +33,12 @@ pref("extensions.postDownloadThirdPartyPrompt", true);
// Preferences for AMO integration
pref("extensions.getAddons.cache.enabled", true);
-pref("extensions.getAddons.get.url", "https://services.addons.mozilla.org/api/v4/addons/search/?guid=%IDS%=%LOCALE%;);
-pref("extensions.getAddons.search.browseURL", "https://addons.mozilla.org/%LOCALE%/firefox/search?q=%TERMS%=%OS%=%VERSION%;);
-pref("extensions.getAddons.link.url", "https://addons.mozilla.org/%LOCALE%/firefox/;);
-pref("extensions.getAddons.langpacks.url", "https://services.addons.mozilla.org/api/v4/addons/language-tools/?app=firefox=language=%VERSION%;);
-pref("extensions.getAddons.discovery.api_url", "https://services.addons.mozilla.org/api/v4/discovery/?lang=%LOCALE%=%DISTRIBUTION%;);
-pref("extensions.getAddons.browserMappings.url", "https://services.addons.mozilla.org/api/v5/addons/browser-mappings/?browser=%BROWSER%;);
+pref("extensions.getAddons.get.url", "");
+pref("extensions.getAddons.search.browseURL", "https://gnuzilla.gnu.org/mozzarella/search.php?q=%TERMS%;);
+pref("extensions.getAddons.link.url", "https://gnuzilla.gnu.org/mozzarella/;);
+pref("extensions.getAddons.langpacks.url", "");
+pref("extensions.getAddons.discovery.api_url", "");
+pref("extensions.getAddons.browserMappings.url", "");
// The URL for the privacy policy related to recommended extensions.
pref("extensions.recommendations.privacyPolicyUrl", "https://www.mozilla.org/privacy/firefox/?utm_source=firefox-browser_medium=firefox-browser_content=privacy-policy-link#addons;);
diff --git a/mobile/android/app/geckoview-prefs.js
Re: [GNU-linux-libre] [dyne:bolic] Beta release: dynebolic 4.0.0
On Fri, 5 Apr 2024 01:53:59 +0200 Denis wrote: > the GPG key that signed the release? On Fri, 22 Mar 2024 05:28:38 +0100 Jaromil wrote: > Hi Bill, it is my key, also included in devuan-keyring and should be on > pgp.mit.edu. I upload it here too https://jaromil.dyne.org/jaromil.pub > > thanks for checking! ciao
Re: [GNU-linux-libre] [dyne:bolic] Beta release: dynebolic 4.0.0
awesome, it is great to see a new dynebolic i gave the new LiveISO a try with QEMU (2 cores 2GB RAM) - some observations: * there was no audio - alsamixer would not start * KDE is much too heavy for the dynebolic use-case - even if it worked well in this context, i would strongly recommend against it for A/V production even on the most powerful computer - but ... it did not work well - after launching a few applications, then stopping them, with no applications running, both CPUs stayed at 50% with about 900 MB RAM usage - after starting konqueror, both CPUs went to 100% and stayed that way for the remainder of the session - after viewing a few websites, konqueror became unusably sluggish, then KDE crashed and restarted; but the CPU did not settle down, and konqueror stayed unbearably slow i also noticed some FSDG issues - i am CC'ing this to the gnu-linux-libre mailing list - we should follow-up on these on that list * thunderbird directs users to the mozilla "app store" - all FSDG distros disable that feature or change the URL - it is relatively simple to do - trisquel and parabola direct to the mozzarella website instead - it responds to the same URL search format https://gnuzilla.gnu.org/mozzarella/ * also the dynebolic website invites users to use non-free websites such as discordapp - i believe that also is not permitted, though that may be a grey area
Re: [GNU-linux-libre] Differences between Trisquel's kernel and linux-libre for i915 (video)
possibly related - i remember this from last yaer: > 2023-03-12 - i915 deblobbing bug fix > > Initializing the i915 driver when using certain Intel i915 GPU variants > appears > to freeze the system: there is an infinite loop of disarmed (unsatisfiable) > blob loading attempts in 6.1.-gnu (up to 6.1.18-gnu) and 6.2.-gnu (up to > 6.2.5-gnu). See this thread for a workaround (that bypasses the loop but > disables GPU acceleration), to confirm whether your GPU is affected, and for a > patch, that fixes the problem without disabling GPU acceleration. The fix is > slated for inclusion in upcoming releases, presumably 6.1.19-gnu, 6.2.6-gnu, > and 6.3-rc*-gnu. where "this thread" is: https://www.fsfla.org/pipermail/linux-libre/2023-March/thread.html#3507 i could supply a binary of linux-libre < 6.1 for parabola, if that would help isolate the problem - maybe there is a also still an older deb package for trisquel to try
Re: [GNU-linux-libre] Differences between Trisquel's kernel and linux-libre for i915 (video)
there is another relevant tid-bit that Edgar did not mention here - parabola's linux-libre behaves the same; so that reasonably eliminates any peculiarities of the distro - it is probably a kernel configuration issue Edgar - you did not answer my question on the parabola forum - namely: > have you tried other kernels? - try linux-libre-vanilla and see if that works linux-libre-vanilla is configured differently than linux-libre and the others - also, what about the parabola LiveISO, does that boot? - if there is any difference, that could point to a clue (different versions, different configs)
Re: [GNU-linux-libre] Should the use of C#, Mono, and .NET still be discouraged?
On Mon, 8 Jan 2024 17:10:12 -0500 bill-auger wrote: > > > * ".NET spying"[4] i could add too, that vague "spying" claims are even more challenging to identify - that usually requires running the program for long periods of time while logging all networking, perhaps fudging the system clock and other tricks, to notice any unexpected networking - one can never verify that the networking is "spying" because almost everything is encrypted these days - all that can be deduced, is that some communicating is taking place with some server, which is a relatively normal thing for some applications to do - whether or not the communication contains anything interesting to a "spy", it could be a normal "keep-alive" signal which itself, may not be suspicious
Re: [GNU-linux-libre] Should the use of C#, Mono, and .NET still be discouraged?
On Tue, 16 Jan 2024 22:29:09 -0500 Richard wrote: > There is a crucial difference between those two cases: Chromium gives > a maintained practical free alternative (Firefox), and Mono does not. > If you want to run C# programs, as far as I know Mono is the ONLY free > base to start from. for FSDG issues, i am usually accounting for priorities, in terms of a desirability/workload ratio - so another big difference is that web browsers have a high desirability; but dotnet has very low, nearly non-existent desirability - the fact that dotnet has a replacement is not the major factor - dotnet and mono are both easy to discard; simply because they have no important clients - there is barely no intersection of it's user-base and ours - the main value of dotnet and mono in distros is as yet another programming toolkit in the crowd of many, but one which has never been widely adopted by distros or their users - it has been an option for nearly ~20 years; and many applications exist - yet distros have not adopted those applications - so it is not likely to ever be an important platform to support on free systems On Tue, 16 Jan 2024 22:29:09 -0500 Richard wrote: > > a few issues have accumulated in the parabola > > bug tracker over the years - we know of one conflict with the FSDG > > - the telemetry feature is enabled by default > > You did not say what program or package this is about, and I can't tell. > I am guessing it is Mono. same as this thread subject, the dotnet runtime and SDK for C# language programs, and the mono equivalents that dotnet is displacing - this spilled over from the FSD mailing list earlier last month - i tried to give references for the past discussions and those bug reports - the specific bug report is this one https://labs.parabola.nu/issues/2590 it was easily fixed; but the OP is asking if the situation is any better or worse now; so i gave the one example i know which has been demonstrated - at least that one issue needs treatment before FSDG distros can recommend it - o/c that is interpreting the "no malware" requirement broadly, which IMHO is too vague - telemetry is not literally "malware" and is not necessarily "spyware" - it is usually collected anonymously, for instance - we interpret the "no malware" FSDG section as actually "no anti-features", an even less well-defined concept - i think we should define it formally given the current wording, the "no malware" criteria reduces to a suggestion; because "whatever" it covers is so subjective - even viruses are not mentioned - does that mean they are permitted? - with such vague requirement, that makes it very difficult for us even to discuss these "malware/spyware" features, "anti-features", or whatever to call them, because those are not well-defined terms - everyone is free to interpret nearly any networking feature as being either "mal" or desirable, and they do - geo-location is a prime example - like anything else which may fall under the "no malware" criteria, whether the FSDG forbids or prohibits it, defers to the belief of the maintainers of each distro individually whether or not it qualifies as "malware" in their opinions - i would like to propose a significant re-wording of the "no malware" section, in order to give it some degree of objectivity On Tue, 16 Jan 2024 22:29:09 -0500 Richard wrote: > > the first link WRT the "EULA" is a library that is/was required by > > mono - im not sure if anything like it is in the new incarnation; > > but that is not unlikely > > That is breathlessly terse, so the only part I understand is that Mono > depends on something nonfree. The community would have to fix this. yes this entire message was terse; because these point have been discussed already - i mentioned that non-free library; because it was the only non-free part of the mono ecosystem that we found, and coincidentally it was the only part back then which came from microsoft - so now that all parts come from microsoft, i was speculating that more of the replacement parts may have odious terms of use On Tue, 16 Jan 2024 22:29:09 -0500 Richard wrote: > "Not build from source" is crucially ambiguous. If it means "We can't > build it from source", that would imply it is not free software. I > get the impression you mean something other than that, but what > exactly does it mean? this is a commonly vague bug report that we get regularly - we dont know what it means until someone investigates the claim - generally: 1. inspect the sources for pre-compiled binaries and remove them 2. try to build it with networking disabled 3. if it fails, investigate why 4. perhaps locate the missing sources to replace any essential binaries that were deleted in step 1 5. compile those and repeat from step 2, until it builds, or until you decide to retreat from the rabbit hole and resign from that specific adventure it is very common with these non-native byte-code languages for applications to ship
Re: [GNU-linux-libre] Should the use of C#, Mono, and .NET still be discouraged?
On Mon, 8 Jan 2024 17:10:12 -0500 bill-auger wrote: > IMHO, the not "built from > source" is the most worrisome - that often indicates that something non-free > was required for the build i realized that may be confusing for those unfamiliar with parabola - parabola's dotnet is taken directly from arch - it was possible to disable the telemetry feature without re-building, by setting an environment variable; so that is still the case arch prefers to built everything from source if possible - there is usually a fundamental reason why some package is not built from source, that could be because it is not possible
Re: [GNU-linux-libre] Should the use of C#, Mono, and .NET still be discouraged?
i could be more precise - this was discussed on this list previously though - a few issues have accumulated in the parabola bug tracker over the years - we know of one conflict with the FSDG - the telemetry feature is enabled by default, which we consider to be in conflict with the "mo malware/spyware" guideline, so that is disabled in parabola - the first link WRT the "EULA" is a library that is/was required by mono - im not sure if anything like it is in the new incarnation; but that is not unlikely - IMHO, the not "built from source" is the most worrisome - that often indicates that something non-free was required for the build On Sun, 29 Jan 2023 16:24:14 -0600 Jacob wrote: > On 1/28/23 01:01, bill-auger wrote: > > * "Microsoft redistributable assembly EULA"[1] > > * "Arch version is not built from source"[2] > > * "dotnet-sdk, dotnet-runtime telemetry"[3] > > * ".NET spying"[4] [1]: https://labs.parabola.nu/issues/1334 [2]: https://labs.parabola.nu/issues/1794 [3]: https://labs.parabola.nu/issues/2590 [4]: https://labs.parabola.nu/issues/2894
Re: [GNU-linux-libre] Should the use of C#, Mono, and .NET still be discouraged?
On Sun, 07 Jan 2024 22:49:26 -0500 Richard wrote: > The reason we discouraged use of Mono and .NET was concern about danger > that Microsoft would attack the free replacements with patents. what happened recently, could be somewhat worse - the microsoft implementation has been ported to our system and has displaced the free replacement - the free replacement 'mono' was reviewed and included in the FSD; but most likely, mono is going to cease being maintained and fall out of use, leaving only the microsoft implementation, which has not yet been shown to be libre and have no odious EULA's attached as some of microsoft other libraries do/did On Sun, 07 Jan 2024 22:49:26 -0500 Richard wrote: > We don't say that free distros should reject them. unless it is or requires something non-free - as of now, i dont believe that anyone knows if it does or does not - i would not presume that it is FSDG-fit, at least until it has an entry in the FSD furthermore, in the context of the FSDG, if some code-base is fundamentally unable to build from source with binaries and blobs removed, it highlights the difference between the FSD and FSDG - the source code may qualify as libre and so may be listed in the FSD, though it will not compile without supplement of non-free binaries, libraries, blobs; so FSDG distros could not distribute binary packages i would put this in the same category with chromium - it is much easier to discard than to audit - very few people would mind the former; and no one wants to do the latter
Re: [GNU-linux-libre] Should the use of C#, Mono, and .NET still be discouraged?
for context, this thread began last year https://lists.nongnu.org/archive/html/gnu-linux-libre/2023-01/msg0.html i dont think you will find many more opinions (neither for nor against) about dotnet in the free software community - there is no important software in distros for instance, which use it - it is used almost exclusively by developers who either prefer to work on windows or for applications which target windows primarily - that is not because it has any unique value as a platform or language, but because it was imposed upon them as the lingua-franca of windows development to replace their visual-basic platform - it is cross-platform because its purpose was to compete with java; but i doubt that it was used very much with that intention - java was very popular at that time; but is not nearly as popular today - java is rarely discussed on this mailing list either, for the same reason - there are very few examples of java software which distros distribute also FWIW, the original question "should it be discouraged?" did not really belong on this mailing list - that question is more appropriate for the FSD - in the context of this mailing list, it is only important if distros want to distribute it, and if it has potential conflicts with the FSDG - i think the original discussion did not go very far because few distros do distribute dotnet; and those which do, probably would not miss it if it needed to be deleted
Re: [GNU-linux-libre] Third-Party Package Managers
granted that this would be the final determination, in each case, the client would require patching, with one of two options: A) patch the client to filter results per the metadata, and further, to filter additional packages based on the blacklist B) patch the client to replace the upstream repo as a client source, with new libre-only repos, hosted for all distros to share option B should be relatively easy with one simple zero-maintenance patch, which distros could apply on their own, once - ie: that is probably only a matter of configuration rather than "code" - the blacklist could be maintained as part of the central repo filter option A would require some code, which would surely be different for each example; but has the advantage of not requiring new libre-only repos to be maintained - option A would be as effective with the existing upstream repos as they are in either case, a new team would need to be created to maintain the clients, the blacklists, or both; or the FSDG work-group would need to assume that role after all is said and done, for either option to be successful will require the cooperation of all distros which want to continue distributing the clients; but currently, we have no way to accomplish that final and essential step - we can only assume that they will all be interested voluntarily - i really think we should contact them all now to explain the plan, and ask for volunteers
Re: [GNU-linux-libre] [RFC] FSDG amendment - addition to section "Commitment to Correct Mistakes"
for those who are not aware of this, that list already exists - the former FSF licensing officer made it a criteria for endorsement in 2018 this amendment is not a new proposal, but only a formality, to make it clear that the recommendations apply perpetually to all distros after the initial endorsement process
[GNU-linux-libre] [RFC] FSDG amendment - addition to section "Please Teach Users about Free Software"
== Please Teach Users about Free Software == Endorsed distros should present the core tenants of software freedom, only in accordance with the Free Software Definition and the current FSDG work-group recommendations, without reinterpretation, embellishment, or omission. Please avoid suggesting or implying, on public communication channels other than the FSDG work-group mailing list, that the FSF guidelines, the FSDG work-group recommendations, or the practices of other FSF-endorsed distros, which do not conflict with those guidelines and recommendations, are somehow in discordance with the principles of software freedom. We very much hope that such a situation would never occur. If all of the endorsed distros were not in common agreement on the definition of this fundamental shared concept, it would undermine the validity of the FSDG. If ever there are objections, or some dissonance across distros, regarding what software freedom and the FSDG do and do not entail, or whether one of the endorsed distros is failing to meet the guidelines, such matters should be addressed by the FSDG work-group on the mailing list. The FSF will take notice of any grievances or adversity, offering clarification when requested, and guidance for any emergent grey-areas.
[GNU-linux-libre] [RFC] FSDG amendment - new section "Being a Good Neighbor"
== Being a Good Neighbor == The FSDG work-group is established for the purpose of discussion about freedom, privacy, and other FSDG-related concerns regarding the software distributed by FSDG-endorsed distros, collaborative auditing of certain software which may exhibit those concerns, and the interpretation and implications of the FSDG itself. It is strongly recommended that at least one person, in close communication with the core maintainers of each distro, should read, and ideally participate in, the discussions on the FSDG work-group mailing list. It is a relatively low-volume mailing list; and we assume that each distro will remain genuinely interested in the discussions, especially as the endorsement of the distro will be perpetually contingent upon the distro's willingness to address emerging problems. If some software is found to have FSDG-related problems, or if important suspicions are expressed to, or by the distro maintainers, the FSDG work-group should be consulted, for the benefit of all endorsed distros. Everyone in the work-group is a volunteer; and no one is expected to open bug reports against every distro, nor to prepare general bulletins, whenever a shared concern arises. The FSDG work-group mailing list is the central clearinghouse for common issues. Most of the problems and suspicions will usually be of concern to the wider community, applicable to all endorsed distros, and can be resolved most quickly and effectively for all, through collaboration.
[GNU-linux-libre] [RFC] FSDG amendment - addition to section "Commitment to Correct Mistakes"
== Commitment to Correct Mistakes == The FSDG work-group, with the oversight of the FSF, shall maintain a list of software with known FSDG issues, and their commonly accepted remedies. Distros shall, at all times, heed the current recommendations on that list. In the case of contention, the issue may be reintroduced into the work-group discussions, for the purpose of re-assessment, and possibly a revision of the current recommendation. Distros should refrain from introducing software into their repositories, for which there are known contentions regarding it's FSDG-fitness, until the issue is raised and thoroughly discussed publicly among the work-group. Once the facts and arguments are presented as clearly as possible, and people have had adequate time in which to express their opinions, the FSF agent in charge of FSDG over-sight may be consulted for an official recommendation. Pending an official recommendation, the standing consensus of the work-group should be taken as the general recommendation, with respect to that particular software; and each endorsed distro should promptly apply that recommendation to their software. Once an official recommendation is determined, it shall be added to the list of common remedies for future reference.
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, 01 Aug 2023 22:39:34 -0400 Richard wrote: > > 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 > > I don't know what this is about. Would you please show it? i will post them individually, as they address three distinct FSDG sections; though they are all complementary the statement above is referring specifically to the "Being a Good Neighbor" section
Re: [GNU-linux-libre] Third-Party Package Managers
sry then - i should have kept that more focused - all of them will raise the same fundamental questions, whether investigated one by one or in tandem they all have a client which fetches metadata from their repo, and offers downloads to the user - some repos may expose license declarations to the client, and some may not - the ones that do not, will not allow the simpler option of patching the client - the ones that do, will present dubious licensing information that is because those repos allow anyone to publish to them anonymously; so the readily available licensing information (if any) is supplied by the uploader, and is not verified by anyone else - i am only asking to consider whether that information is reliable enough, without scrutinizing the code-bases, as the FSD does the ones i looked at, declare licenses for only about 50% of the packages - that is because very few require the uploader to specify any license - some suggest it in the documentation, and some do not even suggest it - some may not even allow it this is definitely worth considering now as a general concern - i think that the success of any one of the examples will hinge primarily on that factor alone can we rely on the terse 'GPL3', 'MIT', 'BSD3' labels declared by anonymous uploaders, without looking at the code-base? - it is a simple question, and will be relevant to nearly all of these package managers - let is answer it now
Re: [GNU-linux-libre] third-party package managers
On Tue, 01 Aug 2023 22:40:39 -0400 Richard wrote: > > this is a most interesting new statement - are you suggesting that > > GNU should have a formal project dedicated to this? > > THose sorts of questions seem like a distraction to me. > I don't want to spend any time on them. > > I've just said what I plan to _do_. i would not have been distracted if instead you wrote: "_I_ will have to study each one of these" - this is what what you wrote: > On Sun, 30 Jul 2023 21:42:56 -0400 Richard wrote: > > The GNU Project will have to study each one of these i was not suggesting anything new - until recently, i assumed that the only people interested were the participants on this mailing list - considering that this mailing list is not a GNU project, it appeared that you were suggesting something yet unknown to readers of this mailing list
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
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 :)
Re: [GNU-linux-libre] Third-Party Package Managers
On Mon, 31 Jul 2023 00:52:38 -0400 bill-auger wrote: > imagine pulling and packaging every > repo from github automatically, based only on github's license detector - > would > you really consider that as properly audited? presuming that the answer is "no - that would be crazy", i will add that github's license detector is far more reliable information than the metadata these package have access to github's license detector is actually based on _a_ file it found in the code-base - im quite certain that the licensing declaration for most TPPMs is simply a drop-down GUI selection, or handwritten 'MIT' in a metadata file - 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
Re: [GNU-linux-libre] Third-Party Package Managers
On Thu, 27 Jul 2023 06:05:40 +0200 Denis wrote: > If the repository has strict licensing criteria, then we can count it > as audited, but only for licensing i have trouble accepting that - "audited for licensing" means that someone has checked that the licensing was done properly, all files are accounted for, no license conflicts, and so on - these repos are nearly 100% user-curated - the criteria is only that the uploader declares a license (eg: License: MIT) - that is the most that can be expected; and no one checks to see if even that 'MIT' ID accurately represents the code-base On Thu, 27 Jul 2023 06:05:40 +0200 Denis wrote: > But then precisely because distributions repositories are audited for > more than just licensing, it might not be feasible to package 150 000 > ruby packages. that is because distributions repositories are audited _at_ _all_ - most of those third-party repos are not audited in any way, just the same as github - the license presentation is highly suspicious for all hosted projects - it depends entirely on the anonymous uploader's knowledge and honesty, and often on their anonymous copyright which can never be verified i think this is being much too generous - imagine pulling and packaging every repo from github automatically, based only on github's license detector - would you really consider that as properly audited?
Re: [GNU-linux-libre] third-party package managers
On Tue, 18 Jul 2023 16:38:13 +0200 Denis wrote: > On Wed, 12 Jul 2023 22:02:30 -0400 Richard Stallman wrote: > > Would a few of you like to form a committee to choose one? I think > > that would be useful. You could have discussions on another list > > specifically for this. i mentioned this before; but i can not imagine what existing mailing list that could be, other than this one; and its scope is rather narrow and short-lived to deserve a new dedicated mailing list On Sun, 30 Jul 2023 21:42:56 -0400 Richard wrote: > > all of them are under review - you could definitely help if you like - > this > > wiki is tracking the progress: > > The GNU Project will have to study each one of these, one by one -- > and each one will take time. this is a most interesting new statement - are you suggesting that GNU should have a formal project dedicated to this? - bearing in mind that no one who is currently interested in addressing these is a member of any GNU project, that statement seems like a stretch of the imagination, albeit an interesting one the reason that is interesting, is because it is not obvious why the GNU project would have any interest in such a project, other than to support the FSDG - currently, these third-party repos are squarely in the domain of the FSDG work-group; because only the FSDG has any criteria about these - the FSD criteria only relates to the source code of the client applications, all of which are libre; and i dont believe that it was ever within the scope of the GNU project standards or any FSF campaign the FSDG work-group is not a GNU project; so these TPPMs are not otherwise relevant to any GNU or FSF project - the FSDG is a formal project of the FSF licensing office; but the work-group is not - it has always been community-based - though donald effectively made it a volunteer group of the FSDG project, it has no formal standing and no real efficacy beyond evaluating prospective distros if the FSDG work-group were formal project of the FSF licensing office or GNU; that would go a long way toward the sort of reform i have been seeking - if it is not, then any work done has little chance of being effective if a new GNU project were created to address these, that would be a fine way to handle this _one_ FSDG concern; but it would still leave all other FSDG concerns hanging un-addressable
Re: [GNU-linux-libre] Can we slow down?
On Sun, 23 Jul 2023 16:27:42 +0200 Denis wrote: > On Tue, 18 Jul 2023 22:51:32 -0400 bill-auger wrote: > > and so finally, that i am reluctant to do any of that work, until i > > can see a complete clear path to the goal; because i have no interest > > in TPPMs otherwise > People that care about software using third party package managers or > about using software from these package managers can do the work > instead. > > So here enforcing the FSDG > about nonfree firmware makes more sense as the problem isn't going to > fix itself. > > But we're not in this situation with the third party package managers, > so we also have other options as well. there is an important difference - there is only one FSDG distro with any desire to distribute non-free firmware; and they keep it in a separate repo, which is considered to be not part of the libre distro - that separation was done before the FSF endorsed the distro - there is no imperative to liberate firmwares; because distros have yet always complied voluntarily on that criteria the TPPMs situation is very different - distros which are not interested in them, already do not distribute them; and so they have no imperative to liberate any - OTOH, distros which are interested in TPPMs, are currently distributing them, and were doing so when those distros were endorsed - although it should be imperative for those distros to liberate or to exclude them, unfortunately, those distros have no incentive to do either, because the FSDG is not enforced after the initial endorsement - the result is that no one is motivated to liberate them, or to use liberation recipes devised by others if we want to invoke the "commitment to correct mistakes" criteria, the first step would be to convince distros that most TPPMs are unfit - so how do we do that, when when distros are free to refute any alleged "mistakes" - distros are even free to re-commit past mistakes and re-open the original freedom bug report which had once prompted an acknowledged correction, essentially admitting that the "mistake" is now intentional - that is the FSDG we have now - distros are required to follow the guidelines only until endorsed; and there is no authority to decide what constitutes "a mistake" later on, or to ensure that mistakes will ever become corrected this is essential - users of an FSDG distro should be reasonably certain that it actually follows the FSDG, and that the criteria are precise enough to be applicable - if the FSDG can not assure that with any confidence, it is not doing very much of value for anyone - the value of the FSDG is not for the FSF as a showcase, nor for distro maintainers as a trophy - its primary value is for users - just as users need FSDG distros to avoid the hassle and uncertainty of curating their own libre software collection perpetually, users need the FSDG to assure them which distros will actually do that job for them perpetually in this case, the most fruitful way to invoke the "commitment to correct mistakes" criteria, would be to demand that all distros remove all unfit TPPMs immediately, until each is made FSDG-fit - that will need to happen anyways, if they are fixed; but only then would distros have any incentive to do anything about them - users deserve to know whether or not their distro is following the FSDG - on that concern alone, i would not wait another moment to run this experiment - that is essential and it will need to happen eventually; but again, the critical issue to address is that nothing like that could be done, neither now nor later, when there is no one in authority to confirm that these TPPMs have ever been a "mistake", and that the grace period has expired or soon will to wait until each or all TPPMs have been liberated, before expecting distros to do anything at all about them, is only to postpone the inevitable moment of truth - the situation will be no different when the time comes to convince distros to adopt the proposed liberated TPPMs - we would still need to convince distros that most TPPMs are unfit; and that would still need to be done with some authority, in order to be compelling - i dont see any value in postponing that event until after help is no longer needed, when the same could be done now while help is needed i would rather put that horse squarely before the cart now, rather than later - it is unreasonably optimistic to be building any new carts for that horse to pull, when it is so uncertain whether or not the horse can stand on its own legs, let alone deliver carts successfully to any destination
Re: [GNU-linux-libre] Can we slow down?
On Tue, 18 Jul 2023 22:51:32 -0400 bill-auger wrote: > that may allow some > work to progress; but only existential crisis facing the FSDG and work-group - sry typo it only _postpones_ the existential crisis, which we are neglecting to address, for a few more years
Re: [GNU-linux-libre] Can we slow down?
On Tue, 18 Jul 2023 16:16:59 +0200 Denis wrote: > bad quality free software will tend to use it anyway. that is always an option - anyone can grab 'pip' or whatever from same repo maintainers where the hundreds of other bad software they want to use will be downloaded from - if 'pip' is not in the distro repos, it is only one more non-distro package to install, before installing the hundreds of others which is it's only purpose On Tue, 18 Jul 2023 16:16:59 +0200 Denis wrote: > I also don't see how they could be forbidden by the FSDG if they follow > the FSDG. i was not suggesting that any distro should exclude any which are FSDG-fit, only that i believe it is the most responsible option; and we know of only two examples anyways which are fit - i was suggesting that all FSDG distros should exclude the vast majority of them as they are; because they are not FSDG-fit, unless someone _first_ does the work to fit them somehow RMS wants to allow TPPMs to slide for a few more years - that may allow some work to progress; but only existential crisis facing the FSDG and work-group - maybe that would be a fine option, if there was any hope that the FSDG will be enforceable someday the only point of my last message is that it is not possible to convince distros that these TPPMs, in their current form, are against the guidelines, and therefore to remove them and/or help to liberate them - surely they would have reached that conclusion on their own by now - we must consider that question as essential; because today, distros are not obligated to follow the FSDG in any way i would not want to obligate anyone to help do the work; but it would be nearly impossible even to suggest it, if there is no obligation to follow the FSDG in the first place, nor any consequences of ignoring pleas to follow it in the last place then furthermore, if something can be done to liberate them, how to convince the distros which refused to remove them, to use the liberated versions instead, rather than continuing to distribute the unfit versions forever - because surely at that point, even if all TPPMs were allowed temporarily pending a solution, once a solution exists, it should then be mandatory to exclude the unfit versions - i am fairly certain that some distros would still refuse to comply; so we may as well start addressing that now and so finally, that i am reluctant to do any of that work, until i can see a complete clear path to the goal; because i have no interest in TPPMs otherwise - "the goal" is not to liberate TPPMs for who knows what reason - the goal is to convince FSDG distro to follow the guidelines; so that liberated TPPMs would be interesting to distros wanting to keep the TPPMs
Re: [GNU-linux-libre] Can we slow down?
On Mon, 17 Jul 2023 02:29:07 -0400 bill-auger wrote: > * third party package managers i will take this one issue to illustrate RMS has asked us to start a sprint on this issue - that is awesome!!! - but most likely, only myself and gnutoo will volunteer to do it that is worth noting, because my favored option for _all_ of them, is to exclude them from parabola, and accept packaging requests for desirable packages from those repos - why? - because that is the very reason why distros exist, isnt it? so i would be doing that work only for the benefit of other distros, despite that i believe it is not the best course of action - if i, like other distros, were acting only on the behalf of my distro, i too would have no incentive to do this work on behalf of other distros (ie: the ones who want this junk should be the ones to clean it up) still, i would do it, if i thought for a moment that any of those other distros would appreciate the effort, or have any incentive to even consider the results - but i have every reason to be pessimistic about that, as things stand - i can not in good conscience, do that work on the behalf of people who will most likely reject it, some of whom have promised in advance to ignore it - like anyone else, my time is valuable - i would rather spend that time doing something constructive that is why the issue of reform is primary - every moment i spend on this work-group today, feels to me as if i am squandering my time; so i must do so under loud protest, in order to justify my own negligence of my primary responsibilities
Re: [GNU-linux-libre] Can we slow down?
i agree - this is going nowhere fast - i made that proposal in hopes that it will someday be able to arrive somewhere - i do not expect the proposal to be acted upon in the short-term - just planting a seed - until that seed bares fruit, all other discussions, and any work done, are speculative On Mon, 17 Jul 2023 02:25:24 +0200 Denis wrote: > discussions that have still some issues left pending: > - The ScummVM thread has still some things pending (what text to put > out, what rationale to use). > - There new mails with the thread on third party package managers. > - There is a thread on emulators. > - And one on Docker and how to deal with Docker that I also need to > reply to. > - There is also one on Parabola packaging of ScummVM. i dont think we need to do or say anything about ScummVM - that knocks two items off that list - but even if that were important, it is exactly the same topic as "emulators" - if ScummVM is a special case, that would be because it has libre guest applications in the distro repos, while most other emulators do not - though even that distinction is still undecided docker, for the purpose of this work-gruop, is one example of a "third party package managers" so those two items collapse as one line of activity so we really have only three active lines of activity: * are the ScummVM games libre? * third party package managers * emulators and other hosts of foreign applications the ScummVM thread is the only one that got out of hand - the ScummVM and emulators threads were both unprovoked tangents off of the much more significant 'bass' discussion the "emulators and other hosts of foreign applications" topic is only loosely related to software freedom, and only on the second order; because they are all libre, and all have known libre use-cases - i would suggest putting that one on the shelf indefinitely besides those though, there are 4 or 5 important issues that have been left unaddressed for years - IMHO, adding more active lines of activity is digging the work-group deeper into technical debt, especially because there is no indication that anything we do will have any consequence beyond parabola and replicant so "yes", i think this work-group should slow down or halt, until someone in a position of authority does _something_, _anything_ at all to support us in our efforts
Re: [GNU-linux-libre] third-party package managers
just to note that i moved the tables of evaluations and proposals to the wiki, to make it easier reference and to maintain https://wiki.parabola.nu/TPPM_Liberation_Project
Re: [GNU-linux-libre] the straw that broke the camel's back
On Fri, 14 Jul 2023 22:11:58 -0400 Richard wrote: > When you see someoe overreact based on exaggeration, > please try to stay calm. To exaggerate and overreact in response > to an overreaction is not helpful, it was no exaggeration - you have not been around - this has been a recurring theme for years; and we tried to explain this to you about three years ago what Ricardo was really suggesting is that distros have no regard for this work-group, mainly because it spends too much time on petty issues and never accomplishes anything - several of the FSDG distros have expressed that opinion and i agree fully with that assessment - i have no valid counter argument for it - this work-group is not respectable today; and it is barely functional i would very much like to change that, by convincing distros that they have a stake in these discussions, and to entice as many as possible to participate, for the sake of making the work-group better serve the free software community as a whole, through collaboration, rather than each distro isolating themselves and their users from the community as a whole, and doing redundant work
Re: [GNU-linux-libre] the future of the FSDG
blind CC'ed to the FSF licensing department as [gnu.org #1959291]
[GNU-linux-libre] the future of the FSDG
we are still facing the existential crisis for the FSDG and this work-group, which has been looming for years, yet to be addressed - if the FSF can not maintain the FSDG, as it has demonstrated for the past five years, then we must consider some alternate reform, to protect its reputation and to unclog the bottleneck of progress these are only general suggestions; and i am not alone in proposing them - i have some formal amendments to the FSDG prepared, which i would be glad to propose publicly - i wrote them years ago, and have showed them to about a half-dozen interested people, all of whom agreed that something like them should be discussed and adopted 1) can the work-group conclude and act upon contentious issues by consensus? i suggest that all FSDG decisions be made democratically by consensus among the work-group, or a committee comprised of endorsed distro representatives, unless explicitly overruled by the FSF - the FSF has paid so little attention to the FSDG and for so long, that this is the only reasonable way to make progress 2) if the work-group does not have that authority is the FSF willing and able to make such conclusions and act upon them? the past five years would suggest "no"; so we clearly need to improve the workflow somehow, or abandon the FSDG program entirely - in the current state, it is completely meaningless; because distros have no incentive to follow it, and the workflow is completely broken 3) once a conclusion is reached (either by the FSF or the work-group), does the work-group have the authority to ask distros to remove or treat some software? as it is today, distros may (and do) simply ignore or refuse such requests and to be clear, i am not referring to optional recommendations - i am referring to plain objective determinations such as: "is the foo program acceptable, or is it not?" - those things which already are obligations of the FSDG, as it is already written, but require decisions about specific examples (due to a confusing license, for example) i suggest that the work-group also be granted that authority; especially because, even when the FSF was actively involved, the FSF never did make such requests to distros beyond the initial evaluation period - the FSDG (only vaguely) requires users to post freedom bugs against each distro of their own volition, and offers no remedy for noncompliance - so in order for this proposal to work, one additional privilege would be essential 4) if a distro fails to comply in a timely manor, or plainly refuses, then what? currently, nothing - thats what - if non-compliance is a legitimate option, then the FSDG is meaningless, and the work-group is a waste of time for such cases, i suggest that the work-group also be granted the authority to revoke the endorsement of distros with a demonstrated history of non-compliance, again by democratic consensus, and with the FSF reserving the option to overrule the work-group's decision - but most critically, for the sake of the FSDG and the community at large, that distros would no longer have the option to ignore the FSF's or the work-group's decisions without consequence along with that, it makes sense for the work-group to also have the authority to endorse distros in the first place (another severe bottleneck), on the same contingent basis - namely: _if_ the FSF decides to become involved in the process, the FSF has the final word on it - but for as long as the FSF is not involved in some issue, the authority of the work-group on that issue would be total
Re: [GNU-linux-libre] is the license of 'bass' acceptable?
On Fri, 14 Jul 2023 15:48:00 -0400 Ruben wrote: > Also I still maintain that beneath-a-steel-sky and such are under a > (badly written) free license. which brings us back to where we were last week - it seems that the license has been fully reviewed, and all opinions have been expressed on that note, ruben's opinion has sufficient merit that i would gladly change my opinion if that would help reach an actionable conclusion - the rationale being that despite the wording, the "no selling alone" requirement is trivial to satisfy, such that it does not significantly impede software freedom in practice - frankly, "in practice" is the extent of my concern; because "in practice" is what distros actually do it is also worth noting that in practice, no one _can_ sell these games alone - their combined value is substantially _less_ than the meager copying/distribution fee, which the license permits still, even if the jury is agreed unanimously, we have done nothing of consequence yet; because the judge is absent from the court
Re: [GNU-linux-libre] the straw that broke the camel's back
On Fri, 14 Jul 2023 14:49:30 -0400 Ruben wrote:
> Recommendations are precisely that, recommendations. Each project can
> still draw the line where they see fit. The FSDG also have requirements
> ("a free disto *must* not..."), but this is not the case at hand.
scummvm is not that case - i agree - but that was unprovoked tangent -
the original (actionable) discussion was derailed by people who do not regularly
participate on the list, or who regularly do the work of auditing and liberating
software - yet that tangent discussion proved to be damaging to the reputation
of the work-group, which only demonstrates the severe lack of rigor and
discipline caused by the FSF's absence
the original topic was "are the games libre?" - if they are not libre, then the
line is clearly drawn in the FSDG, as it is written - distros must not
distribute non-free software - i have zero concern for scummvm - it is libre,
and has libre use-cases, therefore it is acceptable per the FSDG
On Fri, 14 Jul 2023 14:49:30 -0400 Ruben wrote:
> As the work-group can't issue any rulings, there can't be such
> imperative. Distros can choose to follow the FSDG or not, and they can
> choose to discuss stuff here, but that is all.
i agree fully - if the work-group has no authority, and the FSF ignores
everything the work-group discusses, then sure, there is no imperative for
distros to do anything, including to follow the explicit guidelines - that is
exactly what we have now - but is that what we want?
if endorsed distros have the option _not_ to follow the FSDG, then what good is
the endorsement? - for distros, it is a meaningless trophy - for users, it is
misinformation at best
that does not sound like a badge that i would be proud to wear - im not
interested in vague recommendations and petty trophies - and i am definitely
not interested in doing work for people who will reject it, or have promised
out-of-hand to reject all such future work
i and others have been suggesting for years, both to the FSF and to RMS, to
give authority to the work-group - not because i prefer that, but because
it appears to be the only possible way to get _anything_ done
the FSF has paid such little attention to the FSDG in the past 5 years, that
they still have not accepted, rejected, nor so much as entertained the
suggestion - so i am suggesting it now publicly, for whatever good that may do
Re: [GNU-linux-libre] Third-Party Package Managers
On Thu, 13 Jul 2023 22:02:44 -0400 Richard wrote: > > that was why he mentioned it - he was adding the emacs repos to the very > short > > list of third-party repos, which are known to have a strong libre > licensing > > policy > > That makes sense. Sorry for the noise. np, that was constructive - i can refine that a bit more the reason why i did not mention the emacs repos is because those are in a special subclass: "in-app add-ons downloaders and binary auto-updaters" - as i understand, the emacs repos are accessed only from within the emacs program; but that is not the primary use of the emacs program - the emacs program would be fully useful without them - there are another few dozen repos in that class also (eg: mozilla ad-ons) - unless like emacs, the repo has strict licensing standards (most dont), we usually disable that feature from applications, or try to curate some of the packages in a distro-maintained repo we have been limiting the research to package manager clients, applications which only purpose is to interact with a third-party repo, on the basis that those all could be excluded if necessary, without losing any applications
[GNU-linux-libre] the straw that broke the camel's back
On Thu, 13 Jul 2023 11:02:19 +0200 Ricardo wrote: > For me the > conclusion is obvious: I’ll just ignore whatever actions this group > declares as decided when *this* is exemplary of the decision making > process. well, i rest my case - if FSDG distros will not to follow the recommendations and will not help to improve them, we may as well disband the work-group and delete the FSDG - it is useless unless distros respect it _as_ _written_, and actively help to change outdated or misguided parts ricardo has just confirmed my suspicion that we are wasting our time on this mailing list - i can tolerate a few wild decisions and bike-shedding - but what is not acceptable, is that there are no consequences for distros which ignore the work-group's decisions and even declare that intention publicly OTOH (my preference), we could strengthen the reputation and usefulness of work-group by limiting discussions to the important issues, and further by revoking endorsement of distros which refuse to participate in the discussions, but rather ignore the decisions of the people who did participate frankly, this has gone on much too long, while the only people who could possibly tame this chaos are the ones adding the most to the chaos - it is quite discouraging to see the very people we are working for, rejecting the efforts with such indignation - one would need to be insane to stay on this bandwagon if nothing changes, and _very_ soon, to give distros some imperative to respect the work-group, i must withdraw also, if only for the sake of my own sanity and dignity - i have plenty of other things to do that will be fruitful and people will respect
Re: [GNU-linux-libre] third-party package managers
> We would like to start with one of the easy targets ah, but you did not - you started with the most challenging example (rust/cargo) i suppose that is great; because that work is being done (AFAIK) by no one in this work-group - if they succeed, all the better for us - maybe we can ignore rust for a while and simply accept the GNU team's solution o/c what would be even better? if those people would then join us on this mailing list to tackle the other dozens of examples On Wed, 12 Jul 2023 22:02:30 -0400 Richard wrote: > Would a few of you like to form a committee to choose one? I think > that would be useful. You could have discussions on another list > specifically for this. this work-group already is that committee, de-facto - it was formed for exactly this sort of work - appointments are not needed, only volunteers are; but we dont have many of those - ie: gnutoo and i would probably just appoint ourselves, due to lack of willing candidates (just as we have already taken it upon ourselves to begin categorizing and hacking these) - this list has barely been used in the past 5 years - this is the sort of activity it desperately to re-invigorate its usefulness to the community we have already done much of the needed research on the parabola bug tracker; though, it really should have happened on this mailing list - the only reason that information has not made it onto this mailing list until now, is because there are no other distros interested in helping - the few other distros which had any desire to address these package managers, simply chose to discard them - IMHO, that is a fine option; but obviously, none will ever become liberated that way - trisquel may be the only one of those with the desire to reinstate them in a liberated form On Wed, 12 Jul 2023 22:02:30 -0400 Richard wrote: > Can you set yourselves a deadline of 3 weeks to find which are the > easier targets, and report? i definitely like that plan - it feels like movement
Re: [GNU-linux-libre] emulators and other hosts of foreign applications
On Wed, 12 Jul 2023 22:03:18 -0400 Richard wrote: > > It is not intrinsically unethical to use nonfree software. > > Using a nonfree program by yourself is not unethical. > > > Moreover, I would suggest that FSF should not be in the business of > > advising people at large not to use nonfree software, and to my very > > limited understanding, it does not have such a mission. the FSF does do that; and it is reasonable for them to do so, because we have libre replacements for every important use-case - but the FSDG does not require distros to have the same mission as the FSF, only to uphold the merits of software freedom without sacrificing it - a very simple way to do that is to tell people "you know, you dont actually need that non-free program - we have a perfectly adequate libre replacement for that use-case - plus! i signed it with my key, so that you dont need to trust some unknown third-party to compile your software for you" the issue WRT the FSDG is not for distros to actively criticize anyone for their personal computing habits - the FSDG is only requiring that distros do not provide, encourage, or suggest using non-free software, or to explain to users where to get some, or how to install it, or how to use it
Re: [GNU-linux-libre] emulators and other hosts of foreign applications
On Wed, 12 Jul 2023 22:02:54 -0400 Richard wrote: > The point is to about judging whether including a certain free program > tends to do indirect harm that outweighs its direct good (which, in > cases like ScummVM, is very small). This is not a matter of rigid > rules and "justifications". It is a matter of weiging good and harm. > > > but for one caveat - the FSDG as it is, is extremely vague - so vague, > that it > > was apparently _intended_ to be imprecise > > Yes, exactly! I think what you mean is that some of its questions are > judgment calls, a matter of weighing one goal against another. 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) the problem we have experienced due to vagueness and judgment calls, is that most distros do not participate in these discussions; and some will refute the consensus of the work-group and facets of the FSDG itself if confronted about alleged infractions; but they make no effort to change the consensus or the FSDG to justify their interpretations - instead, each distro makes their own judgment calls, quietly amongst themselves, often contradicting the judgment of other distros and the work-group as a whole - the result in the perception of the greater community is that we all look like we can not agree on what the FSDG actually specifies that is why i was applauding a call for precision, along with encouraging distros to participate in forming consensus on the few remaining judgments
[GNU-linux-libre] the purpose of this list
On Wed, 12 Jul 2023 22:02:53 -0400 Richard wrote: > I guess the first question was, what was the purpose of this list from https://lists.nongnu.org/mailman/listinfo/gnu-linux-libre > gnu-linux-libre -- Workgroup for fully free GNU/Linux distributions > > A list for coordinating GNU/Linux freeing efforts across multiple projects - > fully free distros, linux-libre, IceCat, etc. See also > https://libreplanet.org/wiki/Group:FreedSoftware. from > https://libreplanet.org/wiki/Group:FreedSoftware > Group: FreedSoftware > > Coordination for software projects to fill the gaps in 100% free software > GNU/Linux distributions. This mostly involves fixing freedom problems in > existing free and almost-free software. This is the main page for the public > facing, volunteer driven, endorsed/common distributions program.
Re: [GNU-linux-libre] Third-Party Package Managers
On Mon, 10 Jul 2023 22:34:47 -0400 Richard wrote: > > > if their operators shared our values, there would be no problem - the > > > haskell repos are only exception that i know of > > We also have: > > - For Emacs: ELPA GNU, ELPA non-GNU > > I know what those two are, but what is the issue about them here? > Why mention them here? > > Everything in them is under GPLv3+ or compatible licenses. that was why he mentioned it - he was adding the emacs repos to the very short list of third-party repos, which are known to have a strong libre licensing policy
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, 10 Jul 2023 22:36:31 -0400 Richard wrote: > However, having looked ath those games' license, I see it is nonfree. > So my decision is to state this policy: > > We urge free distros not to include ScummVM because does not > contribute anything significant to the free software commuity. if those four games are all non-free, the suggestion will most likely never apply to any distro, because it singles out that one specific and very unpopular program - scummvm is nearly unknown, even to gamers - that statement will only become less relevant over time most other game emulators have no games in the distros repos, and are much more likely to remain in the system, because they have always been used primarily for non-free games - scummvm is among the least interesting one of the lot - without those four games, libre distros will probably remove it anyways, with or without a suggestion to do so at the very least, you could generalize it like: > We urge free distros not to include emulators and hosts of foreign programs > without accompanying libre guest softwrae; because those do not > contribute anything significant to the free software commuity otherwise. in that form, it actually could be a reasonable requirement > Free distros must not include emulators or hosts of foreign programs > without accompanying libre guest softwrae; you are being very inconsistent about this though - on the other thread, you are suggesting that distros should keep _dozens_ of third-party package managers, probably for years, and not suggesting any sort of warning about those - yet those have a clear and present conflict with the FSDG, as it is already written
Re: [GNU-linux-libre] Docker
On Mon, 10 Jul 2023 22:34:30 -0400 Richard wrote: > > I meant that I was fine with removing all third party package managers > > if that was the only way to make Parabola not explode. > > I think that solution is so drastic and painful that we should rather > start fixing them one by one, and the distros can keep using the broken > packages managers until we replace them. it was not painful - users griped about the lost convenience; but these third-party packages managers should never affect the operating system - by those words alone, the danger should be obvious if that were true - if the removal of any were harmful to the system, that would be just cause to treat them as a fatal infection and eradicate them from the system, before those third-parties have the power to hold our systems hostage by withholding essential system components or dependencies - if you think i am over-stating that, it has happened before in the javascript world, with widespread damage those package managers are important for OSes without proper package management - we have proper package management - everything in those repos that people want to use, can and should be packaged properly by distros instead - to believe otherwise is an anti-distro mentality - that is the reason why removing them from parabola caused no damage - all of the important packages from those repos are already packaged in the distro repos - if users request more, we can add more ignoring that they are a loop-hole for installing non-free software, any distro dev who wants to keep these is only being lazy, or pandering to their users' desire for convenience - parabola has been guilty of both for years; but anyone who believes they are necessary or inherently valuable does not understand why distros exist and why those package manager exist - they are not for us - they are for someone else's (proprietary) system
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, 10 Jul 2023 00:52:58 -0400 bill-auger wrote: > the FSDG deals only with source code and has "the four freedoms" > as it's policy, and nothing more - anything beyond the four freedoms is > irrelevant or is posted as a warning sry typo - the *FSD* deals only with source code
Re: [GNU-linux-libre] Third-Party Package Managers
On Mon, 10 Jul 2023 03:41:59 +0200 Denis wrote: > That same paper from 2019 has some numbers: > +---+---+ > | Debian| over 59 000 packages | > | Maven Central | over 290 000 packages | > | RubyGems | over 150 000 packages | > +---+---+ there is one hugely important factor missing from that numerical comparison - debian repos are curated/audited/vetted, all are built from source, and all source code is provided - simply "adding" 150,00 packages to guix sounds like a big deal? - consider that _none_ of them have yet been audited by anyone who cares about licensing > So here we have 3 cases: > - Repositories that are 100% free software -> nothing to do. only one is known (cabal) > - Repositories that are not 100% free software but have strict > licensing -> Can be fixed somehow with the same approach than R. only one is known (flatpack) > - Repositories with lax licensing information: Very complicated to fix. that is all the rest (dozens of repos)
[GNU-linux-libre] third-party package managers
On Sun, 9 Jul 2023 18:37:56 +0200 Denis wrote: > If you have ideas on how to do it better feel free to share them, > because for me the proposed docker fix is close to ideal I think. that has been my priority all along, to catalog the possible solutions - there are not so many options for any of these all of the possible solutions are in the table in the OP, categorized by intrusiveness, maintainability, usability, and libre-effectiveness - whatever is "ideal" for each example, is going to be a compromise of one of other of those properties the solution chosen for docker is not ideal because it sacrifices "libre-effectiveness" - because dicker, like most of these, do not expose licensing meta-data to the client, the only way to achieve 100% libre-effectiveness for those, is either to reject them entirely (very easy), or to host curated repos (very demanding)
Re: [GNU-linux-libre] third-party package managers
On Sun, 9 Jul 2023 17:47:38 +0200 Denis wrote: > Is it OK if we keep them for now and warn users until some design work > is done by GNU? If some were removed, can we add them back? that is an essential concern for this work-group - if some software is generally considered to be problematic, the reasonable thing to do is to remove it, pending an investigation that is why we have been handling this in parabola as more of a whitelist approach: evaluate all of them shallowly, implement the simplest solution to all of them initially, _then_ work on liberating one or another individually according to their importance - in that way, we get _something_ done to address the issue in a time-boxed manor the past has shown us that some distro are not willing to do that, which means those controversial code-bases will probably never be addressed; because there is no imperative for any distro to do so - to require such controversial software to be excluded until proven fit, would give those distros some imperative to help us do the work, or at least to share their findings and opinions the approach RMS is suggesting, to address them only one at a time (the blacklisting approach), will result in most of them being ignored for years, regardless that we already have concluded that they all share the same essential freedom problem and all need some sort of treatment or removal
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, 10 Jul 2023 04:24:24 +0200 Denis wrote:
> I'd prefer avoid comparisons with the FSD as it's a different project
> that might or might not have the same set of policies.
i have already offered that analysis as best as i understand it (IIRC on this
same thread) - the FSDG deals only with source code and has "the four freedoms"
as it's policy, and nothing more - anything beyond the four freedoms is
irrelevant or is posted as a warning
so the FSDG is a proper super-set of the FSD criteria ("the four freedoms" plus
more criteria) - therefore, anything which fails an FSD audit is necessarily
unfit for the FSDG; so all of the FSD rejections are relevant to distros
the "List of software that does not respect the Free System Distribution
Guidelines" could list all of those immediately with the suggested liberation
treatment: "none yet known", and ideally go beyond that to suggest acceptable
liberation treatments for each, as they become known
On Mon, 10 Jul 2023 04:24:24 +0200 Denis wrote:
> And the next
> step if we look at the FSD would be to start looking at how similar
> it is, and then discuss FSD policies and so on, in a never ending
> discussion.
yea, like this one :)
i was only suggestion that as an ideal situation, to describe the intention and
utility of "the list" itself - this work-group is far from doing anything
"ideal" yet
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, 10 Jul 2023 04:19:00 +0200 Denis wrote: > If we just want a decision on the games, and not to add them to the > list of software that doesn't respect the FSDG we can have each distro > either: i think we wat to add them - that list should be resource for any software which has been audited by the work-group and found to be flawed - we should really consider integrating the FSD audits as well the rationale is not merely to be pedantic - it is a matter of efficiency, (to reduce duplicated efforts), the same reason your previous message suggested being more precise; so distro have a clear central resource where to find past knowledge, rather than repeating the same audits On Mon, 10 Jul 2023 04:19:00 +0200 Denis wrote: > > "is the license of 'bass' acceptable?" > It was not just bass but at least 2 or 3 other games if I recall well. there are only four scummvm games to deal with immediately - very likely, no others will ever be added to any distro - all four are in guix, trisquel, and pureos (and probably ututo) - parabola had only 'bass' and still has scummvm (with no dependents) - probably no other FSDG distros have any of these things we have a good handle on the entire situation - we only need to decide if the licenses are acceptable
Re: [GNU-linux-libre] emulators and other hosts of foreign applications
On Sun, 9 Jul 2023 15:00:53 +0200 Denis wrote: > So if we come up with something clear and not ambiguous, the cost > of arguing goes down significantly: distributions would just need to > point users and contributors to a very clear justification that speak > for itself. +100 but for one caveat - the FSDG as it is, is extremely vague - so vague, that it was apparently _intended_ to be imprecise - this is a great proposal, except that it only addresses one small area, which the FSDG already covers the entire FSDG should be revised in just that way, to remove as much ambiguity as possible from the existing requirements On Sun, 9 Jul 2023 22:37:01 -0400 bill-auger wrote: > so if we want to discuss how the FSDG can better serve distros "in the wild", > let us discuss ways to inform distros of the work-group's expectations, and > ways > to enforce them - it seems that all the policy is in place already really, we need to address the FSDG short-comings first - i agree with every word you have written today; but if we can not ensure that distro are aware of the expectations, or to enforce even the existing requirements, all new proposals are moot as things are now, distros are reviewed and endorsed, and nothing further - any flaws which may have been overlooked during the initial review, or are added later, will likely not be known to the distro as an infraction,, unless perhaps the distro is heavily involved with the work-group (most are not) - worse, even if infractions occur despite being know to be as such, infractions are without consequence ie: this is not the time to be considering additions or revisions, unless they address reform of the work-group's responsibilities and authority
Re: [GNU-linux-libre] emulators and other hosts of foreign applications
On Sun, 9 Jul 2023 15:00:53 +0200 Denis wrote: > And doing nothing is not an option because if distributions practically > speaking steer users too much toward nonfree software (for instance by > packaging software that is only meant to run nonfree software) but that is already prohibited, albeit vaguely: > A free system distribution must not steer users towards obtaining any > nonfree information for practical use, or encourage them to do so. however, the FSDG has caveats regarding this: > In general, something that helps people who already use nonfree software > to use the free software better with it is acceptable, > but something that encourages users of the free software > to install nonfree software is not. the wording is confusing; but it appears to be saying that any free software which helps people to use non-free software along with or via the free software, is acceptable if we reject that interpretation, then that sentence must be clarified - i dont see any other way to interpret those words if we take that interpretation, then this is a moot discussion - that is exactly what these host programs do, including the worse cases (game machine emulators) - they help people to run non-free games, using a free emulator, as opposed to using a non-free emulator if that was not convincing, consider this sentence, which is more clearly worded: > For a borderline case, a clear and serious exhortation not to use > the nonfree program would move it to the acceptable side of the line. so it seems to me that the FSDG already requires distros to warn users about scummvm or any other "hosts of foreign applications" - if sufficiently warned, those programs are acceptable - nothing new needs to be added - it is only matter of communication and enforcement, which are unfortunately the key factors that the FSDG is lacking now to select from RMS's options, the FSDG is already nearest to (4); but stronger > 4. Tell free distros they can redistribute it provided they remove all > information about finding the nonfree programs it can run. the FSDG already requires everything suggested by #4 - furthermore, it requires "a clear and serious exhortation not to use the nonfree program" so if we want to discuss how the FSDG can better serve distros "in the wild", let us discuss ways to inform distros of the work-group's expectations, and ways to enforce them - it seems that all the policy is in place already
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, 08 Jul 2023 22:54:02 -0400 Richard wrote: > When we consider the possibility of changing the criteria for endorsing > a free distro, this seems like the right list to use. you were not suggesting to change the criteria - you were suggesting to post some sort of warning, which distros could decide to heed optionally - there is no place to put such a warning - the FSDG has never done anything like that that sort of warning is often added to the FSD entries though On Sat, 08 Jul 2023 22:54:02 -0400 Richard wrote: > Arent the maintainers of free distros on this list? > I thought they were. there are only a few - we wish that all of them would participate; but it is not a requirement
Re: [GNU-linux-libre] emulators and other hosts of foreign applications
On Sat, 08 Jul 2023 22:53:07 -0400 Richard wrote: > > this part just went full-circle back to a few weeks ago > > "emulators and other hosts of foreign applications" > > > https://lists.nongnu.org/archive/html/gnu-linux-libre/2023-06/msg00088.html > > You're focusing on abstract classifications of programs, but that's > not what this issue is about. > > Right now we are thinking about the ScummVM case. I do NOT expect we > will want to treat all such cases alike. > > I don't think that "being a VM" is a pertinent factor anyway. > > even those which would be the safest to recommend, such as QEMU, can run > non-free software as well as anything > > That is too terse for me to follow. What _exactly_ is the stance > you are arguing against? all of that was based on the previous context - you asked the question: On Mon, 19 Jun 2023 22:54:31 -0400 Richard wrote: > Is this kind of issue really limited to emulators? There are other > kinds of programs which are platforms to run other programs, and I > think that they would all raise similar issues my answer was "no, this kind of issue applies to any emulator, VM, or interpreter" - it only depends on how generically the concern is applied - that is why i changed the subject; because generally, the concern goes well beyond scummvm, to any "hosts of foreign applications" (wine, java, python, audio plugin hosts, you name it) as for which are predominantly used to run non-free software, id say the three topping that list would be QEMU, wine, and audio plugin hosts
Re: [GNU-linux-libre] is the license of 'bass' acceptable?
On Fri, 07 Jul 2023 05:05:04 -0400 Richard wrote:
> I don't know what this license says, but this "precedent" argument is
> not the right way to think about these issues. If a decision is
> clearly right, we don't need to cite a precedent for it,
this post shows the dubious section of the license, and its similarity with the
analogous license section of the OFL license
https://lists.nongnu.org/archive/html/gnu-linux-libre/2023-06/msg00056.html
the complete license is in this post
https://lists.nongnu.org/archive/html/gnu-linux-libre/2023-04/msg00015.html
On Fri, 07 Jul 2023 05:05:04 -0400 Richard wrote:
> If we see a need to reconsider a decision, we should reconsider
> thoughtfully based on what we know and understand.
>
> Let's hope our old decisions were mostly wise and that few need
> reconsideration.
i dont know if the previous decision needs reconsidering - you are the one who
suggested that; and presumably you are the one who approved the license
originally - i was not around then - i dont know where that discussion took
place or who was involved
if the previous decision was wise, then this one ('bass') probably should be
acceptable; because the dubious section of the license is the same trivial
requirement
maybe it would be best to make a decision about this one in isolation (that
was the original purpose of this thread), then revisit the OFL license, if this
one ('bass') is not 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 Fri, 07 Jul 2023 05:02:44 -0400 Richard wrote: > I am not sure what you mean by saying one is a "webmaster's concern". > It is a question of what to say in www.gnu.org, to be sure, but you > seem to mean something else, and I am not sure what. no, that is all i meant - this mailing list is for reviewing distros and liberating non-free software - there is nowhere in relation to the FSDG to put arbitrary recommendations of the sort this is proposing (to recommend rejecting scummvm, although it is libre) - that concern is outside the scope of this work-group the "List of software that does not respect the Free System Distribution Guidelines" in the subject is a list of recommended liberation treatments of non-free software - all entries are of the sort: "distros must treat this software or discard it" - in general, those are software which would not qualify for the FSD - none are of the sort: "distros may choose to discard this software; although it requires no libre treatments and is listed in the FSD"
[GNU-linux-libre] emulators and other hosts of foreign applications
On Wed, 5 Jul 2023 14:52:08 +0200 Denis wrote: > > Is this kind of issue really limited to emulators? > Yes there is. Some compatibility layers have the same issue. > > It also applies to operating systems like Android etc, so we can treat > the issue in a more generic way if we want. > > > Perhaps you can generalize it to be about programs with a certain > > structure of use cases, rather than "emulators". > Yes. this part just went full-circle back to a few weeks ago "emulators and other hosts of foreign applications" https://lists.nongnu.org/archive/html/gnu-linux-libre/2023-06/msg00088.html as i noted earlier, it depends how "generically" they are viewed - in the strictest sense, it would apply to every runtime and language interpreter, such as java, dotnet, python, gnu-smalltalk, etc - anything which can be characterized as a VM even those which would be the safest to recommend, such as QEMU, can run non-free software as well as anything
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
[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] Parabola packaging
On Mon, 3 Jul 2023 20:25:04 -0700 Ian wrote: > I would never ask that the > core - though free - not be coded in such a way that someone may install > non-free software on it. no one could reasonably ask that; because it is impossible to accomplish - the only way to prevent it, would be with some non-free, non-removable gate-keeper program - if that mechanism were free, people could easily remove it
Re: [GNU-linux-libre] Third-Party Package Managers
On Mon, 03 Jul 2023 21:57:24 -0400 Richard wrote: > I think "third party" is not a very good concept to explain what these > things are and why they are an issue. It focuses conceptually on the > relationship that they have to distros, rather than on why they exist. "third-party" is much more significant - the term was taken directly from the FSDG > Nor should the distribution refer to third-party repositories that > are not committed to only including free software; their problem with them is not the languages nor _why_ they exist - their problem is the mere fact that they do exist and are widely used by and desirable to users; but are operated by people who do not share our values, and thwart our attempts to uphold them if their operators shared our values, there would be no problem - the haskell repos are only exception that i know of On Mon, 03 Jul 2023 21:57:24 -0400 Richard wrote: > > that alone makes them all very ugly and undesirable from the distro's > > perspective - all things being equal, we should not need any of them - > they all > > exist because windows and mac do not have proper package management; so > every > > programming language established their own > > I agree completely, but there is noi use fulminating against them. > If we want this problem fixed, we have to fix it. ok, but that is the reason "why they exist", which you just offered as the primary motivation for fixing them - i was suggesting that we really dont need them at all; because we have proper package management already - those are intended for, and mainly useful for someone else's systems
Re: [GNU-linux-libre] third-party package managers
On Mon, 03 Jul 2023 21:56:50 -0400 Richard wrote: > That is technical design work. There are users of those languages on > gnu-prog-discuss and we can have good discussions about how to fix > them. this mailing list was created specifically for that purpose - that is why we are subscribed to it there are users of those languages _everywhere_ - we could have good discussions on this list too; though they would be public, as they should be - gnutoo just tried to have such a discussion; but you asked him to stop it's no wonder why this work-group has become dysfunctional - both the FSF and GNU dismiss its importance, ignore it, and even thwart attempts to make progress (notice my proper "its" correctness - nailed it this time) On Mon, 03 Jul 2023 21:56:50 -0400 Richard wrote: > If and when we have fixed them. we can talk with the developers > of free distros about adopting our solution. im more than happy if someone else wants to do the work; but you are literally telling us that only GNU developers are qualified to decide how to handle these freedom issues, and to do the work, although it is _not_ GNU software, and this will all be done privately, then finally dropped on us from upon-high - all the while, we must not discuss it, nor do any similar work (in the very work-group which was created specifically for that purpose) doesnt that seem the least bit arrogant to you? - the spirit of collaboration of which you speak so highly, seems to be absent from that project
Re: [GNU-linux-libre] Parabola packaging
On Sun, 2 Jul 2023 20:20:04 -0700 Ian wrote:
> 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
> then use
> AND don’t install supported non-free software
>
> Is it not that simple?
i think it could be even simpler - you may have a bug in that pseudo code
no free distro can prevent running non-free software; so every FSDG distro
satisfies the 'else-if' - in fact, only FSDG distros do - so that second
antecedent of the 'else-if' ("AND allows non-free software") is always true, if
"allows" means "can not prevent it" - however, if you never install non-free
software, then that would be irrelevant to the equation anyways; because it
could as well be its negation: ("AND NOT allows non-free software")
maybe you meant: "AND don’t install _un-supported_ non-free software"
or its inverse: "AND install only _supported_ non-free software"
because you would be hard-pressed to find any distro which both "is free" and
"supports" (literally) non-free software, if "supports" means differently than
"allows", but it means "assists, distributes, documents, accepts bug reports,
or similar" - applied to real-world inputs, you will find that any such
distro would also satisfy the 'if' ("contains non-free software")
Re: [GNU-linux-libre] third-party package managers
On Sun, 02 Jul 2023 22:46:21 -0400 Richard wrote:
> We may as well deal with Cargo because we're here.
that would be acceptable to me also; except that the "we" who are "here"
("here" being the FSDG list) are not involved in the cargo discussion - it was
revealed only a few days ago, that there was any such discussion about cargo;
because that is happening on a private list
Re: [GNU-linux-libre] Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines"
On Sun, 02 Jul 2023 22:44:48 -0400 Richard wrote: > In that case, if we find that there are indeed a few free games that > use ScummVM, let's adopt that statement. There seems to be no > significant reason not to. > > Supposing there are a few free games that use ScummVM, either of two choice > would be possible: > > 1. Treat it like any other free program. > 2. Use my announcement, above. what i am trying to address on this list (the FSDG list), is that these are separate concerns - to make a statement about scummvm is a webmaster's concern - to decide if the games, which distros are distributing now, are acceptable is an FSDG concern the "reason not to" (to make a statement about scummvm) _yet_, is because we have yet to address the primary concern of the games licenses - although that is the only reason why this discussion started i suggest to move the discussion about a general statement to the webmasters list, and focus on the license of the games on this list; because that is the more urgent concern, and has yet to yield an actionable consensus
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 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 do agree with that statement; however, the thing is, distros are distributing scummvm now, because there are free games for it - that is the only reason why any distro is distributing scummvm today if there were no free games for scummvm, no one would need to recommend excluding it - distros would most likely remove it anyways; because the package has no dependents remaining in the system so more to the point, the only reason why we are discussing scummvm is because we have yet to determine if those scummvm games are or are not libre - if they are libre, then there is nothing remaining of importance to discuss - this is "putting the cart before the horse"
Re: [GNU-linux-libre] third-party package managers
On Sat, 1 Jul 2023 01:55:03 -0400 bill-auger wrote: > i dont see any of them as important enough to prioritize blindly gnutoo addressed docker, only because he uses it - that is not because it was the most important or was the easiest to fix i have a gut feeling that rust cargo is going to be the most problematic of all; so i am not eager to begin this over-all goal by investigating that one in isolation - i suspect that the reason why rust is being discussed among GNU devs, is because some people have made the pre-determination that it is the most important - i disagree - i hold no favoritism in this matter
Re: [GNU-linux-libre] Parabola packaging
On Mon, 26 Jun 2023 21:01:40 -0400 Richard wrote: > To other experts, such as GNUtoo, what you write would be clear. > But I don't have that background knowledge. For me to understand, it > behooves you to notice when a person needs some background knowledge > to understand -- and state that background knowledge explicitly. i understand - i did not intend to make a detailed point of parabola's packaging - i was only vaguely trying to explain that to remove some undesirable or unpopular software from the parabola repos is not a "deal-breaker" for any user who still desires it - it is only a minor inconvenience to find the recipe and install from source
[GNU-linux-libre] Third-Party Package Managers
On Sun, 25 Jun 2023 22:16:35 -0400 Richard wrote: > Sorry, I don't know the term "TPPM". "Third-Party Package Manager" we invented that acronym to describe this class of program - that is the property all of these share which conflicts with the FSDG - they are downloaders for foreign repos, which are not dedicated to software freedom - some may have additional features, but those features are not problematic docker, cargo, pip, npm, many many more - they are all similar enough for our purpose, to be considers as equivalent competing implementations of the same misguided use-case: to search for, download, and install foreign un-vetted software onto your system that alone makes them all very ugly and undesirable from the distro's perspective - all things being equal, we should not need any of them - they all exist because windows and mac do not have proper package management; so every programming language established their own the proper way to handle that use0case, is for each distro to package each library in their distro-specific format; but that is a lot of redundant effort, and the vast majority of users will never want any of those libraries
[GNU-linux-libre] third-party package managers
On Mon, 26 Jun 2023 21:00:35 -0400 Richard wrote: > > - a slight variation to that, would be to curate > > libre-only repositories for each package manager, and hard-code that URL, > so > > that the user needs not to define one > > That would be adequate, but in some cases could be a gigantic job. it would be a gigantic job in _all_ cases, guaranteed - first identifying the potential good set according to the license declared as metadata (if any is declared), then collecting those, and hosting them, is the least of the effort - that could perhaps be mostly automated - but each of those many thousands of packages should be audited, to ensure that the declared license is correct (if any is declared) and if the code-base itself is licensed properly, contains no blobs, and so on - rough estimate: a minimum of one hour per package, times thousands of packages, for each of dozens of repositories therefore, it would be wise to classify and prioritize them all before attempting such a feat - that is the purpose of the table on the parabola ticket On Mon, 26 Jun 2023 21:00:35 -0400 Richard wrote: > You may have the attention capacity available to think about each one > in parallel, but I don't. It is useful for you to accumulate > information about them all. that table was not to consider any specifically - it was to abstract the general properties they all have in common, and to itemize and rank the possible solutions, which are applicable to all - it was not necessary to investigate any of them, in order to make that table of options we have yet to accumulate much information on any of them, and we have only applied any solution to three of them so far, each among the simplest, but least satisfying solutions - namely: get rid of it entirely, or null its default search/download URL rather than handle any one of them independently, they all could be investigated and evaluated in stages - that would help to prioritize the most important vs the most demanding ones the only analysis that was done so far (call this stage 1), is that i read the policies of a few of the more popular ones - that was only to classify them as having a strong, weak, or absent licensing policy - only one (haskell cabal) had a strong libre-only licensing policy; so we can eliminate that one for all subsequent stages then next phase is to determine if the client has access to the declared license in the metadata, before downloading - if so, that one would qualify for the hacking treatment (filter search results and downloads, based on the declared license) - that is relatively simple but a weak solution; because none of those packages would be audited - the declared license could easily be incorrect, because most of these repos accept anonymous uploads, which are not vetted in any way however, precisely _how_ to implement that filter is not important at this stage, only that it is a candidate for that sort of treatment - all of these tools are free software; so we know that it is possible _somehow_ once they are all classified by their applicable treatments, they could be prioritized by importance, and the actual work could begin if the client does not have access to the license metadata, then depending on its importance, it could get the null URL treatment, or be ejected from libre-land entirely, or a greatly more time-consuming approach would be needed to rescue it if ejecting rust for example, is the only feasible option, and if doing so breaks every rust program in existence, then i guess every rust program needs to be ejected too; because i seriously doubt that we are going to accomplish the complete repo reconstruction necessary to rescue the worst of those programs i am much more in favor of first identifying which of those programs are amenable to the most and least feasible treatments, rather than to focus on any one without that foreknowledge; because frankly, i dont see any of them as important enough to prioritize blindly
[GNU-linux-libre] third-party package managers
On Thu, 22 Jun 2023 21:45:01 -0400 Richard wrote: > Anyway, the right place for those discussions is gnu-prog-discuss, > not here. with all due respect mon capitaine, i beg to differ - this is the most appropriate list to discuss these third-party package managers and their repositories; because most every distro distributes those programs - it is well beyond a GNU-only issue - this general topic began on this mailing list in 2016 http://lists.nongnu.org/archive/html/gnu-linux-libre/2016-04/msg00070.html http://lists.nongnu.org/archive/html/gnu-linux-libre/2016-04/msg00116.html according to the gnu-prog-discuss mailing list topic, guix is the only FSDG distro, whos team members may participate - whatever conclusions are reached would affect all FSDG distros, so we should have a voice in the discussion - that is precise the purpose of this mailing list About gnu-prog-discuss: > This list is an internal list to the GNU project. Only active GNU programmers > and maintainers may join. gnu-prog-discuss is for those who would like to > discuss issues of programming that affect the GNU Project (e.g., coding style > or library organization). gnu-prog-discuss should not be mentioned in other > contexts. On Thu, 22 Jun 2023 21:45:01 -0400 Richard wrote: > Let's not rush into a discussion of Docker now. That discussion will > take time and attention. We do not know enough about Docker and its > usage to reach any conclusions. (You seem to know something about it, > but that knowledge has not been stated here, so _we_ do not know it.) gnutoo brought up docker; because he found a potential solution for it - to announce that on this mailing list is exactly what we hope all FSDG distro devs would do - im quite sure that he has shared everything he knows about it in this thread - not much is known of any of these; because so few people care to address the issue - that is evident from the fact that the discussion began in 2016 and we are no closer to a solution for any of these today each of them will take time and attention - i agree that it is reasonable to handle one at a time - cargo definitely needs discussion - that one is probably going to be the most troublesome of all; but this is the first i know of anyone discussing freedom concerns about cargo - i know that the hyperbola team has excluded it on principle; but there has been no public discussion that i am aware of
Re: [GNU-linux-libre] no drm book
i would just add that the answer should be obvious, to the questions of where to PUT or where to GET digital books - the answer is: "any server on the internet is sufficient" - the web (aka: HTTP) was designed specifically for that very purpose, and for that purpose exclusively - HTTP uses, not surprisingly, the intuitive 'PUT', 'POST', and 'GET' requests as among the it's common "verbs" the only reason i can imagine DRM being part of the question, is if some publishing "platforms" would require or inject DRM - they probably all require running non-free javascript to read about and access the work also - but no one needs any "platform" nor "publisher" for this - anyone with a computer can publish it, and anyone else with a computer can retrieve it - IMHO, the best source for a published work is directly from the author, if the author is concerned about fair or ethical distribution - any search engine would be sufficient to direct people to the resource, if one knows in advance that such a resource may exist so what this question is really asking, is for a third-party service which can help to advertise the existence of the resource to a wide audience - it is one of the most common arguments (though misguided) against self-hosting: "but how will people find me?" - answer: "that is why search engines were invented" for any digital work, the concept of a "publisher" is obsolete - this question is asking for a "distributor" or a "marketer" - that is a very different concern from "how to publish?" or "should i use DRM?" - it is a sad state of affairs, if people (especially libre-minded people) generally see those concerns as intrinsically entwined WDYT?
Re: [GNU-linux-libre] Docker
i can answer some of those questions On Wed, 21 Jun 2023 21:56:26 -0400 Richard wrote: > Was it you who implemented this fix? You didn't say so; you said > only that it had been fixed in Parabola. yes, that was all denis - he was also the most ardent about finally moving forward on more of these TPPMs - the most popular examples are removed now (pip and rubygems) On Wed, 21 Jun 2023 21:56:26 -0400 Richard wrote: > > I changed the default repository to http://localhost but since nothing > > is there, it doesn't pull images by default from docker hub anymore. > > That seems rather drastic. Will Docker, thus modified, still function > for the legitimate jobs (using free software only) that users expect > it to do? > > Keep in mind that all I know about Docker is that it packages programs > together in a container. it can launch the "container-ed" programs, and the same application can also search the docker-hub repo (replete with non-free OS'es and applications) for recommendations, and download the packages; so it qualifies as a third-party repository per the FSDG - it can also search and download the OS container images, for developers to add their applications into, and publish those back to the third-party repo the current solution has no hard-coded remote URL; so it can not search, download, or publish, without manual user configuration - though it can probably still launch application if one has a copy already, and generate application containers if one has a prepared OS base image already On Wed, 21 Jun 2023 21:56:26 -0400 Richard wrote: > What is `byzantium'? What is `pureos/byzantium'? it is simply a version release name - trisquel uses similar names such as: 'trisquel/nabia' On Wed, 21 Jun 2023 21:56:26 -0400 Richard wrote: > It sounds like you think the new behavior is flawed. > What would desirable fixed behavior be? generally, a more desirable fix is one that behaves exactly as the standard tool, without manual user configuration, yet offers libre-only software selection - the current solution satisfies the FSDG, but is missing those other desirable properties On Wed, 21 Jun 2023 21:56:26 -0400 Richard wrote: > If you don't have a real solution ready, we could put this off and > deal with it later. FWIW, this already is "later" - we have been deferring to address these for about 7 years now - o/c a bit longer wont hurt; but this is a very large problem - docker is only the tip of the proverbial iceberg for an overview of what we are dealing with (the number of examples which would need treatment, the proposed solutions. and their consequences), see the table on the OP of the parabola related ticket: https://labs.parabola.nu/issues/1035 the solution chosen for docker (as this thread is describing) was "disable default URL, make user-configurable" - the solution chosen for pip and rubygems was "remove TPPM - do nothing else" - both have "FSDG-fitness: total" and were relatively easy to implement; but neither are not the ideal options to answer the previous question, the ideal solution is one with the properties: workload: none or minimal intrusiveness: none or minimal disruption:none or minimal effectiveness: total FSDG-fitness: total unfortunately, none of the proposed solution is ideal - we probably will need to settle for satisfying the latter two, with the least disruption to user's workflow
Re: [GNU-linux-libre] Parabola packaging
On Mon, 19 Jun 2023 22:54:09 -0400 Richard wrote: > 1. Is each and every one of the user-maintained recipes supposed to be for > a free program? no - parabola does not host any user-maintained recipes, and does not direct users toward any - we generally warn against installing any third-party software yet, almost every parabola user know where to find them (arch hosts them); so they will have no trouble finding a recipe for any package that parabola has discarded - albeit, they will most likely find it in a pool alongside recipes for non-free programs (which are usually simply installers for the publisher's binary) On Mon, 19 Jun 2023 22:54:09 -0400 Richard wrote: > 2. How does Parabola deal with the issue of free programs that are > useful only for running nonfree programs? Does it try at all? If so, > in which steps? we believe that the FSDG prohibits such a program > The system should have no repositories for nonfree software and no specific > recipes for installation of particular nonfree programs. if the entire functionality is to install something else, that is effectively an executable recipe - the classic example is the flash-player installer - that program may itself be free - in theory, someone could modify it to install something other than the flash player; but there is little to no motivation for that use-case in general On Mon, 19 Jun 2023 22:54:09 -0400 Richard wrote: > 3. How do they verify that a package is really all free software, > when someone proposes to add it to the user-maintained recipes? i realize now the confusion - i was too vague - the user-maintained recipes i was referring to, are the ones that arch hosts - parabola does not blindly accept recipes as arch does - when i wrote that discarded packages are reverted to the user-maintained pool, i did not intend that explicitly - i was referring to the arch pool, where those recipes are hosted already, and will be, regardless of what parabola does parabola users do submit recipes for consideration, as a "packaging request" - we evaluate those thoroughly (eg: is it well-licensed, does it build entirely from source, does it recommend anything non-free or download anything from a third-party at runtime) - if accepted, parabola will host the recipe and binary packages - the user who submitted it is asked to continue maintaining the recipe, as an honorary team member; but they are not obliged to do so
[GNU-linux-libre] emulators and other hosts of foreign applications
On Mon, 19 Jun 2023 22:54:31 -0400 Richard wrote: > Is this kind of issue really limited to emulators? There are other > kinds of programs which are platforms to run other programs, and I > think that they would all raise similar issues -- though perhaps there > is an empirical tendency for emulators to be used for running nonfree > programs. in the broadest sense, it is somewhat ubiquitous - any application, which its only purpose is as a host of other "foreign" applications would qualify - in addition to the obvious emulators and game engines, hugely popular VM "platforms" such as java, python, also audio plugin hosts, and let's not forget web browsers, would also meet that description for emulators (the questionable ones) it is not precisely a "tendency" to be used primarily to run non-free programs - in most cases, that was the original motivation for writing them - nintendo emulators for example, are probably the most prolific and popular; but no one writes new games for them - they are popular for the nostagia value of playing the old games often though, the motivation was only for the author to practice the art of emulator/compiler design - ie: the original author never intended to _use_ it for anything another aspect of those, is that often the emulator itself is not entirely reverse-engineered, but will include the original manufacturer's operating system ROM, or require that the user acquires one, in order to do anything with it - most MAME emulators are of that sort - they do not distribute the ROMs for copyright reasons; but the emulator is useless without them, other than educationally (to study emulator/compiler design)
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:57:42 -0400 Richard wrote: > I never saw any mail about that topic, but it is worth thinking about > in hope of reaching some conclusion. i see - i guess someone CC'ed you later - note the thread subject: "Adding some scummvm game(s) to the List ..." it would be prudent to decide that first - IMHO, the next discussion topic that should lead to, is "how to better maintain the (long-neglected) List"
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 wrote: > The question is not whether ScummVM false into the category of "0 free > games need it" or "1 or more free games need it". agreed - but there are good reasons to prefer the logical approach for one, decisions based on logic are objectively verifiable, and they can be decided in a finite amount of time - decisions relying on judgments are subjective, and can drag on indefinitely - if decisions must be re-evaluated for every similar instance, it becomes a sisyphusian task - that is quite important when we are dealing with a pool of many thousands of softwares, any of which may have subjective criticisms secondly, the subjective approach is what we have now, with common issues going unresolved for years - it is also, why we have FSDG distros arriving at conflicting conclusions, regarding which software are fit and which are not On Mon, 19 Jun 2023 22:55:29 -0400 Richard wrote: > 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." my opinion is even simpler - ScummVM is not significant enough to warrant a single word of this discussion i can understand the need of that deliberation for popular or "high-profile" software - i propose that the microsoft dotnet suite is one of those, which has never been discussed - it would pass the threshold of "1 or more free clients exist"; but "does the free world need it?" is dubious and highly subjective if taken on a one-by-one basis, this discussion is exemplary of the inefficiency of the subjective approach, per the desirability/work-load ratio, which i use to decide which to keep, which to fix, and which to discard - discussions such as this, weigh in on the work-load factor, while the desirability of ScummVM decreases with each passing "gaming aeon" (roughly 5 years)
Re: [GNU-linux-libre] Docker
On Mon, 19 Jun 2023 22:54:37 -0400 Richard wrote: > Docker is one of the many package manager systems that we will need to > address one by one. (I expect that we will find that the differences > between them lead to a need for different solutions.) they are quite conventional though - there are two general ways to handle it all could be addressed by the approach denis chose for docker, which is the least user-friendly option - a slight variation to that, would be to curate libre-only repositories for each package manager, and hard-code that URL, so that the user needs not to define one (but then the user would be unable to define any other alternative, such as the package manager's standard repo) the other generally applicable approach is only possible if the the package manager's standard repo exposes licensing metadata - in that case, the client could be modified to filter non-free results - unfortunately, most do not indicate the license, or even require that the uploaded defines one recently, one of them (flatpack) decided to do that - their tool now offers an option to filter "free-only" - thats not quite sufficient; but it does make the tool easier to patch (to force that option always) On Mon, 19 Jun 2023 22:54:37 -0400 Richard wrote: > If so, maybe we should explain to all free distros how to fix it that way. that is what i see as the primary value of the "List of software that does not respect the Free System Distribution Guidelines" (not only to warn about certain problematic programs, but also to offer suggestions for how to liberate them)
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 wrote: > The proposed action > under discussion is to state officially that ScummVM has a problem. we seem to have lost focus - this thread need a reboot the original topic was about the games, currently distributed by some FSDG distros, with a license which is _possibly_ non-free - we have yet to decide that is indeed the case we then speculated that there may be no libre games known to be compatible with ScummVM; and in that case, _maybe_ ScummVM itself becomes dubious - we can not seem to agree on that either; but that is not worth discussing yet - that is predicated on a conclusion that no libre games exist; which has not yet been concluded from there, it leaped to a proposal to "state officially that ScummVM has a problem" 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 ruben also suggested that such licenses are already deemed acceptable, referring to the precedent case of the OFL fonts license if we had stayed on topic, and concluded in the first place, that the game license is acceptable, the engine would never have been in question - without a resolution to the original topic, the game engine was a red herring so we should return to the original topic - is the "no-selling" license of "BASS" acceptable or not - if it is acceptable, nothing remains to discuss - if it is not acceptable, we should move to the original proposal (add it to the list fo software to avoid) - that would be good progress; because that itself is another important topic to discuss - namely: that list is dreadfully out-dated and needs a total review
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 02:58:33 -0400 bill-auger wrote: > we are yet to determine whether or not it is a non-free license, per the FSDG this is a good thing BTW - this is the first instance where ive noticed more than two distros represented in any discussion on this mailing list - there seems to be three distros interested in this discussion now - that itself is a positive outcome IMHO
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 wrote: > Guix is supposed to be entirely free software. > How can they justify the inclusion of these games, > they being nonfree? i suspect that the most distros distributing these games relied on debian's judgment, that they were fit for debian's DFSG; because debian usually does a thorough job - however, debian uses different guidelines than GNU - it is only recently that anyone has contested those licenses - this may be one of those instance exhibiting the subtle differences between the mostly-compatible guidelines of different distros but again, rubuen has suggested that GNU has already accepted licenses of that sort - ie: we are yet to determine whether or not it is a non-free license, per the FSDG
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 wrote: > Is there an actively maintained _libre_ replacement for ScummVM? there probably are no replacements for it's _precise_ feature-set; because it's precise feature-set is limited to that one style of "point-and click" game, which has gone "out of vogue" many years ago - however, modern game engines are versatile, supporting most any style of game - if someone wanted to make a new one, any of the newer actively-maintained game engines could replicate ScummVM's feature-set, albeit without support for obsolete hardware
Re: [GNU-linux-libre] Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines"
On Wed, 14 Jun 2023 22:30:48 -0400 John wrote: > I was answering bill's claims about how > many people are still interested in it. i understood you - i would just add that 2009 was almost 15 years ago - in gamer years, that is 3 aeons ago - the underlying technology is 10 aeons old - i trust that most readers of this list do not have such a myopic view of software; but gamer culture does but that is not the reason why i am so inclined to dismiss these games and the engine - it is because to me, _no_ games are important enough to deserve such fuss - they are purely for entertainment; so they are inherently low priority - from that perspective, we may as well be discussing how many "lady gaga" videos we can distribute - answer: "i dont care - we have bigger fish to fry today" - "zero" is as good as any other amount - lets just decide, then move on with due haste my dismissiveness is not absolute, only a matter of priorities - the desirability/workload ratio of each game is typically very low - in my experience auditing software licensing, games are time-bandits in only one instance, was i successful to convince the upstream to clarify the licensing - unfortunately, he had forgotten where he got most of the images from; so that never actually happened - he promised to accept submissions, if someone wanted to replace all of the images; but stated that he was not likely to do anything more that one was a relatively _positive_ experience - game authors/maintainers are typically dismissive of licensing deficiencies, out-of-hand; and some readily become indignant and/or obscene - in another instance, the bug report was closed within 15 minutes, with a single remark from a maintainer: "F--- You!" (my dashes) - that was not an obscure game either - it is one of the most popular libre games in another instance, the author refused to clarify the license, because he was convinced that the game's mere existence, put it automatically and implicitly under the same license as the game engine that it runs on - as proof, he directed me to the game engine's wiki, where the game's release was originally announced - those release notes had no mention of any license, nor did the source code; but in the authors mind, that announcement itself, because it was on that wiki, was sufficient licensing for the game files the liberation prospects are even worse for decades old games - for those, it is likely impossible to contact the authors - i have come to conclusion, that it is unwise to spend any significant amount of time on any games, given the average success rate and time consumed
