From: bill-auger <bill-auger@peers.community>
To: gnu-linux-libre@nongnu.org
Cc: guix-devel@gnu.org
Subject: Re: [PATCH] gnu: Add ungoogled-chromium.
Date: Sat, 16 Feb 2019 03:00:21 -0500 [thread overview]
Message-ID: <20190216030021.374f4c82@parabola> (raw)
In-Reply-To: <87tvhf5f8d.fsf@dustycloud.org>
On Mon, 04 Feb 2019 23:34:45 +0100 Ludovic wrote:
> It’s not entirely clear to me what the problems are, to be honest.
On Wed, 06 Feb 2019 22:04:59 +0100 Marius wrote:
> Indeed, the only real breakthrough is that we now have a script to
> create an Ungooglified source tarball with all unnecessary third_party
> components removed.
> I am of course happy to help other FSDG distributions liberate their
> Chromium too.
it is not clear to *anyone* precisely what the licensing problems are -
not even the upstream developers have been able to confirm or deny them
with any certainty - that is the very reason why this ugly situation has
been standing all these years, as yet unresolved
by your own admittance there, you have not "liberated" chromium - you
have "ungooglified" it, and discarded some non-essential third-party
code - the work of the "ungoogled" and "iridium" teams has been
discussed at length and was concluded to be insufficient as a liberation
procedure, because their work only addresses proivacy issues, but not
licensing - "liberation" would first require *something* that is not
FSDG compliant to be identified as such, and *then* for that something
to be removed or patched in order to be compliant - neither of those
events has occurred, and we all know it - that is the very reason this
situation has stood unresolved for so long
so, this recent work done by guix is not a resolution to the problem -
it is merely sweeping the problem under the rug, rather than confronting
it at face value, as Adfeno has been suggesting
On Thu, 07 Feb 2019 18:52:02 -0500 Christopher wrote:
> +1 ... If concrete problems are found, by all means those should be
> raised and addressed. Otherwise I really think we ought to merge this
> work.
this statement is indicative of the lack of concern for the wider FSDG
ecosystem which is implicit in most of the guix team's statements on
this issue - do correct me if im wrong, but i read that: "we" as:
"guix" - as in: guix should adopt this program - as in: regardless of
the long standing consensus among the other FSDG distros that it is not
yet fit for inclusion
this is puts the other FSDG distros in a very uncomfortable position;
and the chromium program specifically, is not really the crux of the
issue - i do hope that i have not lost anyone's attention yet; because
this is where i will try to explain, what is the critical point of
contention at this time
about a year ago, the FSDG review process and criteria for endorsement
of new distros was updated - the new FSDG criteria checklist for
community review that was adopted includes the following essential
criteria:
"Programs commonly known to have freedom issues are liberated or
excluded"
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"
that created an uncomfortable pressure point for any distro that wants
to distribute this browser - according to the literal reading of that
criteria, no new distro could be endorsed by the FSF today if it
distributes chromium; because it would never make it past the community
review stage - this was not a concern for the last new distro because
it did not include chromium; so that ugly wart is still sitting there
today
it was also agreed upon at that time, that the FSDG criteria should be
applicable to all currently endorsed distros in perpetuity, so ...
On Mon, 04 Feb 2019 23:34:45 +0100 Ludovic wrote:
> I’d also like to stress that, if Chromium is eventually included in
> Guix, we are committed to fixing it or removing it should someone
> later discover that it does not comply with the FSDG (that’s the
> “Commitment to Correct Mistakes” section of FSDG.)
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), just as what happened with pureos; which they reluctantly,
but eventually acted upon by removing chromium from their free repos -
so, why would guix want to invite controversy, by knowingly repeating
this historical mistake?
and BTW, where was guix's voice on this matter last year when pureos was
trying to defend their very same position on this very same issue? - no
one came forward to back them up on that position then; and to their
credit, they decided to adopt the position of the group, for the sake of
presenting a coherent message to the free software community as a
unified group - that was an important gesture on their part, which
strengthened the credibility of the FSDG, by showing that its
guidelines are not subject to the interpretation of each distro
arbitrarily - perhaps that consensus could have gone the other way if
the argument: "we should always trust the upstream on their word"[1]
had gained favor, and guix's induction of a chromium package would be
an entirely uninteresting event today
so, i suggest that it is in the best interest of guix (and any other
distro that wants chromium) to explicitly challenge that one point and
see if that entry can be removed or changed before that bug report is
posted against guix - i think i have just demonstrated that it would be
an easy argument to make, that chromium entered guix knowingly and
willingly in conflict with the new FSDG criteria
this is not a comfortable situation for anyone - a number of people
on this list have openly expressed a strong dislike for that current
situation - it is a really ugly point of contention at the moment; but
nothing has been done about it yet - i think the reason for that, is
mainly because there has been too few interested in defending or
liberating that program until now - even the pureos devs, who were the
last to remove it, were not particularly fond of it, but were slow to
remove it, only to appease users - this would be a great entry point for
guix to join the discussions on the FSDG mailing list, and perhaps
resolve this issue for everyone, including distros yet to come
it was, of course, nice of Marius to offer to assist other distros; but
individual assistance is not what is needed - what is needed is a
generally agreed upon, documented, liberation procedure that can
replace: "Use GNU IceCat instead" as the new FSDG recommendation - i
think we would all like to see that happen; but i dont think anything
convincing has yet been presented, much less been discussed openly or
agreed upon
[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?msg=305;bug=28004;att=0
next prev parent reply other threads:[~2019-02-16 8:00 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87y3qvb15k.fsf@fastmail.com>
2019-02-02 19:20 ` [PATCH] gnu: Add ungoogled-chromium Marius Bakke
2019-02-03 18:16 ` Joshua Branson
2019-02-04 4:52 ` bill-auger
2019-02-04 5:52 ` brettg
2019-02-04 7:46 ` Ineiev
2019-02-04 10:56 ` bill-auger
2019-02-04 14:43 ` Jean Louis
2019-02-04 12:26 ` [GNU-linux-libre] " Julie Marchant
2019-02-04 15:03 ` bill-auger
2019-02-04 22:34 ` Ludovic Courtès
2019-02-06 21:04 ` [GNU-linux-libre] " Marius Bakke
2019-02-07 23:52 ` Christopher Lemmer Webber
2019-02-07 23:59 ` Julie Marchant
2019-02-16 8:00 ` bill-auger [this message]
2019-02-16 10:25 ` Brett Gilio
2019-02-16 14:18 ` Julie Marchant
2019-02-16 15:37 ` [GNU-linux-libre] " Adam Van Ymeren
2019-02-16 19:47 ` Adonay Felipe Nogueira
2019-02-16 20:01 ` Brett Gilio
2019-02-16 20:06 ` Brett Gilio
2019-02-17 1:39 ` bill-auger
2019-02-17 22:33 ` [GNU-linux-libre] " Ricardo Wurmus
2019-02-18 12:05 ` bill-auger
2019-02-18 12:15 ` Hartmut Goebel
2019-02-18 13:44 ` Tobias Geerinckx-Rice
2019-02-18 19:22 ` Simon Nielsen
2019-02-19 20:45 ` [GNU-linux-libre] " bill-auger
2019-02-16 20:07 ` Alex Griffin
2019-02-17 1:49 ` bill-auger
2019-02-17 1:37 ` bill-auger
2019-02-17 2:30 ` Julie Marchant
2019-02-17 2:42 ` bill-auger
2019-02-17 4:19 ` Julie Marchant
2019-02-17 7:43 ` bill-auger
2019-02-17 14:06 ` Julie Marchant
2019-02-18 7:43 ` bill-auger
2019-02-17 20:55 ` Christopher Lemmer Webber
2019-02-16 11:16 ` Gábor Boskovits
2019-02-16 12:55 ` ng0
2019-02-16 13:10 ` Gábor Boskovits
2019-02-18 13:47 ` Denis 'GNUtoo' Carikli
2019-02-16 15:10 ` znavko
2019-02-16 15:50 ` Marius Bakke
2019-02-16 16:20 ` [GNU-linux-libre] " Amin Bandali
2019-02-16 16:33 ` Marius Bakke
2019-02-16 19:27 ` Amin Bandali
2019-02-17 2:20 ` bill-auger
2019-02-16 16:34 ` Alexandre Oliva
2019-02-16 16:54 ` Marius Bakke
2019-02-17 3:38 ` bill-auger
2019-02-16 18:56 ` Giovanni Biscuolo
2019-02-19 16:28 ` Giovanni Biscuolo
2019-02-09 14:04 ` Adonay Felipe Nogueira
2019-02-03 20:21 ` Amin Bandali
2019-02-05 5:22 ` [bug#28004] " swedebugia
2019-02-12 15:58 ` [PATCH v2] " Marius Bakke
2019-02-18 22:43 ` [bug#28004] " Marius Bakke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190216030021.374f4c82@parabola \
--to=bill-auger@peers.community \
--cc=gnu-linux-libre@nongnu.org \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).