[GNU-linux-libre] Chromium, ungoogled or otherwise, and Guix
I decided to spend some time looking into Chromium, ungoogled-chromium, and Guix's methods, and the GNU FSDG. Even if vanilla Chromium does check out to be 100% free software it's already pretty easy to tell that it wouldn't be FSFG compliant, at least not out of the box. One is because of add-ons. It has a similiar problem to Firefox where people get sent to a place with both free and proprietary add-ons. Another is the support Widevine DRM, which seems to go against "the distro must contain no DRM..." in the FSDG. Thirdly, Chromium appears to ship with binaries in the source tree (the ungoogled-chromium README mentions that they "strip binaries from the source tree, and use those provided by the system or build them from source".) This seems the appropriate thing to do for FSDG compliance, since "all information for practical use in a free distribution must be available in source form." The source tree of a program shouldn't itself come with binaries, IMO, only source code. My proposal would be to mention these items in the chromium-browser entry on the libreplanet wiki either in addition to or in place of the current references of licensing problems that the wiki page has. Since some issues need fixing in Chromium regardless before an FSF- endorsed distro could ship it I then turned my attention to ungoogled- chromium to see if it could be a potential fix for those things. They do seem to disable the webstore URLs so the add-on problem seems fixed and stripping out binaries from the source tree seems to fix the third problem, but they don't appear to remove the Widevine DRM. As long as that remains the case it would seem that ungoogled-chromium is also not suitable for inclusion in FSF-endorsed distros, at least not out of the box. Since Guix has added ungoogled-chromium, without seemingly have changed it to also tackle the DRM portion, I have reported this to their bug tracker. I'm waiting to receive the bug number. The last item seems specific to Guix: Their method of building seems to involve downloading Chromium, then runnning ungoogled-chromium over it, and then building. That would mean, if someone wanted to build it on Guix themselves, that they'd also be going through those same steps. I don't know that FSF- endorsed distros should be having their users download non-FSDG compliant software in order to build them, even if its patched and modified during the build process. When LibreWRT was founded in 2010 (before it later merged into libreCMC) we submitted a similiar question to the FSF, as to if it was sufficient for the LibreWRT build scripts (which would be run by the person building the firmware image from source, just like how someone might instruct Guix to build from source) to download Linux and then run the Linux-libre deblobbing scripts on it vs having the build scripts instead download tarballs that were already cleaned up. I can't seem to find the email from back then but the response was that we needed to use already cleaned-up tarballs. Guix should do something similar. signature.asc Description: This is a digitally signed message part
Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.
18.02.2019, 14:44, "Tobias Geerinckx-Rice" : > If this is the quality of argument that ‘won’ over PureOS, it's > blaming Guix/Ricardo for not being around to stop others from > being bullied. > > Kind regards, > > T G-R Hi Tobias, I've been reading this conversation from the outside but noticed it seems to be shifting to a meta rather than about the state of chromium itself so it would be nice if it went back on topic. Seeing as the issue here relates to being uncertain shouldn't upstream confirm which parts run under what license in more detail? As I can tell so far this hasn't been done (unless I've missed something) thus the current situation. So the choice here is really about following the FSDG for now until it's revised or going against it causing a split in the community around it. Guix would be in the right but depending on the result there's a chance for a negative return (or a positive one). Are most here sure which direction it will go? From just reading the snippets about PureOS they seemed to have gotten quite a bit of flack until it was removed, won't the same happen to Guix? I've enjoyed using Guix for a bit over a year now and will continue regardless of the outcome. I apologize if this email is in conflict with the standard format as I usually don't engage in responding to mailing lists so my interpretation of the desired style might not be as accurate as of yet. Thank you Simon Nielsen
Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.
bill-auger wrote: On Sun, 17 Feb 2019 23:33:06 +0100 Ricardo wrote: I don’t feel motivated to apologize to the people involved in PureOS because I wasn’t around when they were pressured / convinced to drop Chromium. no, but you could have been around - you also could have argued for pureos on their side of the debate, and perhaps won favor for chromium at that time; so that none of us would need to be discussing it today, nor ever again - but unfortunately, it is true, you did not do that - so here we are today, raking this ugly old thing out of the mud once again If this is the quality of argument that ‘won’ over PureOS, it's blaming Guix/Ricardo for not being around to stop others from being bullied. Kind regards, T G-R
Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.
On Sat, 16 Feb 2019 12:16:41 +0100 Gábor Boskovits wrote: > It seems to me, that there is a whole bunch of people interested in > this, but due to lack of resources or for some other reasons nothing > is really happening. Do you know any we we could help getting this > resolved? This is a very good point. I also wonder if at the end, working to fix the problem by reviewing chromium source code more carefully would take less resources than discussing endlessly on how to deal with the fact that the source code hasn't been reviewed. Denis. pgpiN045HYdwh.pgp Description: OpenPGP digital signature
Re: [GNU-linux-libre] FSDG processes
Gábor Boskovits asked: > 1. If there is a free software, how do we ensure that it remains > free, or that it gets into the list of software with freedom issues? > Do we supervise each commit? My understanding is that each distro should be doing their own due diligence to only include FSDG-compliant free software but from what I read in the FSDG that doesn't necessarily have to be an "exhaustive" process. The FSDG has a part regarding that under "Commitment to Correct Mistakes": > Most distribution development teams don't have the resources to > exhaustively check that their distribution meet all these criteria. > Neither do we. So we expect distros to occasionally contain mistakes: > nonfree software that slipped through, etc. We don't reject a > distribution over mistakes. Our requirement is for the distribution > developers to have a firm commitment to promptly correct any mistakes > that are reported to them. > Do we have a central place, where freedom related bugs can be > reported? This mailing list is supposed to be a centralized place for discussion of things common to endorsed distros. Freedom issues should fall under there, unless it's something that is somehow exclusive to one distro. > 2. If there is a claim, that a given software has freedom issues, do > we accept that without any investigation? How do we protect ourselves > from a malicious actor faking these reports to hurt the reputation or > market share of a software? I don't think it would make any sense to do that. If someone reports that a freedom problem exists, and if it's not immediately obvious where the problem is, it seems perfectly reasonable to ask the person to point to the specific freedom problem that they're seeing. > On the contrary, if we get a report that the freedom issues don't > exist any more, then we have to investigate that? This is probably folded up into the distro's own due diligence that they should already be doing. > 3. If we have to investigate that a freedom issue does not exist any > more, how is that done? Where can we track the progress of such an > investigation? What is needed to take part in that? I imagine that depends on the scenario and if a distro using their own internal resources or if it's some sort of cross-distro collaboration. > 4. What does 'files with unclear licenses' mean? > > 5. There is a whole bunch of licenses listed as acceptable by FSDG, > including for example the 'modified BSD license', that do not mandate > to put anything your source file, just drop the LICENSE file in the > root folder of the project. The only thing I have seen why you would > include anything license related in your files, is that the licensing > remains clear in the case the file is copied out of the source tree. > It seems to me there is a contradiction here: there is a license > approved by the FSDG, but it is not approved at the same time, as > software gets rejected, stating that the license is unclear, however > the author did everything the license required. To me the only > resolution to this would be: > either to accept that files without the license notice, for licenses > that don't mandate their inclusion is really under the license; > or to declare all licenses not mandating the inclusion of a license > notice incompatible to the FSDG. What is your opinion on this? I'm combining 4 and 5 since they seem similar. Broadly-speaking there are two ways to handling copyright and licensing information with a free software project: File-scope notices and centralized notices. These are discussed more fully in [0]. My take is that whether a given program uses either method shouldn't have any bearing on being suitable for inclusion; because I see nothing in the GNU FSDG that would require distros to only include programs that use file-scope notices. Indeed, that would unnecessarily limit the number of free software programs available. For programs that use centralized notices that should apply to the entire program unless there is some notice to the contrary. So; a file without a license header isn't necessarily a problem. It needs to be evaluated within the context of that program (i.e., it might lack a license header because the project uses centralized notices.) Even programs like Linux-libre don't have copyright and licensing information inside each and every file. The standard in the kernel community is that things without specific license headers in the kernel are treated as being under the project's default license of GPLv2-only. [0] http://softwarefreedom.org/resources/2012/ManagingCopyrightInformat ion.html signature.asc Description: This is a digitally signed message part
Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.
On Sun, 17 Feb 2019 23:33:06 +0100 Ricardo wrote: > I don’t feel motivated to apologize to the people involved in PureOS > because I wasn’t around when they were pressured / convinced to drop > Chromium. no, but you could have been around - you also could have argued for pureos on their side of the debate, and perhaps won favor for chromium at that time; so that none of us would need to be discussing it today, nor ever again - but unfortunately, it is true, you did not do that - so here we are today, raking this ugly old thing out of the mud once again On Sun, 17 Feb 2019 23:33:06 +0100 Ricardo wrote: > In day to day Guix activities, we don’t ask developers of other > distros that also happen to subscribe to the FSDG to reach consensus > before making project decisions. of course every distro should have complete autonomy, especially for decisions that only pertain to that one distro - i am only considering the most fundamental decisions that obviously affect all distros equally, and reflect upon the integrity of the FSDG itself, such as which software is FSDG-free and which are not (and clarifying why or why not, and ideally, offering specific guidance for acceptably liberating the most common or troublesome ones) - if we can not all agree on that single most central concern to the FSDG, then what exactly is the value of the FSDG anyways? On Sun, 17 Feb 2019 23:33:06 +0100 Ricardo wrote: > You are suggesting that FSDG > distros form a community beyond the sense that they abide by the same > guidelines. I don’t think that’s reflecting reality. It’s another > thing to discuss if this should be so. yes - awesome!! - that is exactly what i have been proposing and working toward for a long time - in this case, not as just "another thing to discuss"; but it is *the* sole reason that i raised this issue with guix at this time (last september actually[1]) i have repeated it over and over again, that i couldnt care less about the chromium program, specifically - i want to discuss only and exactly this: enticing all FSDG distros to collaborate toward the achievement of common goals and solutions to common problems; as to avoid both redundant efforts and the presenting of conflicting philosophies to users, regarding the nature and essence of "free software" - the chromium program is not itself a fundamental problem, but one, albeit notorious, example of a common problem that affects all FSDG distros, and has been addressed by the group for the purpose of presenting a uniform message regarding it's FSDG status it would be a beautiful thing to have vigorous cross-distro collaboration as a focal point of the FSDG itself, very much in the collaborative spirit of GNU; and i think that most of the distros are already on board with that idea as a worthwhile plan, and have always been participating on the FSDG mailing list under that presumption - last year's re-structuring of the incoming distros community evaluation process was a concrete step in that direction "reality" is only what we make of it - if you see the FSDG as nothing more than a trophy or badge that you earned once upon a time, a milestone that need not be any concerned ever more after, then that is the reality you will have - the FSF does not want to mandate that anyone participate in the on-going group discussions; but it is a very good idea to show that the FSDG distros behave as a community of siblings by, at the very least, presenting a uniform stance on shared freedom issues On Sun, 17 Feb 2019 23:33:06 +0100 Ricardo wrote: > I see no violation of the FSDG here. that is not news, Ricardo - no one sees any obvious licensing violation of the FSDG; not today, nor a year ago, nor five years ago - if there were any known, they could have (and probably would have) been addressed long ago, and maybe we would not be discussing this now - the only clear FSDG problem today is the new one that guix is making for all other distros that are trying to be compliant with the FSDG as it is written, by intentionally doing something that is explicitly against the written recommendation - the "as it is written" part is perhaps dubious; but it is the keystone of a long-standing FSDG anomaly, and guix is in a very good position to help resolve that once and for all, for the benefit of all whether anyone likes it or not, adding chromium into any FSDG distro today, is in direct conflict with that pesky: "what is written" - the solution is almost certainly, that it needs to be re-written; but there is not yet anything to over-write it with - "i see no problem" is clearly not sufficient - we all know it has FSDG problems; and the current wording will remain until someone who cares about chromium offers a convincing liberation procedure to replace it as the FSDG recommendation we are asking for your help with this, for the benefit of all FSDG distros and their users, present and future, because it is only guix that claims to have any new information about
