GNU bug report logs - #34565
ungoogled-chromium may contain Widevine DRM

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34565 in the body.
You can then email your comments to 34565 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jason Self <j <at> jxself.org>
To: submit <at> debbugs.gnu.org
Subject: ungoogled-chromium contains Widevine DRM
Date: Mon, 18 Feb 2019 19:44:57 -0800

Package: guix

Unless I am mistaken, ungoogled-chromium is not removing Widevine DRM
from upstream Chromium. Guix should remove that if upstream won't, as I
believe this goes against "the distro must contain no DRM..." in the
FSDG.

Message #8 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Jason Self <j <at> jxself.org>
Cc: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Tue, 19 Feb 2019 02:06:01 -0500

[Message part 1 (text/plain, inline)]

On Mon, Feb 18, 2019 at 07:44:57PM -0800, Jason Self wrote:
> Unless I am mistaken, ungoogled-chromium is not removing Widevine DRM
> from upstream Chromium. Guix should remove that if upstream won't, as I
> believe this goes against "the distro must contain no DRM..." in the
> FSDG.

Why do you think this is the case? It doesn't work for me on any of the
Widevine demos I can find, unlike an installation of Google Chrome.

[signature.asc (application/pgp-signature, inline)]

Message #11 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Jason Self <j <at> jxself.org>
To: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Tue, 19 Feb 2019 05:28:26 -0800

[Message part 1 (text/plain, inline)]

On Tue, 2019-02-19 at 02:06 -0500, Leo Famulari wrote:
Why do you think this is the case?

We know Chromium comes with it. Have you looked through ungoogled-
chromium to see where it's being deleted?

[signature.asc (application/pgp-signature, inline)]

Message #14 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Julien Lepiller <julien <at> lepiller.eu>
To: Jason Self <j <at> jxself.org>
Cc: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Tue, 19 Feb 2019 14:42:42 +0100

Le 2019-02-19 14:28, Jason Self a écrit :
> On Tue, 2019-02-19 at 02:06 -0500, Leo Famulari wrote:
> Why do you think this is the case?
> 
> We know Chromium comes with it. Have you looked through ungoogled-
> chromium to see where it's being deleted?

Our package definition has two widevine-related headers listed as
preserved third-party stuff... I'm not sure how widevine normally
gets into chromium, but if we don't have it, I guess we should
not need these headers? There might actually be an issue, but
I'm not sure how to check. Where is widevine in upstream (non
ungoogled) chromium? Is it downloaded at runtime?

IIUC, the rest of this widevine directory is removed before
building anything, so maybe there's nothing to worry about
after all?

Message #17 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Jason Self <j <at> jxself.org>
Cc: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Tue, 19 Feb 2019 09:43:42 -0500

[Message part 1 (text/plain, inline)]

On Tue, Feb 19, 2019 at 05:28:26AM -0800, Jason Self wrote:
> We know Chromium comes with it. Have you looked through ungoogled-
> chromium to see where it's being deleted?

Please show us the paths in our package's source code. We need to remove
it if it is there.

I looked and cannot find it.

I looked at how some other distros do it.

They get the Widevine binaries by extracting them from a download of the
Google Chrome browser, which is not the browser that has been packaged
for Guix.

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Julien Lepiller <julien <at> lepiller.eu>
To: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Tue, 19 Feb 2019 15:44:17 +0100

Le 2019-02-19 14:42, Julien Lepiller a écrit :
> Le 2019-02-19 14:28, Jason Self a écrit :
>> On Tue, 2019-02-19 at 02:06 -0500, Leo Famulari wrote:
>> Why do you think this is the case?
>> 
>> We know Chromium comes with it. Have you looked through ungoogled-
>> chromium to see where it's being deleted?
> 
> Our package definition has two widevine-related headers listed as
> preserved third-party stuff... I'm not sure how widevine normally
> gets into chromium, but if we don't have it, I guess we should
> not need these headers? There might actually be an issue, but
> I'm not sure how to check. Where is widevine in upstream (non
> ungoogled) chromium? Is it downloaded at runtime?
> 
> IIUC, the rest of this widevine directory is removed before
> building anything, so maybe there's nothing to worry about
> after all?

So I've downloaded the source tarball with `guix build -S chromium`
and here's what I found in it:

$ find -name cdm
./media/cdm
./third_party/widevine/cdm
./chrome/android/java/src/org/chromium/chrome/browser/media/cdm
./chrome/browser/media/android/cdm
./content/renderer/media/cdm
./chromecast/media/cdm
./components/cdm

$ find -name widevine
./third_party/widevine

