Re: [GNU-linux-libre] Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines".
Hello, Richard Stallman writes: [...] > The Steel Sky license requires packaging a "larger & possibly commercial > software distribution" with it. That is not a trivial requirement. > > A trivial packaging requirement is ok because it is trivial. > A burdensome packaging requirement is not ok. > > Have I explained clearly? Yes, thank you! Best regards, Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: [GNU-linux-libre] Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines".
Hello, Richard Stallman writes: [...] > > ruben also suggested that such licenses are already deemed > > acceptable, referring to the precedent case of the OFL fonts > > license > > What is the license condition in question? What are its words? > That may be a topic I can resolve, given the facts. on June 14 [1] I added some details about the secific licensing terms, this is a renewed version of my previous message, sorry for the repetition. the note on the GNU license list on SIL OFL 1.1 [2] states: --8<---cut here---start->8--- The Open Font License (including its original release, version 1.0) is a free copyleft license for fonts. Its only unusual requirement is that when selling the font, you must redistribute it bundled with some software, rather than alone. Since a simple Hello World program will satisfy the requirement, it is harmless. --8<---cut here---end--->8--- this is the relevant text regardind the selling conditions in the SIL Open Font License 1.1 [3]: --8<---cut here---start->8--- 1) Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself. 2) Original or Modified Versions of the Font Software may be bundled, redistributed and/or sold with any software, provided that each copy contains the above copyright notice and this license. These can be included either as stand-alone text files, human-readable headers or in the appropriate machine-readable metadata fields within text or binary files as long as those fields can be easily viewed by the user. --8<---cut here---end--->8--- the relevant text from the game Beneath a Steel Sky v.1.2 [4] license (one of the games in scummVM extras source folder) is this: --8<---cut here---start->8--- 2) You may charge a reasonable copying fee for this archive, and may distribute it in aggregate as part of a larger & possibly commercial software distribution (such as a Linux distribution or magazine coverdisk). You must provide proper attribution and ensure this readme and all associated copyright notices, and disclaimers are left intact. 3) You may not charge a fee for the game itself. This includes reselling the game as an individual item. --8<---cut here---end--->8--- No doubt both are (very) poorly worded from a legal point of view but AFAIU the "Beneath a Steel Sky v.1.2" license have the same **legal** effect of the SIL OFL 1.1 Best regards, Giovanni. [1] message-id:87sfauff66@xelera.eu [2] https://www.gnu.org/licenses/license-list.html.en#SILOFL [3] https://directory.fsf.org/wiki/License:OFL-1.1 [4] https://sourceforge.net/projects/scummvm/files/extras/Beneath%20a%20Steel%20Sky/bass-cd-1.2.zip/download -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: [GNU-linux-libre] Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines"
Hi Denis, Denis 'GNUtoo' Carikli writes: [...] >> Guix is supposed to build everything from sources, right? > It usually does. People in guix-devel report already > pointed that the games was missing source code, so I added more infos > about that. > > I also made the case for packaging draci-historie or development tools > or removing ScummVM. thank you for your work! other people following this discussion may be interested in the details reported by Denis on guix-devel: https://lists.gnu.org/archive/html/guix-devel/2023-06/msg00072.html Happy hacking! -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: [GNU-linux-libre] Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines".
Hello, it's very hard to follow this very long thread so please forgive me if I miss something already discussed Ruben Rodriguez writes: > On 4/25/23 21:58, bill-auger wrote: >> yes, that the game engine is libre; but the games mentioned in the OP all >> have >> the "no-selling" license [...] > On the topic of the games with the "may distribute it in aggregate [...] > commercial software distribution", those are under a badly written but > sufficiently free license. This position is backed by this similar case: > > https://www.gnu.org/licenses/license-list.html#SILOFL > > SIL Open Font License 1.1 > "[...] when selling the font, you must redistribute it bundled with some > software, rather than alone. Since a simple Hello World program will > satisfy the requirement, it is harmless". The requirement is the same. I just want to add that the relevant text from SIL OFL 1.1 is this: --8<---cut here---start->8--- The OFL allows the licensed fonts to be used, studied, modified and redistributed freely as long as they are not sold by themselves. The fonts, including any derivative works, can be bundled, embedded, redistributed and/or sold with any software provided that any reserved names are not used by derivative works. --8<---cut here---end--->8--- while the relevant text from the game Beneath a Steel Sky v.1.2 license (one of the games in scummVM extras source folder) is this: --8<---cut here---start->8--- 2) You may charge a reasonable copying fee for this archive, and may distribute it in aggregate as part of a larger & possibly commercial software distribution (such as a Linux distribution or magazine coverdisk). You must provide proper attribution and ensure this readme and all associated copyright notices, and disclaimers are left intact. 3) You may not charge a fee for the game itself. This includes reselling the game as an individual item. --8<---cut here---end--->8--- No doubt both are (very) poorly worded from a legal point of view but AFAIU the "Beneath a Steel Sky v.1.2" license have the same **legal** effect of the SIL OFL 1.1 that is a free software license: you may not charge a fee (sell) the work by themselves but only included in a derivate work. Who is going to decice if a similar note as https://www.gnu.org/licenses/license-list.html.en#SILOFL should be added for the "Beneath a Steel Sky v.1.2 license" or better for all (non copyleft) licenses that substantially states "you may not sell the work by themselves but only included in a derivate work."? Thanks for the attention. Best regards, Giovanni. [1] https://sourceforge.net/projects/scummvm/files/extras/Beneath%20a%20Steel%20Sky/bass-cd-1.2.zip/download -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: [GNU-linux-libre] ungoogled chromium reported in Guix and unremoved after 8 months
my last message in this thread quil...@riseup.net writes: [...] > Unlicensed files in Chromium which were considered to be nonfree are still > there and has not been resolved you are talking about Chromium: facts about ungoogled-chromium in Guix, give us facts! since ungoogled-chromium was officially released in Guix there was a long discussion on gnu-linux-libre: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg9.html also: https://lists.gnu.org/archive/html/gnu-linux-libre/2019-02/msg00065.html please review the past threads and file new bug reports if some issue is still in **ungoogled-chromium from Guix** [...] Bye. Gio' -- Giovanni Biscuolo Xelera IT Infrastructures
Re: [GNU-linux-libre] ungoogled chromium reported in Guix and unremoved after 8 months
Jean Louis writes: [...] > After review of websites of Ludovic Courtès pleas do not bring your personal (or comunitarian, or from a very large group of people) campaign against Ludovic Courtès [1] in a discussion on the ungoogled-chromium in Guix Guix is not Ludovic Courtès nor each of the persons now maintaining it: Guix is a project, with many persons (I'm giving a tiny help) hard working to keep if compliant to the guidelines [...] > Hyperbola have different people in their rows. That is why they are > publishing profound analysis of problems with Chromium. If you see that any of the issues analyzed in the Hyperbola paper are still in ungoogled-chromium from Guix please file a bug report and refrain from personal attacks; before doing that please read the package definition of ungoogled-chromium (I've done it and I don't see any issue pointed by the Hyperbola paper there) Facts, Jean Louis: give us *facts* ;-) [...] Best regards. Gio' [1] https://gnu.support/richard-stallman/Ludovic-Court%C3%A8s-Guix-is-accusing-Stallman-of-Thoughtcrime-on-his-own-domain-GNU-org.html -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: [GNU-linux-libre] ungoogled chromium reported in Guix and unremoved after 8 months
Quiliro Ordóñez writes: [...] > This the bug report in Guix: > http://issues.guix.gnu.org/issue/34565 that bug report is about "ungoogled-chromium may contain Widevine DRM" it is implicit, but I *must* stress it, that this means "ungoogled-chromium Guix package" (the package definition is in Guile and is almost human readeable) this bug report was deeply analyzed by several Guix team members, I contributed a little bit (I am not a mainteiner of Guix), and now it's closed since ungoogled-chromium distributed as part of Guix does *not* contain Widevine DRM there are other bug reports about ungoogled-chromium in Guix: https://debbugs.gnu.org/cgi/pkgreport.cgi?archive=both;include=subject%3Achromium;package=Guix and all DFSG related ones was addressed in a timely manner > This is the analysis of Chromium Ungoogled and Chromium by Hyperbola: > https://wiki.hyperbola.info/doku.php?id=en:main:chromiums_freedom_flaws Interesting analysis, I'm almost sure all the issues pointed in that analisys are _well_ addressed in ungoogled-chromium from Guix, if you or any other person find some *specific* issue in that package please file a proper bug report via bug-g...@gnu.org AFAIK all Guix mainainers are working hard to keep Guix FSDG compliant, if you want to help please point to *specific* issues > I would like the FSF to take a stance on this immediately. I think a > week is more than enough, considering that this issue has been analyzed > before. I feel that a distro that has a freedom critical bug should not > take such a long time delay to correct it. You are wrong, http://issues.guix.gnu.org/issue/34565 is not a freedom critical bug Neither this https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34605 [...] HTH! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.
Hello all, I really appreciate the efforts of everyone involved in checking possible FSDG issues in Guix ungoogled-chromium, seriuosly anyway I find this thread is way too long to be useful in addressing FSDG issues in that package, so they can be **tacked** and **referenced** properly I humbly invite anyone finding _specific_ issues to file a bug to bug-g...@gnu.org, as I did myself here http://issues.guix.info/issue/34605 (forwarding one behalf of Luke report) this will be my last message in this thread Marius Bakke writes: [...] >> ;; Note: https://www.fsf.org/licensing/h264-patent-license: >> "use_openh264=false" >> "rtc_use_h264=false" > > I'm not an expert, so I'll defer judgement on this topic to someone more > knowledgeable. My understanding is that the OpenH264 library in use is > sufficiently free. Is that incorrect? disclaimer: I'm not an expert and not at all knowledgeable :-) but there's no need for an expert here: the link in the above note substantially explains that H264 [1] is patent encumbered (thus not patent-free), anyway GNU FSDG clearly states https://www.gnu.org/distros/free-system-distribution-guidelines.en.html#patents --8<---cut here---start->8--- we don't generally ask free system distributions to exclude software because of possible threats from patents. --8<---cut here---end--->8--- nonetheless, OpenH264 is free software, so I don't see any FSDG issue in distributing it all above said, I do not see FSDG issues in using H264 HTH! Giovanni P.S.: I'm _not_ implying that patents are not a seriuos issue, but that discussion is OT here :-S [1] sorry to note the onviuos: it's a video compression format, not a software (the software is OpenH264) -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.
Hello Luke, I'm replying _only_ about the DRM issue you reported please consider there is an opened bug for this issue: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34565 for specific issues about DRM in Guix ungoogled-chromium package please comment that bug including 34...@debbugs.gnu.org ...at least until is still open :-) I'm not including 34...@debbugs.gnu.org because IMHO all your concerns are well addressed in the bug report thread Luke writes: [...] > Correct me if I'm wrong, but Widevine DRM and the ability to run > proprietary codecs is still being built according to the provided > package source? no > That's definitely a blocker. > > While completely removing the DRM ability and creating a clean source > tarball is optimal, it should at minimum be disabled at compile time to > protect users. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34565#58 --8<---cut here---start->8--- For DRM to work, the user has to build with "enable_widevine=true", and then somehow obtain 'libwidevinecdm.so' and make the browser use it. --8<---cut here---end--->8--- this means that DRM *is* disabled at compile time and _also_ that libwidevinecdm.so is not included in Guix ungoogled-chromium source [...] Thanks! Giovanni -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: [GNU-linux-libre] question about GNU FSDG compliance process
ted as it could be - it has > been discussed how it could be refined and expanded to be a prime > resource to anyone who wishes to customize one of those programs - if > done well, there no reason why it should not be mandatory IMHO; I strongly disagree, but who am I to tell?!? :-) [...] > the bottom line is that all this work is done by volunteers, including > the review of new distros - in order to do a better job or to do more, > more volunteers are needed to review software, discuss issues, and > document the results just to be clear: each and every volunteer helping pointing out FSDG related issues deserves our gratest gratitude, seriously ...just please be precise when reporting FSDG issues, like suggested here: https://www.gnu.org/help/gnu-bucks.en.html (Detailed instructions) thanks for listening! Giovanni [1] http://lists.nongnu.org/archive/html/gnu-linux-libre/2019-02/msg00028.html -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: [GNU-linux-libre] Chromium, ungoogled or otherwise, and Guix
Hello Jason, Jason Self writes: > On Tue, 2019-02-19 at 17:18 +0100, Giovanni Biscuolo wrote: >> do you have the bug number now? > > 34565 > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34565 thank you for the reference! for all Guix ungoogled-chromium package DRM I'll continue on that bug report thread [...] -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: [GNU-linux-libre] Chromium, ungoogled or otherwise, and Guix
Hello Jason, Jason Self writes: [...] > 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. I agree: please someone involved https://libreplanet.org/wiki/Group:FreedSoftware could complete the info for chromium on https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines#chromium-browser ? I find https://directory.fsf.org/wiki/Review:Chromium-REV-ID-1 also very useful [...] > 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, in Guix ungoogled-chromium, Widevine is disabled at build time: http://issues.guix.info/issue/28004#2 http://issues.guix.info/issue/28004#87 > I have reported this to their bug tracker. I'm waiting to receive the > bug number. do you have the bug number now? > 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. in order to distribute the Linux-libre kernel developers have to download a non-FSDG Linux kernel... or they have to download a stripped-source-version?... and who is entitled to download a non-stripped version so he can distribute a stripped-version? > 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. please find that reference, this should be clarified once and for all (if it's not already documented on some FSF or libreplanet page) Thanks! Giovanni -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
[GNU-linux-libre] question about GNU FSDG compliance process
Hello licensing team and gnu-linux-libre,
first: thank you all for your commitment!
please I have some questions and some comment on the subject
I'm following the guix-de...@gnu.org mailing list (I'm not a maintainer)
and in this thread
http://lists.nongnu.org/archive/html/gnu-linux-libre/2019-02/msg0.html
there was some controversy on the inclusion of a patched chromium
version in Guix [1]
questions arosed in this discussion are not specific to Guix nor to
chromium but - in my view - involves the entire compliance process and
periodic reviev
in particular Bill Auger in this message
http://lists.nongnu.org/archive/html/gnu-linux-libre/2019-02/msg00028.html
wrote some interesting comments:
bill-auger writes:
[...]
> about a year ago, the FSDG review process and criteria for endorsement
> of new distros
AFAIK documented in this page:
https://libreplanet.org/wiki/Incoming_distros
shouldn't that page be linked in the official GNU FSDG Guidelines page
[2] so that the endorsement process is clear to everyone reading the
Guidelines?
I already knew GNU FSDG Guidelines page but I was not aware of "Incoming
distros" page since Saturday
> was updated - the new FSDG criteria checklist
for reference [3]
> for community review that was adopted includes the following essential
> criteria:
>
> "Programs commonly known to have freedom issues are liberated or
> excluded"
the "Sample Checklist" section on [3] states:
"[...] The text of each criteria in the checklist table is a hyper-link
to the relevant section of the FSDG. [...]"
but that is not true, since the criteria cited above ("Programs commonly
known to have...") links to a resource _outside_ the official GNU FSDG,
**extending** it with a new criteria
my question is: is that "Software blacklist" [4] a mandatory criteria
for GNU FSDG?
if it has to be a criteria, shouldn't be better to update the official
GNU FSDG page?
my opinion is that the "Software blacklist" [4] is a valuable *tool*
for evaluators but should _not_ be considered as part of GNU FSDG itself
> that criteria is a link to the "software that does not respect the
> FSDG" wiki page, which includes an entry for 'chromium-browser' (the
> debian package name) with the liberation procedure being specified as:
>
> "Remove program/package Use GNU IceCat, or equivalent"
if the "Software blacklist" is to be considered mandatory, then every
distro including a blacklisted entry should be considered "non
compliant"
IMHO the evaluation process should be more articulated than a check on a
blacklist; the case of "ungoogled-chrome in Guix" is a nice example of
the shortcoming of this approach
actually the FSDG Reviev Guide [5] clearly states:
--8<---cut here---start->8---
You can do a similar check to see if any of the packages listed on the
List of software that does not respect the Free System Distribution
Guidelines are included in the distribution. Don't assume that there's a
problem just because the distribution includes a package named on that
page, though: a lot of the entries suggest solutions that help the
software comply with the guidelines without removing it
completely. You'll have to check yourself to see whether or not the free
distribution has taken those steps. Usually, that's as simple as
comparing version numbers.
--8<---cut here---end--->8---
so IMHO including "Software blacklist" [4] in the checklist [3] is
in direct contradiction with the above statement
> that created an uncomfortable pressure point for any distro that wants
> to distribute this browser - according to the literal reading of that
> criteria,
the question is precisely this: should the "Software blacklist" [4] be
"literally read"?
[...]
> it was also agreed upon at that time, that the FSDG criteria should be
> applicable to all currently endorsed distros in perpetuity, so ...
so, again: is really "Software blacklist" an FSDG criteria?
[...]
> if chromium enters the guix repo it will almost surely be followed by a
> freedom bug report (which per the current FSDG criteria, would be fully
> justifiable)
i feel some clarification in gnu-linux-libre is needed on this process
and on the status of "Software blacklist" [4] page
[...]
thanks for listening!
Giovanni
P.S.: please consider that this interesting summary on
chromium status: https://directory.fsf.org/wiki/Review:Chromium-REV-ID-1
is not referenced in [4] while IMHO it should be
[1] this is the specific Guix issue http://issues.guix.info/issue/28004
[2] https://www.gnu.org/distros/free-system-distribution-guidelines.en.html
[3] https://libreplanet.org/wiki/Temp
