Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

2019-02-19 Thread Donald Robertson



On 2/16/19 2:47 PM, Adonay Felipe Nogueira wrote:
[snip]
> 
> As I said in a message to these mailing lists, I already started
> reviewing Chromium, although this project is big and I might not have
> the time nor all the skills to do it alone. Since today, I moved the
> review, which was available at [1], to the appropriate Review namespace
> at [2].
> 


Thank you for taking the time to do this review. The system we've set up
relies on the whole community to do the checking. It is not possible for
the distros (even aided by this mailing list), to review everything
exhaustively. Instead, we rely on reports that specify what the exact
freedom issue is. Obviously we can take it upon ourselves to sometimes
conduct these reviews, but we encourage everyone to participate by
filing bugs when they come across things
.
-- 
Donald R. Robertson, III, J.D.
Licensing & Compliance Manager
Free Software Foundation
51 Franklin Street, Fifth Floor
Boston, MA 02110
Phone +1-617-542-5942
Fax +1-617-542-2652 ex. 56



Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

2019-02-19 Thread Donald Robertson



On 2/16/19 8:39 PM, bill-auger wrote:
> On Sat, 16 Feb 2019 14:06:43 -0600 Brett wrote:
>> I think you can probably go ahead and push that patch
>> Bill,  What do you think here?
> 
> i think that would be intentionally creating exactly the same
> unpleasant situation as the pureos bug report that stood for many
> months, unaddressed
> 
> i think that IF this is the proper course of action, then we
> should apologize to pureos for asking them to remove it last year
> 
> but let me rephrase that more plainly:
> 
> if we do not FIRSTLY apologize to pureos for asking them to remove
> chromium and publicly endorse them to re-instate it, then endorsing it
> into guix would be hypocritical and shameful
> 
> 

>From this thread it seems like there were some legitimate issues that
the people at Guix have now addressed. Isn't this more a situation of
possibly changed circumstances?
-- 
Donald R. Robertson, III, J.D.
Licensing & Compliance Manager
Free Software Foundation
51 Franklin Street, Fifth Floor
Boston, MA 02110
Phone +1-617-542-5942
Fax +1-617-542-2652 ex. 56



Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

2019-02-19 Thread Donald Robertson



On 2/16/19 2:29 PM, Amin Bandali wrote:
>> I’ve attached a gzipped version of the above text file.
> 
> Sorry, hit send too soon.  I’ve attached it to this message.
> 

I just want to clarify something here. Not having proper license and
copyright headers on files within a project is not a bar to that program
being free software. If it was, we'd have to remove something on the
order of 80% of the Free Software Directory. It's obviously bad
practice, as it can create confusion, particularly if those files get
separated from the project. So we want people to fix that. But the
reality is that almost all the tickets I file with projects are about
missing headers because very few projects do it 100%.

If that's all we're seeing, then that in itself is not an issue in terms
of whether it can be in a fully free GNU/linux distro.


-- 
Donald R. Robertson, III, J.D.
Licensing & Compliance Manager
Free Software Foundation
51 Franklin Street, Fifth Floor
Boston, MA 02110
Phone +1-617-542-5942
Fax +1-617-542-2652 ex. 56



Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

2019-02-19 Thread Donald Robertson



On 2/17/19 9:06 AM, Julie Marchant wrote:
[snip]
> 
>> most importantly, i personally dont care to argue for nor against
>> chromium - i just want all FSDG distros to agree on how it should be
>> treated, regardless of what that entails
> 
> Why? Are you opposed to individual distros making their own individual
> decisions?
> 

Distros have to make decisions all the time about what software to
include, and we don't want to interfere with that. The system as it is
set up is such that the distros promise to respond to reports of freedom
issues and fix them when the report is valid.

We can obviously all work together to tag issues (as we've done here
).
But as noted before, some items on that list might not be up to date,
and obviously if someone has taken the time to address the issues then
we need to see about updating to reflect new possible fixes. Updating
that list involves discussion here on the mailing list and likely
approval from RMS as well.

Something being on the list isn't an automatic ban for a distro wanting
to include it. You can view it as an initial nonfree report that needs
to be addressed.