$ find -name '*widevine*'
./third_party/widevine
./third_party/widevine/cdm/android/widevine_cdm_version.h
./third_party/widevine/cdm/widevinecdmadapter.ver
./third_party/widevine/cdm/stub/widevine_cdm_version.h
./third_party/widevine/cdm/widevine.gni
./third_party/widevine/cdm/widevine_cdm_version.h
./third_party/widevine/cdm/widevine_cdm_common.h
./chrome/common/widevine_cdm_constants.h
./chrome/common/widevine_cdm_constants.cc
./chrome/browser/component_updater/widevine_cdm_component_installer.cc
./chrome/browser/component_updater/widevine_cdm_component_installer.h
./components/cdm/common/widevine_drm_delegate_android.cc
./components/cdm/common/widevine_drm_delegate_android.h
./components/cdm/renderer/widevine_key_system_properties.cc
./components/cdm/renderer/widevine_key_system_properties.h


This 
./chrome/browser/component_updater/widevine_cdm_component_installer.cc
looks particularly suspicious to me...

Now, it seems that widevine stuff only gets built when the 
ENABLE_WIDEVINE
option is set, and it doesn't seem to be the case in guix' package. 
Since
I don't understand how the browser gets built, so I'm not sure about the
default. In any case, it would be good to get rid of these files even
if they aren't built.

HTH!

Message #23 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Jason Self <j <at> jxself.org>
To: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Tue, 19 Feb 2019 16:39:12 -0800

[Message part 1 (text/plain, inline)]

Based on http://issues.guix.info/issue/28004#2 it is disabled at build
time; but not removed. The person said they thought this was FSDG
compliant but a reading of "the distro must contain no DRM" from the
FSDG could be taken to mean the distro still "contains" it, since it's
still within the source code of the program. "Disabled by default"
shouldn't be good enough IMHO; build flags should not be used to hide
freedom problems. The source code represents what the software *is*,
not the build flags.

[signature.asc (application/pgp-signature, inline)]

Message #26 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Jason Self <j <at> jxself.org>
To: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Tue, 19 Feb 2019 17:12:17 -0800

[Message part 1 (text/plain, inline)]

A different but related matter is the build process itself. I
understand this is not exactly related to the DRM matter but it does
seem similiar. I can open another bug over this if needed. I have
recently submitted upstream's Chromium 73.0.3683.45 into my FOSSology
instance for analysis. Actually, less than a third of the total files
were classified as "BSD-like". In total it found 162 unique licenses.
Of course, automated licenses analysis is never perfect and I have not
fully vetted any particular results but it does help to at least
indicate that which is very clearly free software and that which needs
further investigation.

Even in the short time I was reviewing it I found a number of freedom
problems. I don't mean that to be an exhaustive list of everything,
merely an indicator of a symptom:

* unrar (license denies freedom 0)
* third_party/blink has some images under CC-BY-NC-SA-2.0
* Google Toolbar is in there, with a non-free EULA

Taking this and considering Guix's build process: The method of
building seems to involve downloading Chromium, then runnning
ungoogled-chromium over it, and then building. I'm not sure if any
other packages have their freedom problems fixed in this way but this,
just like build flags, should not be sufficient. Freedom problems
should not be hidden/removed after the fact by asking the user to run a
clean-up program after downloading the source, even if that has been
automated by the package manager. What is sent to the end user to
compile should itself be 100% free software and FSDG compliant from the
beginning. If not it still amounts to distributing non-free software to
the user when they want to, for example, do guix build -S chromium.

[signature.asc (application/pgp-signature, inline)]

Message #29 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Jason Self <j <at> jxself.org>
To: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Tue, 19 Feb 2019 17:19:47 -0800

[Message part 1 (text/plain, inline)]

> should not be hidden/removed after the fact by asking the user to run
> a clean-up program after downloading the source, even if that has
> been automated by the package manager. What is sent to the end user
> to compile should itself be 100% free software and FSDG compliant
> from the beginning. If not it still amounts to distributing non-free
> software to the user when they want to, for example, do guix build -S
> chromium.

I should probably add on that this position comes from my interaction
with the FSF in 2010: When LibreWRT was founded in 2010 (before it
later merged into libreCMC) we submitted a similar 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 and would
have completely automated, 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, not ask the user to clean up the software after
ward even if automated. So that was what we did. Guix should do
something similar.

[signature.asc (application/pgp-signature, inline)]

Message #32 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Jason Self <j <at> jxself.org>
Cc: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Wed, 20 Feb 2019 00:15:36 -0500

[Message part 1 (text/plain, inline)]

