Re: [GNU-linux-libre] is this work-group still serving the community?
On Mon, 1 Nov 2021 23:05:47 +0100 Sam wrote: > make a list of all modified/deleted packages. its much simpler than described in the previous post - starting with parabola's blacklist, most of the work is already done this is exactly the "blacklist rescue team" project proposed for the FSD a few years ago - at that time, i wrote a script which effectively mirrors the parabola blacklist data on a wiki - the data is a single CSV file with references to detailed bug reports and/or liberation procedures https://git.parabola.nu/blacklist.git/tree/post_fsd_wiki.phantomjs?h=wiki-post any distros with similar blacklists could use the script to add distro-specific details/caveats sections IIRC, the reason for the debian bias on that wiki page is because that list was maintained by trisquel and/or gnewsense devs - that is one key area to improve initially - the most difficult hurdle ahead, is to extend the script to map distro-specific package names to wiki pages, reduce duplicates (merge electron, electron6, electron7, ...), etc FWIW, the intention/policy of the parabola blacklist has always been to complement the FSDG blacklist, and to prefer the FSDG blacklist as the primary reference/bug-report, for any programs on it - so the idea to automate synchronizing/consolidating the knowledge-base is as old as the FSDG and parabola themselves - it appears to be among the original intentions of those distros, which were involved with the FSDG in the early years
Re: [GNU-linux-libre] linux ppc micropatch.c: why keep it?
On 8/22/21 3:27 AM, Alexandre Oliva wrote:
When I got involved with Linux-libre back in 2008, a file named
micropatch.c already existed in the Linux source tree, in
arch/powerpc/sysdev/micropatch.c. It's now in
arch/powerpc/platforms/8xx/micropatch.c.
The initial version, added back in 2007, had two sets of binary
"patches". Comments stated:
/* Microcode patches for the CPM as supplied by Motorola.
(CPM stands Communication Processor Module)
Despite the appearance that these "patches" could be code rather than
configuration data, gNewSense (and then BLAG) appear to have decided
that it could be left in, for reasons unknown to me. I assumed there
were good reasons for that, even though I didn't know them, so the
binary "patches" have remained in Linux-libre releases since then.
For most of the time, they've remained unchanged, except for
reformatting of the arrays containing them. Back in Jun 14, 2019, a new
set of binary "patches" were added. It was quite similar in appearance
and spirit, so I also retained it, assuming the same reasons applied.
Part of the commit message that introduced the new bits states:
This microcode is provided by Freescale/NXP in Engineering Bulletin
EB662 ("MPC8xx I2C/SPI and SMC Relocation Microcode Packages")
dated 2006. The binary code is public. The source is not available.
Recently, someone asked in the GNU Linux-libre discussion list why we
didn't remove these bits. I don't know the answer. I wish I did. I
find myself wondering whether it should really have been left alone.
Does anyone have any insights to share as to why this might have been
left in? Absent more information, if I were to come across it today,
I'd most certainly have removed it from Linux-libre, so I'm leaning
towards doing so in the git history rewrite project I've been slowly
working on.
thanks in advance for any information you may provide,
It appears gNewsense categorized it as a false positive, back in the
day. I don't know why.
You can see a snapshot of it from their subversion here (ctrl-f
micropatch.c):
https://web.archive.org/web/20090106133329/http://svn.gnewsense.svnhopper.net/gnewsense/builder/tags/deltad-2008-03-24/firmware/firmware-false-positive
I haven't found any reference to micropatch.c in my old LinuxLibre files.
FYI,
-Jeff
Re: [GNU-linux-libre] is this work-group still serving the community?
On 1/11/2021 05:46, Denis 'GNUtoo' Carikli wrote: Though I really like the idea of sharing the work between the distributions. The question would also be how to share it practically speaking. Back when (2012) I was pretty active on the non-FSDG wiki page I asked myself that same question and shared some thoughts on the Talk page [1]. I often had the feeling that the wiki page was too Debian-based focussed and not technical/machine-readable enough. [1] https://libreplanet.org/wiki/Talk:List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines Or maybe we need to get there step by step? Perhaps a first step that should be fairly easy for each distro is to make a list of all modified/deleted packages. Extract a list of common entries (might need some normalization). Ignore the differences for now, they can be discussed once the process is figured out. Edit the non-FSDG wiki page to match that list (title + package name to start, the other fields can be filled in later). In Parabola for instance if we have our deblob instructions in an mksource() function in the package definitions. But that content could also be moved to scripts to enable other distributions to reuse them. Other distros probably have something similar (e.g. Trisquel's package helpers). The wiki entries could be enriched with a link to each distro's scripts. I'm not thinking further ahead, the next step might present itself more readily when this is done. I think this would already help quite a bit with sharing between distros and with the verification of distros that want to apply for inclusion in the free distro list. As part of my work on Replicant 11 (which is funded by NLnet) I also need to find and remove nonfree software, and I was also pointed to automatic tools to detect licenses (ScanCode and Ruby Licensee) by someone working at the FSFE, and I want to try them. There's also Fossology. I think that there is still a lot of subjectivity in some corner cases, but I completely agree with your conclusion as it would make no sense to decide that per-distribution or even per contributor. Instead having different people discuss the corner cases could help us come to better conclusions and we'd probably all learn in the process as well and become better at it. Indeed. Hopefully, smoothing the collaboration process will help to learn from each other and align subjectivity when it arises. My 2 cents. Regards, Sam
Re: [GNU-linux-libre] is this work-group still serving the community?
On 10/31/21 18:03, bill-auger wrote: rather than each distro repeating the same auditing work and deciding for itself what "libre" means; it would be more efficient if a collaborative team audited contentious software for all distros, and presented the results to the FSF for the final decision, binding upon all distros - IMHO, it would be more respectable as well; because it demonstrates a base-line consensus among the FSDG distros, regarding the minimal liberation procedures thats not to mention, that these are among the grunt-work for any distro - its not the fun or sexy stuff that any dev perfers to spend time on - people should be eager to pool their efforts on these boring administrative chores I agree, this seems like a more efficient way of doing things. I am not sure that FSDG, as it is today, allows this to happen in an objective manner. i believe that most FSDG issues are purely objective questions with clear answers and solutions, requiring no re-interpretation of the FSDG; so any conflicting interpretation would be easily proven erroneous eg: which licenses? which files do each license apply to? are these two licenses compatible? in most cases, there should be no disagreement about such obvious properties This would be great, though even the licenses can be vague enough that it becomes hard to decide, even from the legal point of view, whether they are free, or whether they are compatible, and then I don't see why FSF's legal opinion should be taken over some other competent legal opinion. But this aside, FSDG has really problematic parts: problematic for the program envisioned above. > A free system distribution must not steer users towards obtaining any > non-free information for practical use, or encourage them to do so. The > system should have no repositories for non-free software and no > specific recipes for installation of particular non-free programs. Nor > should the distribution refer to third-party repositories that are not > committed to only including free software; even if they only have free > software today, that may not be true tomorrow. Programs in the system > should not suggest installing non-free plugins, documentation, and so > on. > > For instance, a free system distribution must not contain browsers > that implement EME, the browser functionality designed to load DRM > modules. These are the clauses which were/are instrumental for arguments against including things like Firefox (includes a catalog of addons, some of which are non-free) or Debian-style kernels (load non-free firmware blobs if those are present). There are several tacit assumptions here which I would like to challenge. First one is the assumption that it's the job of the Operating System or the Distribution as a whole to determine whether every piece of software out there is free or non-free. As distro maintainers, we already spend resources on trying to determine whether the software we include directly is free or non-free. And if a piece of software we included talks to a repository or a library of any kind, or merely mentions it, FSDG implies we are now responsible for vetting that repo, continuously. And if that repo is itself an aggregate of some other sources, we have to vet those sources too. Couple it with the fact that nearly every complicated piece of software these days will have at least one community repository of auxiliary code, or plugins, or what have you, and now the distro maintainers end up combing the entire software ecosystem: free and the fringes of non-free, to figure out if any one of literally thousands of separate free software packages can be seen as "steering" towards non-free resources, of which there must be millions now. I believe this assumption should be regarded as wrong, for practical reasons, and that the responsibility sits with the user of a free-and-libre Distribution to vet the packages they get from the Net. From the point of view of distro maintainers, there is no practical way of protecting a user from himself, when that user refuses to be responsible for vetting his own software sources. Only appropriate legislation can protect such users, and only to some extent. ** ** ** ** ** ** Another assumption FSDG makes, a stronger one, even, is that "steering" or even "referring" a user toward non-free sources is bad/unacceptable. I believe that forbidding such references amounts to censorship, and is a worse outcome than just letting the user accept the responsibility. A free distribution user may have a legitimate and ethical interest in both using and studying non-free software for a variety of reasons and in a number of ways. Some non-free software is open-source, and can be effectively studied in detail. Binary blobs can be studied with the intent of reverse-engineering them. To take one particular example, Firefox' implementation of EME can and should be studied in order to actually conclude that it implements