But if at the end of the day, something is determined to not meet the
guidelines, then that will have to be removed, or the distro can't
maintain it's promise. So no endorsed distros will be able to make a
different decision, though obviously as members of the list they are
involved in making that determination.

-- 
Donald R. Robertson, III, J.D.
Licensing & Compliance Manager
Free Software Foundation
51 Franklin Street, Fifth Floor
Boston, MA 02110
Phone +1-617-542-5942
Fax +1-617-542-2652 ex. 56



Re: [GNU-linux-libre] Chromium, ungoogled or otherwise, and Guix

2019-02-19 Thread Jason Self
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

It seems to be disabled at build time only.

signature.asc
Description: This is a digitally signed message part


Re: [GNU-linux-libre] question about GNU FSDG compliance process

2019-02-19 Thread bill-auger
Giovanni -

the first thing i would wat to say is that no one wants to refer to
that list as a "Software blacklist"

a blacklist implies that something is to be shunned, and permanently
so - the main point of that list is not only to point out programs that
have known problems, but more importantly to offer known recipes for how
they can be liberated and used in freedom - so, i prefer to call it a
"rescue" list; rather than giving it the "wall of shame" treatment
that the original title suggests - chromium is an unfortunate example
of one that has no known liberation procedure - no one wants it to
remain that way

regarding how mandatory it is, i think thats mostly up in the air for
the moment - only the FSF could clarify that authoritatively

what is clear though is that the current wording of the review process
prevents any new distro from passing beyond the community review stage
if it distributes chromium; so it is at least, effectively mandatory for
new incoming distros - i think we would all want to see all FSDG rules
applied equally to all FSDG distros, present and future - it is very
unsettling, embarrassing even, if distros contradict each other
regarding what is FSDG-free and what is not - i do think this is among
the highest priorities for the group, especially now that this potential
for conflict has been instantiated with an example

as for the list itself, it is actually relatively short today compared
to what it could be, and is not as well curated 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; but it
would need to be well maintained, to ensure the warnings and
prescriptions for each program remain relevant and useful

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



Re: [GNU-linux-libre] Chromium, ungoogled or otherwise, and Guix

2019-02-19 Thread bill-auger
On Tue, 19 Feb 2019 17:18:19 +0100 Giovanni wrote:
> 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 think that for all intents and purposes, this mailing list is exactly
that "Group:FreedSoftware"

the essential issue here (and it is THE central issue), is that there
is not yet anything "complete" to change it too - "un-google it" is
not complete - we need a proper recipe, declaring both the problems and
the solutions, for all known problems and solutions - once that
information exists, we would want to discuss it; then upon a consensus
that it is a satisfiable solution, someone can make that edit

i dont think we are anywhere near "complete" yet - we have scantly more
information today than a year ago, when it was concluded that the
"ungoogled" treatment would be necessary but not sufficient


> do you have the bug number now?

i could not find it - the "newest bugs" filter seems to be broken

https://debbugs.gnu.org/cgi/pkgreport.cgi?newest=guix


On Tue, 19 Feb 2019 17:18:19 +0100 Giovanni wrote:
> 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?

we discussed this on IRC today

firstly, the FSF does make a distinction between the software
developers and technicians may use for the sole purpose of liberating
software and hardware, and the software get re-distributed to users

but the key difference with that anology, practically speaking, is that
is linux-libre is not a distro - this rule we are discussing is from the
FSDG which applies to distros

now for the sake of this argument, guix is a project, but guixsd is a
distro - so that analogy could perhaps be pertinent to the guix package
manager as a distinct project; but guixsd, the distro, has promised to
follow the FSDG



Re: [GNU-linux-libre] Chromium, ungoogled or otherwise, and Guix

2019-02-19 Thread Giovanni Biscuolo
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

2019-02-19 Thread Giovanni Biscuolo
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/Template:FSDG_Checklist

[4] https://libreplanet.org/wiki/Group:FreedSoftware#Related_pages
"Software blacklist" redirects to
https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines

[5] https://libreplanet.org/wiki/FSDG_Review_Guide

-- 
Giovanni