On Tue, Feb 19, 2019 at 05:12:17PM -0800, Jason Self wrote:
> Taking this and considering Guix's build process: The method of
> building seems to involve downloading Chromium, then runnning
> ungoogled-chromium over it, and then building. I'm not sure if any
> other packages have their freedom problems fixed in this way but this,
> just like build flags, should not be sufficient. Freedom problems
> should not be hidden/removed after the fact by asking the user to run a
> clean-up program after downloading the source, even if that has been
> automated by the package manager. What is sent to the end user to
> compile should itself be 100% free software and FSDG compliant from the
> beginning. If not it still amounts to distributing non-free software to
> the user when they want to, for example, do guix build -S chromium.

To clarify this general point about Guix for anyone who is reading
along, as a matter of policy the end user does not receive non-free
source code from Guix.

The tools provided by Guix to access source code only return source code
that is freely licensed. If the sources have to be modified to ensure
this, the unodified source code is not provided to the user. Guix is
specifically designed to do it this way.

[signature.asc (application/pgp-signature, inline)]

Message #37 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Jason Self <j <at> jxself.org>
To: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Tue, 19 Feb 2019 21:35:47 -0800

Leo Famulari wrote:
> To clarify this general point about Guix for anyone who is reading
> along, as a matter of policy the end user does not receive non-free
> source code from Guix.

Right; the source is downloaded from commondatastorage.googleapis.com
but that is a technicality. What I'm saying is that the recipe should
be updated to cause it to download an already-cleaned up version
directly from Guix (it could be hosted somewhere on gnu.org for example
but exactly where can be up for negotiation) and that this excuse of
"they're getting it elsewhere" shouldn't be usable as an excuse to
sidestep the FSDG. It's still causing the user to download the software
due to the recipes provided by Guix.

> The tools provided by Guix to access source code only return source
> code that is freely licensed. If the sources have to be modified to
> ensure this, the unodified source code is not provided to the user. 

It's still being downloaded into their computer and then being cleaned
up after the fact. If there weren't freedom problems with it there
wouldn't be a need for a clean-up program (ungoogled-chromium in this
case) to be running -- as a process on the user's computer -- to do
this.

And in https://www.gnu.org/distros/free-system-distribution-guidelines.
html we have:

"For instance, a free system distribution must not contain browsers that implement EME, the browser functionality designed to load DRM modules."

So that should make it quite clear.

Message #40 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Julien Lepiller <julien <at> lepiller.eu>
Cc: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Wed, 20 Feb 2019 00:42:19 -0500

[Message part 1 (text/plain, inline)]

On Tue, Feb 19, 2019 at 03:44:17PM +0100, Julien Lepiller wrote:
> So I've downloaded the source tarball with `guix build -S chromium`
> and here's what I found in it:

[...]

Thanks for taking a look, Julien!

We need to find out if Widevine DRM is actually included in the Guix
ungoogled-chromium package or not.

Obviously the intent was to not include it, and it does not work in
practice. Widevine videos do not play and there is no prompt to install
or enable DRM, unlike in some other browsers that use DRM.

I think the next steps for this subject are to first, in general, figure
out where Widevine comes from, and then, more specifically, decide what
to do about the files you mentioned. 

As I mentioned already, other distros seem to get Widevine by extracting
its binary from Chrome, even when using it for Chromium. It seems
reasonable to assume that if Widevine were included in Chromium they
would not be downloading a whole 'nother browser for that one component.

As for the specific files listed by Julien, they may be harmless, or
not, we should figure out what they do and if they need to be removed.

[signature.asc (application/pgp-signature, inline)]

Message #43 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Jason Self <j <at> jxself.org>
Cc: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium might contain remnants of Widevine
 DRM
Date: Wed, 20 Feb 2019 08:59:00 +0100

Jason Self <j <at> jxself.org> writes:

> Leo Famulari wrote:
>> To clarify this general point about Guix for anyone who is reading
>> along, as a matter of policy the end user does not receive non-free
>> source code from Guix.
>
> Right; the source is downloaded from commondatastorage.googleapis.com
> but that is a technicality. What I'm saying is that the recipe should
> be updated to cause it to download an already-cleaned up version
> directly from Guix (it could be hosted somewhere on gnu.org for example
> but exactly where can be up for negotiation) and that this excuse of
> "they're getting it elsewhere" shouldn't be usable as an excuse to
> sidestep the FSDG. It's still causing the user to download the software
> due to the recipes provided by Guix.

Please do not claim that Guix sidesteps or aims to sidestep the FSDG.
This is not the case as we are committed to abiding by the FSDG.

