[Dev] summary of the chromium/electtron/webengine controversy

Denis 'GNUtoo' Carikli GNUtoo at cyberdimension.org
Mon Mar 28 22:07:56 GMT 2022


On Thu, 24 Mar 2022 06:47:34 -0400
bill-auger <bill-auger at peers.community> wrote:

> several people have asked about this since 'jami-gnome' was
> removed from arch - this post is for the sake of a shared "TLDR"
> reference
Thanks a lot for the reference. I really hope that at some point we
will be able to really know the license of chrome/chromium based source
code to solve this for good and/or bury chrome/chromium for good and
have compatible API and/or other browsers backends instead.

> the chromium web browser is on the "List of software that does
> not respect the Free System Distribution Guidelines" wiki
> page[1] - the presence of any software on that list, prevents
> any distro from being endorsed by the FSF, if it distributes any
> of the software on that list, without applying an accepted
> liberation procedure; and puts the ongoing endorsement in
> jeopardy for any distro which later accepts any of them
> un-treated - currently, the only accepted liberation procedure
> for chromuim is: "use icecat"
The issue with that page is that it's not well maintained. Some
information there seem really old and many packages are probably
missing. We probably need people to help with that.

> as far as i have been able to determine, this issue affects all
> web browsers derived from chromium, simply because no one from
> any of the popular forks i have looked at (such as
> ungoogled-chromium and iridium) has claimed to address any
> licensing issues (those projects address only privacy issues) -
> also, this issue most likely affects all software which
> includes, or is derived from chromium, qt-webengine, or electron
That also doesn't seem very relevant by itself: if the issue is fixed
upstream, browsers will probably not mention that they did address
licensing issues.

However as I understand it's really hard to know if it's fixed upstream
or not given the huge amount of code and repositories.

Android has a similar issue, so we probably need to collaborate in
fixing that type of issues in some ways.

As I understand, in both cases the build system doesn't have any
package definitions and the build outputs aren't packaged in any ways.

Instead all the source code is checked out in the same directory and
everything is built from that. Though Android somehow generates a
license list that is available in the settings.

For Replicant 11 I've started making a quick and dirty script to find
out the licenses of each repository but I need to improve it, try
license scanners, etc. I also plan to document these tools in the
libreplanet wiki at some point.

When making packages, we really need to indicate the license under
which the package is, and different distributions probably dealt with
that more or less strictly in the past depending on the distribution.

For instance Debian has a reputation of being strict and of
finding and removing nonfree software from within packages they have
in their main repository. So we can often find information there on new
nonfree software being added to various projects. Finding nonfree code
is probably also related to the will to do it and also the huge amount
of Debian developers compared to other distributions (that we lack in
Parabola for instance).

I really wonder how distributions dealt with code of unknown
licenses in the past. Did they simply remove the packages if the
license was unknown. Are there situations in the past where the
distribution wasn't under pressure of having something important not
working?

Do we have precedents where most distributions removed software because
of mess like that?

I recall that at some point we removed some OpenGL headers in
Gnewsense and that at the end the FSF managed to make the author of
these headers relicense them under free software. Could we somehow
build pressure to have Google make sure that the code is at least legal
to redistribute in ways that we can check?

> some have tried[12]; but it is
> probably never going to be completed satisfactorily - electron
> seems to a hopeless cause for distros[8]; so the only reasonable
> project to consider, is qt5-webengine - that is fortunate,
> because qt5-webengine is used by hundreds of programs, making it
> the one of the three with the greatest impact on distros, by far
> - to focus on chromium would require orders of magnitude more
> work, only for that one extra program
We also need to take into account the maintenance of the license checks.

We probably don't have enough time and people to review some source code
based on chromium for each releases of that code.

The ideal situation would be to have that software packaged as it is
usually done: by having 1 package per dependency. But here that would
probably mean packaging several hundreds or thousands of projects just
for a browser that isn't even desirable. And these packages would also
need to be maintained.

Another option would be to somehow automatize the license checks with
license scanners.

I also wonder if we can somehow force Google to do that work?
Like if there is a lawsuit for instance, would there be a way where
it would be up to google to tell us the license and show to us (for
instance in a document that shows the correspondence between licenses
and files) that they didn't violate any free software license?

Also did someone already try to work with upstream to somehow force
upstream to put in place a process (similar to process in
distributions) where the license are reviewed and licensing information
is updated? Or did someone already discussed with upstream about the
possibility of doing that?

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20220329/9bf75e1e/attachment.sig>


More information about the Dev mailing list