[Dev] [RFC] Let's solve the Chromium freedom issues, definitively

[bill-auger]

On Sat, 13 Jun 2020 00:36:19 -0400 Megver83 wrote:
> I opened an issue in ungoogled-chromium's GitHub, asking if it
> completely cleans Chromium from non-free software. It
> certainly doesn't, but I got very interesting and useful info.
> For further reading:
> 
> https://github.com/Eloston/ungoogled-chromium/issues/1054

i am cross-posting this to the FSDG mailing list, to make others
aware of it

the important factor to bear in mind, is that this is not only
about establishing a libre-fork - the initial audit needed to do
so, would itself be a huge amount of work; but even if that were
easy, the main task entails that someone is going to maintain
the fork into the future - that would entail constantly watching
the new upstream changes, and removing anything new that creeps
in, which conflicts with the FSDG - that maintenance is a
significant challenge with firefox, which is just barely being
met by the available people now - one needs to look no farther
than the under-staffed gnuzilla project for evidence of that -
most people have the opinion that firefox is significantly more
libre-friendly than chromium; which means that there is no one
available to do that same amount of work (and probably more) for
chromium, not even the initial audit needed to establish the fork

if the 'ungoogled-chromium' project had any interest in taking
up that challenge, they probably would have done so already - i
just read that ticket on github today - i presumed that megver
was "barking up the wrong tree"; and that discussion confirmed
so - the maintainer made it clear that a full audit would be too
much work, and the outcome would be undesirable to that project
anyways; because anything which had to be removed, would
probably exclude some use-case on some platform, android
especially

although the reception of megver's proposal was superficially
positive, the counter-proposal offered, is to put all
liberation changes in a separate and unsupported 'contrib' repo,
along with any arbitrary additions which users want to
contribute, with little or no over-sight - that does not sound
like endorsable software to me; because by the maintainer's own
statement, that fork will not be properly maintained and may
contain _anything_ that any user submits

that brings the endeavor right back to square #1 - the only
notable difference with that 'ungoogled-chromium' proposal, is
that the fork or patches would be hosted on github under the
'ungoogled-chromium' name-space; but the 'ungoogled-chromium'
maintainer was not apparently interested in participating in the
effort - for these reasons, the fork or patches would be better
hosted by GNU, and dedicated only to FSDG-fitness; but the
progress to date is probably 10,000 work-hours away from
establishing an initial 100% verified fork - so progress toward
the goal of a 100% libre chromium, has unfortunately not been
advanced one iota by the attempt - that is also ignoring that
the suspected problems, if they exist, are licensing issues,
which can most likely only be resolved and attested to by the
copyright holders, not by any fork or cleaning scripts such as
'ungoogled-chromium'

to quote megver from that ticket:
  "the Chromium distributed by Guix is completely free, ...
   ... but it's technically not FSDG compliant
   because it downloads the chromium source code"

if that were the case, then why bother the 'ungoogled-chromium'
maintainer with this? - other distros could simply convert the
guix liberation script into their format, and declare the matter
as resolved, as the guix maintainers suggested 18 months ago -
in doing so, however, it would immediately become evident that
those liberation scripts would also need to download the
upstream sources - that is an entirely different issue though;
which was discussed on the FSDG mailing list last november[1]

the implications of that, reach far beyond any one program - if
the FSDG prohibited liberation scripts from downloading the
original source code, then FSDG distros could not publish any
liberation scripts - that includes all PKGBUILDs in libre, as
well as the gnuzilla makeicecat.sh script - naturally, any
liberation script must acquire the original code, which is to be
cleaned - the only alternative would be for FSDG distros to
clean the sources privately, and publish the pre-cleaned sources
publicly, keeping all liberation scripts private, including
makeicecat.sh, as published by a GNU project - it would be very
ironic if gnuzilla were considered to be unfit for the FSDG

to assume that the guix chromium is completely free of licensing
problems, is the same as assuming that a forest is completely
devoid of ants, merely because none have been seen yet - the
larger that forest is, it is increasingly likely to have ants
lurking somewhere; and chromium is a very large forest indeed,
perhaps the largest on the planet, and mostly unexplored

there is one other thing wrong with that statement - the fact
that in some or all cases, the upstream code-base may be
downloaded to the local computer to be cleaned in place, is not
the reason why the guix chromium is unfit for the FSDG - the
guix and pureos chromiums are not FSDG-fit, if only because the
standing consensus of the FSDG work-group is that they are not -
the FSF has never contested nor confirmed that consensus; and the
official FSDG recommendation for chromium is still "use icecat"

any solution would need to be approved by the FSDG work-group
and/or the FSF, before it would be considered to be acceptable
in any FSF-endorsed distro, and to become the standard
recommendation - the guix chromium has not passed that review;
and the pureos chromium has not even been looked at - that is
the main reason why this discussion is best conducted on the
FSDG mailing list


[1]: https://lists.nongnu.org/archive/html/gnu-linux-libre/2019-11/msg00002.html