What users get when using “guix build --source” is the processed source
code from the Guix build farm.  The fallback is to fetch the original
sources directly and process them (which is what the build farm does as
well).

--
Ricardo

Message #46 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Giovanni Biscuolo <g <at> xelera.eu>
To: Leo Famulari <leo <at> famulari.name>
Cc: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Wed, 20 Feb 2019 10:22:19 +0100

[Message part 1 (text/plain, inline)]

Hello,

maybe Marius Bakke have something interesting to say about his
judgements on this "DRM matter"

indeed, this is a pretty ignorant (aka me) comment:

Leo Famulari <leo <at> famulari.name> writes:

[...]

> I think the next steps for this subject are to first, in general, figure
> out where Widevine comes from, and then, more specifically, decide what
> to do about the files you mentioned. 
>
> As I mentioned already, other distros seem to get Widevine by extracting
> its binary from Chrome, even when using it for Chromium. It seems
> reasonable to assume that if Widevine were included in Chromium they
> would not be downloading a whole 'nother browser for that one
> component.

ungoogle-chromium FAQs [1] confirms that in order to install Widevine
users have to download a shared object (libwidevinecdm.so) and install
it system wide in /usr/lib/chromium or in $HOME/.local/lib/

I tried to install ungoogled-chromium from Guix but failed (another
story...) so I cannot see myself, but AFAIU there is no way for a user
to enable Widevine from the user interface *nor* manually

I don't know if the libwidevinecdm.so user loading must be forbidden
**programmatically** [2] to be FSDG compliant: what is the case with the
linux-libre kernel? are users forbidden to "insmod proprietery_module"
they _independently_ downloded or developed?

anyway, as Julien Lepiller already verified (Guix package definition is
there for anyone to check, and checking is very easy), Widevine stuff
only gets built when the ENABLE_WIDEVINE build option is set... and it's
not this case, so it's unlikely that users will be able to install
Widevine even following the above mentioned procedure

last but not least: AFAIU ungoogled-chromium Guix package documentation
nor Guix Manual contains information on how to obtain proprierary
extensions to any software; am I wrong?

> As for the specific files listed by Julien, they may be harmless, or
> not, we should figure out what they do and if they need to be removed.

AFAIU that code allows dynamically linking Widevine (sorry cannot still
check myself), but it is _disabled_ at build time

is this enough to be FSDG compliant?

given all the above, it seems to me that ungoogled-chromium binaries
provided by Guix substitute servers _and_ sources provided by Guix build
farms (are provided by them, right?) does not ship with DRM enabled

to sum it up: AFAIU for users to be able to use Widevine they must
create a custom package definition _outside_ official Guix channels
*and* download the shared object "libwidevinecdm.so" from Chromium,
installing it "manually" system wide or locally

HTH!
Ciao
Giovanni


[1]
https://ungoogled-software.github.io/ungoogled-chromium-wiki/faq#how-do-i-install-widevine-cdm

[2] I mean by stripping away any bit of source code that allows users to
dynamically link potentially proprietary shared objects in the software

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[signature.asc (application/pgp-signature, inline)]

Message #49 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Jelle Licht <jlicht <at> fsfe.org>
To: Jason Self <j <at> jxself.org>
Cc: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Wed, 20 Feb 2019 11:09:20 +0100

Jason Self <j <at> jxself.org> writes:

> Leo Famulari wrote:
>> To clarify this general point about Guix for anyone who is reading
>> along, as a matter of policy the end user does not receive non-free
>> source code from Guix.
>
> Right; the source is downloaded from commondatastorage.googleapis.com
> but that is a technicality. What I'm saying is that the recipe should
> be updated to cause it to download an already-cleaned up version
> directly from Guix (it could be hosted somewhere on gnu.org for example
> but exactly where can be up for negotiation) and that this excuse of

I would argue that this way of thinking is one of the issues Guix and
the broader reproducible builds community is trying to solve (in an
ethical way). Practical software freedom also includes the possibility
of not being dependent on even the gnu.org infrastructure.

> "they're getting it elsewhere" shouldn't be usable as an excuse to
> sidestep the FSDG. It's still causing the user to download the software
> due to the recipes provided by Guix.

The implied tone of your message comes across as needlessly
aggressive. I am not sure if the GNU Kind Communications Guidelines
apply here, but I still urge you to give the broader Guix community the
benefit of the doubt in that they are committed to the FSDG and
everything it entails.

This is like arguing that curl could be used to download proprietary
software; An unmodified Guix will never present a user with non-free
software. If it does, this can be considered a bug and should be fixed
ASAP. Your proposal implies that someone else still downloads the
nonfree upstream sources to modify them, so I see this as even more of a
case of working around the spirit of the FSDG.

>
>> The tools provided by Guix to access source code only return source
>> code that is freely licensed. If the sources have to be modified to
>> ensure this, the unodified source code is not provided to the user.
>
> It's still being downloaded into their computer and then being cleaned
> up after the fact. If there weren't freedom problems with it there
> wouldn't be a need for a clean-up program (ungoogled-chromium in this
> case) to be running -- as a process on the user's computer -- to do
> this.

I do not really get the point you are trying to make, because the
software has to be downloaded at some point in time. Offering a
transparent solution in the form of the Guix store, where the
problematic bits of software only exist in a transient state seems like
it improves the situation across the board.

Whether this fits the letter of the FSDG is an interesting discussion to
be had, but arguing that it goes against the core principles is simply
silly :).

>
> And inhttps://www.gnu.org/distros/free-system-distribution-guidelines.
> htmlwe have:
>
> "For instance, a free system distribution must not contain browsers that implement EME, the browser functionality designed to load DRM modules."
>
> So that should make it quite clear.

I feel most folks here agree on this, at least, so if ungoogled-chromium
still implements a functioning EME, that is a bug.

Respectfully yours,
- Jelle

Message #52 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Jason Self <j <at> jxself.org>
To: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Wed, 20 Feb 2019 05:03:31 -0800

[Message part 1 (text/plain, inline)]

Jason Self wrote:
> I should probably add on that this position comes from my interaction
> with the FSF in 2010: When LibreWRT was founded in 2010 (before it
> later merged into libreCMC) we submitted a similar 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
> and would have completely automated, 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, not ask the user to clean up the
> software afterward even if automated. So that was what we did. Guix
> should do something similar.

I haven't been able to find this conversation in my email. As it seems
to be directly relevant to Guix, since it seems to also be the exact
same method they use, I have emailed the FSF asking if they can locate
this in their ticketing system and to re-send the conversation to me.
More to come.

[signature.asc (application/pgp-signature, inline)]

Message #55 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Jason Self <j <at> jxself.org>, 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Wed, 20 Feb 2019 15:37:15 +0100

[Message part 1 (text/plain, inline)]

Jason Self <j <at> jxself.org> writes:

> A different but related matter is the build process itself. I
> understand this is not exactly related to the DRM matter but it does
> seem similiar. I can open another bug over this if needed. I have
> recently submitted upstream's Chromium 73.0.3683.45 into my FOSSology
> instance for analysis. Actually, less than a third of the total files
> were classified as "BSD-like". In total it found 162 unique licenses.
> Of course, automated licenses analysis is never perfect and I have not
> fully vetted any particular results but it does help to at least
> indicate that which is very clearly free software and that which needs
> further investigation.

To avoid duplicate work, it would be useful if you ran this analysis on
the tarball produced by `guix build --source ungoogled-chromium`.

> Even in the short time I was reviewing it I found a number of freedom
> problems. I don't mean that to be an exhaustive list of everything,
> merely an indicator of a symptom:
>
> * unrar (license denies freedom 0)

UnRAR is not present in the Guix source.

> * third_party/blink has some images under CC-BY-NC-SA-2.0

I cannot find these images: grepping for CC-BY-NC-SA or 'Creative
Commons' did not aid.  Did you record the absolute paths to these files?

> * Google Toolbar is in there, with a non-free EULA

My grep-fu is really failing me today.  Where is this located?

> Taking this and considering Guix's build process: The method of
> building seems to involve downloading Chromium, then runnning
> ungoogled-chromium over it, and then building. I'm not sure if any
> other packages have their freedom problems fixed in this way but this,
> just like build flags, should not be sufficient. Freedom problems
> should not be hidden/removed after the fact by asking the user to run a
> clean-up program after downloading the source, even if that has been
> automated by the package manager. What is sent to the end user to
> compile should itself be 100% free software and FSDG compliant from the
> beginning. If not it still amounts to distributing non-free software to
> the user when they want to, for example, do guix build -S chromium.

As Leo says, `guix build --source` should never return nonfree software
as a matter of policy.  Ungoogled-Chromium is no different: running
`guix build --source ungoogled-chromium` will run the pruning scripts
and generate a sanitized tarball, or (more likely) transparently
download an already-processed source from the build farm.

[signature.asc (application/pgp-signature, inline)]

Message #58 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Giovanni Biscuolo <g <at> xelera.eu>, Leo Famulari <leo <at> famulari.name>
Cc: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Wed, 20 Feb 2019 15:48:51 +0100

[Message part 1 (text/plain, inline)]

Giovanni Biscuolo <g <at> xelera.eu> writes:

> Hello,
>
> maybe Marius Bakke have something interesting to say about his
> judgements on this "DRM matter"

[...]

> to sum it up: AFAIU for users to be able to use Widevine they must
> create a custom package definition _outside_ official Guix channels
> *and* download the shared object "libwidevinecdm.so" from Chromium,
> installing it "manually" system wide or locally

This analysis is correct.  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.

[signature.asc (application/pgp-signature, inline)]

Message #61 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Julien Lepiller <julien <at> lepiller.eu>
To: Jason Self <j <at> jxself.org>
Cc: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Wed, 20 Feb 2019 17:18:56 +0100

Le 2019-02-20 14:03, Jason Self a écrit :
> Jason Self wrote:
>> I should probably add on that this position comes from my interaction
>> with the FSF in 2010: When LibreWRT was founded in 2010 (before it
>> later merged into libreCMC) we submitted a similar 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
>> and would have completely automated, 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, not ask the user to clean up the
>> software afterward even if automated. So that was what we did. Guix
>> should do something similar.
> 
> I haven't been able to find this conversation in my email. As it seems
> to be directly relevant to Guix, since it seems to also be the exact
> same method they use, I have emailed the FSF asking if they can locate
> this in their ticketing system and to re-send the conversation to me.
> More to come.

I think the situation is different though. You can see the build script
inside the "origin" record as the liberation procedure that anyone can
see and verify. It's also a procedure targeted at our build farms, so
that they can produce the liberated source code. Users never manipulate
non-free source code, unless something is wrong on the build farm side.

Essentially, users only download the liberated sources, and build the
package from that, or they download the sources from the build farm
and build the package from that. The source they download is the
one that `guix build -S foo` gives you, and the semantics is
"give me the sources to build foo", not "build the sources of foo".

I think that this way is more transparent, since we can independently,
altough with tooling not provided by guix, check and re-run the
liberation procedure that is documented as part of the guix package
recipe. This is much better than trusting someone to have actually
run the right liberation procedure as you can examine both the result
and the procedure itself.

I hope this is clearer now :)

Well, I'm still interested by that discussion on libreWRT.

Message #64 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Adonay Felipe Nogueira <adfeno <at> hyperbola.info>
To: 34565 <at> debbugs.gnu.org
Cc: Jason Self <j <at> jxself.org>
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Wed, 20 Feb 2019 17:15:15 -0300

[Message part 1 (text/plain, inline)]

Em 20/02/2019 13:18, Julien Lepiller escreveu:
> I think the situation is different though. You can see the build script
> inside the "origin" record as the liberation procedure that anyone can
> see and verify. It's also a procedure targeted at our build farms, so
> that they can produce the liberated source code. Users never manipulate
> non-free source code, unless something is wrong on the build farm side.

I'm not taking any sides here, but to give some more information, if for
example you do `guix edit ungoogled-chromium' you will be presented to
the package definition of Ungoogled-Chromium, taking that as an example
you can see that it has a "source (origin ...) ...)" definition, inside
the inner part (the "origin") you have:

* the upstream download location and method, see (method ...), (uri ...)
and (sha256 ...);
* patches that should be applied immediatelly after downloading and
extracting the source files, per (patches ...);
* snippets and modules to be used with these, also to be applied
immediatelly after downloading and extracting the source files, as seen
in (snippet ...) and (modules ...).

When `guix build -S ungoogled-chromium' is done, first it checks the
build farms for the "prepared" source that matches the given package
definition, version, hash and so on; and lastly it tries to "prepare"
the source according to (patches ...) and (snippet ...) declarations
before even telling the user that the download is ready/done.

Having the (origin ...) visible in this way brings the advantages that
the people of Guix told about here, but as far as I can tell, the user
also sees the original location of the non-free source from upstream if
they do `guix edit ungoogled-chromium'.


-- 
- Página com formas de contato:
  https://libreplanet.org/wiki/User:Adfeno#vCard
- Ativista do software livre (não confundir com o gratuito). Avaliador
  da liberdade de software e de sites.
- Página com lista de contribuições:
  https://libreplanet.org/wiki/User:Adfeno#Contribs
- Para uso em escritórios e trabalhos, favor enviar arquivos do padrão
  internacional OpenDocument/ODF 1.2 (ISO/IEC 26300-1:2015 e
  correlatos). São os .odt/.ods/.odp/odg. O LibreOffice é a suíte de
  escritório recomendada para editar tais arquivos.
- Para outros formatos de arquivos, veja:
  https://libreplanet.org/wiki/User:Adfeno#Arquivos
- Gosta do meu trabalho? Contrate-me ou doe algo para mim!
  https://libreplanet.org/wiki/User:Adfeno#Suporte
- Use comunicações sociais federadas padronizadas, onde o "social"
  permanece independente do fornecedor. #DeleteWhatsApp. Use #XMPP
  (https://libreplanet.org/wiki/XMPP.pt), #DeleteFacebook
  #DeleteInstagram #DeleteTwitter #DeleteYouTube. Use #ActivityPub via
  #Mastodon (https://joinmastodon.org/).
- #DeleteNetflix #CancelNetflix. Evite #DRM:
  https://www.defectivebydesign.org/

[signature.asc (application/pgp-signature, attachment)]

Message #67 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Adonay Felipe Nogueira <adfeno <at> hyperbola.info>
Cc: 34565 <at> debbugs.gnu.org, Jason Self <j <at> jxself.org>
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Wed, 20 Feb 2019 22:49:54 +0100

Adonay Felipe Nogueira <adfeno <at> hyperbola.info> writes:

> Em 20/02/2019 13:18, Julien Lepiller escreveu:
>> I think the situation is different though. You can see the build script
>> inside the "origin" record as the liberation procedure that anyone can
>> see and verify. It's also a procedure targeted at our build farms, so
>> that they can produce the liberated source code. Users never manipulate
>> non-free source code, unless something is wrong on the build farm side.
>
> I'm not taking any sides here, but to give some more information […]

I would appreciate it if this discussion could be moved elsewhere.  This
is about whether the package in Guix contains “Widevine DRM”.  As far as
I understand it does not (as a third-party binary needs to be obtained).

If it does after all contain objectionable files please point them out
so that we can remove them ASAP.

Thanks!

--
Ricardo

Message #70 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Jason Self <j <at> jxself.org>
To: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Wed, 20 Feb 2019 18:19:30 -0800

[Message part 1 (text/plain, inline)]

On Wed, 2019-02-20 at 22:49 +0100, Ricardo Wurmus wrote:
> If it does after all contain objectionable files please point them
> out so that we can remove them ASAP.

That was done earlier in the thread. It might also be interesting to
try building with enable_widevine=true.

In the context of the FSDG's "a free system distribution must not
contain browsers that implement EME, the browser functionality designed
to load DRM modules", I wonder if the browser would still be considered
as "implementing" the "functionality ... to load DRM modules" from the
FSF's viewpoint since it's only a build flag and the support for
loading the module (even if not provided by Guix since it's non-free)
seems otherwise intact.

[signature.asc (application/pgp-signature, inline)]

Message #73 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Jason Self <j <at> jxself.org>
To: 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Wed, 20 Feb 2019 18:43:17 -0800

[Message part 1 (text/plain, inline)]

Marius Bakke wrote:
> not present in the Guix source.

Please keep in mind I was discussing upstream Chromium in that piece.
It's also not an exhaustive list.

> I cannot find these images: grepping for CC-BY-NC-SA or 'Creative
> Commons' did not aid.  Did you record the absolute paths to these
> files?

Of course - FOSSology records everything as it recursively unpacks and
searches files, metadata of files, etc. 

1.
third_party/blink/web_tests/fast/backgrounds/size/resources/SquirrelFis
h.svg has within it:
<a rel="cc:attributionURL" href="http://www.flickr.com/photos/goopymart
/">http://www.flickr.com/photos/goopymart/</a>; / <a rel="license"
href="http://creativecommons.org/licenses/by-nc-sa/2.0/">CC BY-NC-SA
2.0</a></div>

2. chrome/test/data/extensions/api_test/wallpaper_manager/test_bad.jpg
contains:
xmpRights:WebStatement="http://creativecommons.org/licenses/by-nc-sa/2.
0/

3. chrome/test/data/extensions/test.jpg contains within it:
http://creativecommons.org/licenses/by-nc-sa/2.0/

4. chrome/test/data/extensions/api_test/wallpaper/test.jpg
Identified by FOSSology as being identical to file 3.

5. chrome/test/data/extensions/api_test/wallpaper_manager/test.jpg
contains within it:
http://creativecommons.org/licenses/by-nc-sa/2.0/

> My grep-fu is really failing me today.  Where is this located?

chrome/test/data/import/firefox/macwin.zip/Profiles/brn6z0fz.default/ex
tensions/{3112ca9c-de6d-4884-a869-9855de68056c}/chrome/google-
toolbar.jar

chrome/test/data/import/firefox/macwin.zip/Profiles/brn6z0fz.default/ex
tensions/{3112ca9c-de6d-4884-a869-9855de68056c}/LICENSE.txt

Keep in mind this was not an exhaustive report of all of upstream
Chromium 73.0.3683.45 and there is much left out. They were intended
only as examples to show freedom problems within Chromium itself.

As for the rest I guess we'll need to wait on a response from the FSF
since I seem to be receving pushback myself.

[signature.asc (application/pgp-signature, inline)]

Message #76 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Jason Self <j <at> jxself.org>, 34565 <at> debbugs.gnu.org
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Thu, 21 Feb 2019 08:51:04 +0100

[Message part 1 (text/plain, inline)]

Jason Self <j <at> jxself.org> writes:

> Marius Bakke wrote:
>> not present in the Guix source.
>
> Please keep in mind I was discussing upstream Chromium in that piece.
> It's also not an exhaustive list.

I don't think upstream Chromium is relevant to this discussion.

>> I cannot find these images: grepping for CC-BY-NC-SA or 'Creative
>> Commons' did not aid.  Did you record the absolute paths to these
>> files?
>
> Of course - FOSSology records everything as it recursively unpacks and
> searches files, metadata of files, etc. 

I was not aware of FOSSology, and admit that I have not checked file
metadata.  It would be great to have this tool in Guix!

None of the reported files are present in the Guix source.  I believe
they are all scrubbed by the Ungoogled binary pruning script.

I really appreciate your effort here, but please only use this bug
tracker for problems that affect the Guix package.  Thanks!

[signature.asc (application/pgp-signature, inline)]

Message #79 received at 34565 <at> debbugs.gnu.org (full text, mbox):

From: ng0 <ng0 <at> n0.is>
To: Marius Bakke <mbakke <at> fastmail.com>
Cc: 34565 <at> debbugs.gnu.org, Leo Famulari <leo <at> famulari.name>
Subject: Re: bug#34565: ungoogled-chromium contains Widevine DRM
Date: Sat, 12 Oct 2019 11:14:17 +0000

[Message part 1 (text/plain, inline)]

Marius Bakke transcribed 1.2K bytes:
> Giovanni Biscuolo <g <at> xelera.eu> writes:
> 
> > Hello,
> >
> > maybe Marius Bakke have something interesting to say about his
> > judgements on this "DRM matter"
> 
> [...]
> 
> > to sum it up: AFAIU for users to be able to use Widevine they must
> > create a custom package definition _outside_ official Guix channels
> > *and* download the shared object "libwidevinecdm.so" from Chromium,
> > installing it "manually" system wide or locally
> 
> This analysis is correct.  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.

Can this bug be closed?
The wording is very vague ("may") and for Guix to distribute widevine.so
legally, you have to get permission and sign an NDA with Google, both of
which are reportedly hard for 3rd party devs even, not sure how hard it is
for new operating systems. Your stand on software with NDAs should be clear
(as per policy not applicable, no NDAs).
So even if traces of the code to build this might still be left, you have
to master additional steps to make it work, and after having read some
of widevine.so I doubt it would work out of the box with Guix System
(elfpatching could get it to work with Guix, but you are still entering
the field where official distribution requires legal paperwork).

[signature.asc (application/pgp-signature, inline)]

Message #84 received at 34565-done <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: ng0 <ng0 <at> n0.is>
Cc: 34565-done <at> debbugs.gnu.org, Leo Famulari <leo <at> famulari.name>
Subject: Re: bug#34565: ungoogled-chromium may contain Widevine DRM
Date: Sat, 12 Oct 2019 13:32:52 +0200

[Message part 1 (text/plain, inline)]

ng0 <ng0 <at> n0.is> writes:

> Marius Bakke transcribed 1.2K bytes:
>> Giovanni Biscuolo <g <at> xelera.eu> writes:
>> 
>> > Hello,
>> >
>> > maybe Marius Bakke have something interesting to say about his
>> > judgements on this "DRM matter"
>> 
>> [...]
>> 
>> > to sum it up: AFAIU for users to be able to use Widevine they must
>> > create a custom package definition _outside_ official Guix channels
>> > *and* download the shared object "libwidevinecdm.so" from Chromium,
>> > installing it "manually" system wide or locally
>> 
>> This analysis is correct.  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.
>
> Can this bug be closed?

Yes, I am closing this now; thanks for the reminder.

The actual Widevine implementation is not part of Chromium, and the
interfaces for loading it are disabled at build time.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.