Re: [PATCH] gnu: Add ungoogled-chromium.

[bill-auger]

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 pack

Re: [PATCH] gnu: Add ungoogled-chromium.

[Brett Gilio]

bill-auger writes:

> 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.  
>

I agree with everything Bill said in his message, and I heavily
encourage all of us lurking in this mailing list with an opinion on the
matter to please state your opinion on this controversy and the Guix
relationship to the FSDG.

The free software guidelines are first and foremost put up by the free
software community by what is specified to be important to the values of
free software. This needs to be addressed sooner than later, because the
act of solidarity on the part of the community here is a tremendously
crucial and singular event.

I'd like to see the offerings of free software to grow, and include
chromium if chromium has a reasonable method of liberation. But there is
yet to be a complete audit to identify the problems. We can not rely
solely on speculation, so lets get to the bottom of this once and for
all.

Brett Gilio

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Chris Marusich]

Hi Danny,

Danny Milosavljevic  writes:

> Can you try the following (if you didn't already)?
>
> [...]
>
> (i.e. the things you did before, just inside a i686-linux guix
> environment.  That only provides minimal--almost no--isolation from
> the host, so it should allow us to test whether the personality is the
> only possible culprit)

Did you mean to say that by using a pure guix environment, we can
achieve a high degree of isolation?

I tried what you suggested.  The mrustc invocation still succeeded.

Just for fun, I also made a simple wrapper program that lets me run
another program using the LINUX32 personality (see attached).  I think I
programmed it correctly, but C is not (yet!) my forte, so if I made an
error, please let me know.  From within the same pure environment, I
used this wrapper program to invoke mrustc in the same way, and it
_still_ succeeded.  That surprised me, since I expected it to fail.

Can you think of any other way I can try to reproduce the issue?

-- 
Chris


with_linux32_personality.c
Description: Binary data


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add ungoogled-chromium.

[Gábor Boskovits]

Hello,

bill-auger  ezt írta (időpont: 2019. febr.
16., Szo, 9:01):

> 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
>

It seems to me, that there is a whole bunch of people interested in this,
but due to lack of resources or for some other reasons nothing is really
happening. Do you know any we we could help getting this resolved?

> 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

I also suspect, that the possible licensing problems are not resolved by this,
if they even exists, what seemingly noone has checked yet.

Also, what ensures you that on the very next commit no non-free software gets
included?

> 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

The main question is what needs to be done, in order to get chromium off
that list. Whatever it takes however, it is very clear that upstream won't do
that, so it is not an option to rely on them any more. What's the way forward?

> 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?

Most probably you are right on this point.

>
> 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
>

Yes I think it would be really important to decide what liberation procedure
would be applicable.

>
> [1]: https://debbugs.gnu.org/cgi/bugreport.cgi?msg=305;bug=28004;att=0
>

Best regards,
g_bor

Re: [PATCH] gnu: Add ungoogled-chromium.

[ng0]

I think it's unreasonable to assume that everyone involved in GNU Distros
reads and participates in gnu-linux-li...@nongnu.org discussions. You have
a limited amount of time for projects, and this other mailinglist, when I
used to follow it has lots of discussions not related to Guix. So please
don't assume that the collective "we" gets involved in discussions on
two lists.

Gbor Boskovits transcribed 4.5K bytes:
> Hello,
> 
> bill-auger  ezt írta (időpont: 2019. febr.
> 16., Szo, 9:01):
> 
> > 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
> >
> 
> It seems to me, that there is a whole bunch of people interested in this,
> but due to lack of resources or for some other reasons nothing is really
> happening. Do you know any we we could help getting this resolved?
> 
> > 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
> 
> I also suspect, that the possible licensing problems are not resolved by this,
> if they even exists, what seemingly noone has checked yet.
> 
> Also, what ensures you that on the very next commit no non-free software gets
> included?
> 
> > 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
> 
> The main question is what needs to be done, in order to get chromium off
> that list. Whatever it takes however, it is very clear that upstream won't do
> that, so it is not an option to rely on them any more. What's the way forward?
> 
> > 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?
> 
> Most probably you are right on this point.
> 
> >
> > 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
> >
> 
> Yes I think it would be really important to decide what liberation procedure
> w

Re: [PATCH] gnu: Add ungoogled-chromium.

[Gábor Boskovits]

Hello,

 ezt írta (időpont: 2019. febr. 16., Szo, 13:56):
>
> I think it's unreasonable to assume that everyone involved in GNU Distros
> reads and participates in gnu-linux-li...@nongnu.org discussions. You have
> a limited amount of time for projects, and this other mailinglist, when I
> used to follow it has lots of discussions not related to Guix. So please
> don't assume that the collective "we" gets involved in discussions on
> two lists.
>

Yes, I totally agree. I believe that keeping both list in CC is the
way to go here.

I am also not subscribed to gnu-linux-libre.

Best regards,
g_bor

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

[Julie Marchant]

On 02/16/2019 05:25 AM, Brett Gilio wrote:
> I agree with everything Bill said in his message, and I heavily
> encourage all of us lurking in this mailing list with an opinion on the
> matter to please state your opinion on this controversy and the Guix
> relationship to the FSDG.
> 
> The free software guidelines are first and foremost put up by the free
> software community by what is specified to be important to the values of
> free software. This needs to be addressed sooner than later, because the
> act of solidarity on the part of the community here is a tremendously
> crucial and singular event.
> 
> I'd like to see the offerings of free software to grow, and include
> chromium if chromium has a reasonable method of liberation. But there is
> yet to be a complete audit to identify the problems. We can not rely
> solely on speculation, so lets get to the bottom of this once and for
> all.

I think that assuming Chromium is no good until something no good is
found in it is a wrong approach.

I don't understand what's so complicated about this issue. In justice
systems, we adopt an "innocent until proven guilty" system because you
can't really prove innocence, only guilt. Would it not make sense to use
this tried and tested system when evaluating whether or not a program is
libre? The only argument I've seen on the matter is the way copyright
works, but Chromium is under the Modified BSD License according to
documentation I was able to find. If some files are not actually covered
by this license, or some other license, it would be very easy to simply
point to the file. As far as I know, and correct me if I'm wrong here,
no one in the entire history of this claim about Chromium being
proprietary has ever done so. If I'm wrong about this, though, then it
seems to me that the correct action to take would be to address that
issue, if not upstream, then in a fork.

-- 
Julie Marchant
http://onpon4.github.io

Encrypt your emails with GnuPG:
https://emailselfdefense.fsf.org

Re: [PATCH] gnu: Add ungoogled-chromium.

[znavko]

Hello, bill! Thanks for your clarifications!
Really, is it possible to make chromium free software?
Also, FSF free software directory can divide packages by criteria like
1) Totally free GNU - open-source and free license GPL
2) Totally free nonGNU - - open-source and free license non-GPL
3) Totally open-source (with non-free license)
4) Non-free

This may help people to solve such issues more conveniently, having this 
knowledge base.
It also will help developers to adopt FSDG.

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

[Adam Van Ymeren]

On February 16, 2019 9:18:58 AM EST, Julie Marchant  wrote:
>On 02/16/2019 05:25 AM, Brett Gilio wrote:
>> I agree with everything Bill said in his message, and I heavily
>> encourage all of us lurking in this mailing list with an opinion on
>the
>> matter to please state your opinion on this controversy and the Guix
>> relationship to the FSDG.
>> 
>> The free software guidelines are first and foremost put up by the
>free
>> software community by what is specified to be important to the values
>of
>> free software. This needs to be addressed sooner than later, because
>the
>> act of solidarity on the part of the community here is a tremendously
>> crucial and singular event.
>> 
>> I'd like to see the offerings of free software to grow, and include
>> chromium if chromium has a reasonable method of liberation. But there
>is
>> yet to be a complete audit to identify the problems. We can not rely
>> solely on speculation, so lets get to the bottom of this once and for
>> all.
>
>I think that assuming Chromium is no good until something no good is
>found in it is a wrong approach.
>
>I don't understand what's so complicated about this issue. In justice
>systems, we adopt an "innocent until proven guilty" system because you
>can't really prove innocence, only guilt. Would it not make sense to
>use
>this tried and tested system when evaluating whether or not a program
>is
>libre? The only argument I've seen on the matter is the way copyright
>works, but Chromium is under the Modified BSD License according to
>documentation I was able to find. If some files are not actually
>covered
>by this license, or some other license, it would be very easy to simply
>point to the file. As far as I know, and correct me if I'm wrong here,
>no one in the entire history of this claim about Chromium being
>proprietary has ever done so. If I'm wrong about this, though, then it
>seems to me that the correct action to take would be to address that
>issue, if not upstream, then in a fork.

This issue documents some chromium efforts to update to copyright on all files. 
 I haven't looked at the source myself yet but this bug suggests that there are 
still hundreds to thousand's of files with no clear license.

https://bugs.chromium.org/p/chromium/issues/detail?id=28291

Someone should run their check licenses script again on the latest codebase and 
see what it reports.

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

[Marius Bakke]

bill-auger  writes:

> 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

For the benefit of everyone following this discussion, I'll summarize
the problems with Chromium and how they are addressed by my patch.

1) Chromium is non-free.

The raw Chromium tarball contains a lot of software that is non-free.
Heck, it's not even possible to build it without the proprietary Unrar
program unless you patch it!

Luckily, these non-free components are in various "third_party"
directories.  Thus, it is possible to traverse the tarball and remove
all such parts that are not already audited and whitelisted.  Which is
exactly what my patch does.

Despite years of searching, I have not found any proprietary parts in
first party code!  I cannot prove this obviously; but proving the
contrary should be trivial.

Thus, I surmise that the code is indeed free --- I would not have
submitted it for Guix if I had the slightest doubt to the contrary.

2) Chromium spies on the user.

Just starting the browser in the default configuration will cause it to
submit traffic to Google.  The exact nature of this data is unclear, but
such behaviour is clearly not something fit for a GNU distribution.

Ungoogled-Chromium solves this by 1) patching out all non-essential
functionality (such as "safe browsing" and web store integration); and
2) performing a tree-wide "domain substitution" such that all Google
(and some more) domains are replaced with a bogus "9oo91e.qjz9zk" domain.

I have verified that the browser sends no unsolicited network requests
when launching or during usage after applying the Ungoogled patches,
something I never managed with the "normal" free Chromium no matter how
many flags or patches I tried.

Thus, I surmise that this browser does indeed protect the users privacy.



Since there have been no coherent arguments against this browser in the
two weeks since it was submitted, I plan to push this patch *tomorrow*.

Thanks for the feedback,
Marius


signature.asc
Description: PGP signature

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

[Amin Bandali]

Marius, if I understand correctly, you have summarized your patch with
respect to the following two issues:

1. Your patch strips out parts of Chromium that are /clearly/ nonfree
   and proprietary (e.g. unrar per your example), and

2. Your patch addresses (or tries to) privacy concerns.

But as far as I can tell, you have not addressed the concerns shared by
Bill and others about the situation with files in the Chromium codebase
that don’t have a clear license.  So I’ll try to repeat/rephrase their
question(s): does your patch address the files with unclear license?
Does it strip out those files that don’t have a clear license?  Can we
be certain that the Chromium built from your patch explicitly *only*
contained free software?

Best,
amin

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

[Marius Bakke]

Amin,

Amin Bandali  writes:

> Marius, if I understand correctly, you have summarized your patch with
> respect to the following two issues:
>
> 1. Your patch strips out parts of Chromium that are /clearly/ nonfree
>and proprietary (e.g. unrar per your example), and
>
> 2. Your patch addresses (or tries to) privacy concerns.
>
> But as far as I can tell, you have not addressed the concerns shared by
> Bill and others about the situation with files in the Chromium codebase
> that don’t have a clear license.  So I’ll try to repeat/rephrase their
> question(s): does your patch address the files with unclear license?
> Does it strip out those files that don’t have a clear license?  Can we
> be certain that the Chromium built from your patch explicitly *only*
> contained free software?

Can you point out one or more files with an unclear license?  Do we have
any reason to distrust what's written in the LICENSE file?


signature.asc
Description: PGP signature

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

[Alexandre Oliva]

On Feb 16, 2019, Marius Bakke  wrote:

> Despite years of searching, I have not found any proprietary parts in
> first party code!

Could you please summarize what you did in your searching?

Maybe you have actually completed the steps that were missing in the
auditing or Chromium to conclude it's Free, or at least some of the
remaining tasks can be checked off.

-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe

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

[Marius Bakke]

Alexandre Oliva  writes:

> On Feb 16, 2019, Marius Bakke  wrote:
>
>> Despite years of searching, I have not found any proprietary parts in
>> first party code!
>
> Could you please summarize what you did in your searching?
>
> Maybe you have actually completed the steps that were missing in the
> auditing or Chromium to conclude it's Free, or at least some of the
> remaining tasks can be checked off.

I'm afraid I don't have a good summary.  I have grepped for certain
keywords and looked for LICENSE-like files, sanity checked many
different parts of the source...  Much like I do for any Guix package,
only going over the course of years.  Are there any concrete tasks that
that I can look at and check off?


signature.asc
Description: PGP signature

Re: Using GPG Subkeys with git/savannah

[Alex Vong]

Björn Höfling  writes:

> Hi Laura,
>
> you wanted to know how to use GPG subkeys. You want to use them for
> virtual machines. I found a very nice, practical explanation from the
> Debian wiki:
>
> https://wiki.debian.org/Subkeys
>
Another guide I find useful is:
https://riseup.net/en/security/message-security/openpgp/gpg-best-practices

In particular, it teaches me to use fingerprint instead of key id, and
to use parcimonie to sync keys.

> What I haven't found out is how/if you can use multiple subkeys for
> savannah.gnu.org. Does anyone know about that?
>
> Thanks,
>
> Björn


signature.asc
Description: PGP signature

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

[Clément Lassieur]

> Since there have been no coherent arguments against this browser in
> the two weeks since it was submitted, I plan to push this patch
> *tomorrow*.

Hi Marius,

Thank you again for your excellent work.  I'm looking forward to seeing
it pushed!

Clément

Re: [PATCH] gnu: Add ungoogled-chromium.

[Giovanni Biscuolo]

Hi guix-devel!

this is my humble contribution to this discussion...
(I'm not a Guix maintainer)

first and foremost, IMHO guix-devel is not the place to discuss GNU FSDG
criteria; I'm going to subscribe gnu-linux-li...@nongnu.org to send
my comments - and I _have_ some - on the FSDG compliance process

if you are interested please follow this thread:
http://lists.nongnu.org/archive/html/gnu-linux-libre/2019-02/threads.html#00020
:-D

bill-auger  writes:

[...]

> 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,

for reference, this page:
https://libreplanet.org/wiki/Template:FSDG_Checklist

> 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"

[...]

> it was also agreed upon at that time, that the FSDG criteria should be
> applicable to all currently endorsed distros in perpetuity, so ...

thank you for the clarification, Bill: you explained us the entire
FSDG_Checklist is *mandatory* for a distro to be GNU FSDG compliant; so
there's **no discussion** here

if Guix System Distribution wants to remain GNU FSDG compliant - as most
if not all Guix contributors would like, I suppose - ungoogled-chromium
should still not be included in Guix System Distribution

so, regarding this bug #28004 the natural resolution should be to
*postpone* the inclusion of this package with a statement like this one:

  "ungoogled-chromium cannot be included in Guix System Distribution since
  it is listed - as 'chromium-browser' - on the page
  

  that is an integral part of the GNU FSDG Guidelines as extended by the
  FSDG_Checklist via 
https://libreplanet.org/wiki/Incoming_distros#Endorsement_Process";

Happy hacking! :-)
Giovanni



[1] https://www.gnu.org/distros/free-system-distribution-guidelines.en.html

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: New topic: asking for help

[Alex Vong]

Laura Lazzati  writes:

> Hi!
>> > * First entry maybe is the homepage as such.
> Guix site?
>> > * Then show the documentation [or: are we here already assuming that
>> > someone found that?].
> We are adding in every video the link to the full documentation in the
> last slide.
>> > * Then mailing list (dev/help).
>> > * IRC channel is also quite a help, I would mention that too.
>> > * There is the debbugs bug tracker
>> > (https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guix) where you could
>> > search for problems. It is maybe not the most obvious interface and
>> > explaining it a bit would be nice.
> uhm but isn't the idea of the video "hi, I'm new, I am trying to use
> GNU Guix, how can I ask for help?" That was what I had in mind, or at
> least what I understood. Maybe if there is enough time, we can add it,
> but I feel it is kind of advanced for the video.
>> >
>>
>> This ordering looks fine to me.
>>
>> I would add some emphasis to finding the
>> documentation and the contact page on the website, but that might be obvious.
> I agree with this, we can show a screenshot of that part of the site :)
>
>>
>> I would spilt up showing documentation, and first refer to the
>> location with the other videos,
>> then to the manual, the rationale being is that someone who is already
>> watching a documentation
>> video might be more interested in documentation videos in the first place.
> I mentioned that the videos show at the end a slide with the link for
> the documentation, but does not harm adding it again.
>> I guess I would skip the dev list here
> OK, just help. is it fine taking snapshots?
>> I also believe that the IRC channel is quite important. On thing to
>> consider here is to mention the
>> things related to nickname registration and logging in.
> Here we need to show like in cli sessions or just explain it?
>> We might also propose the mumi as the primary issue tracking
>> interface, and mention debbugs in
>> case more advanced stuff is needed. No strong opinion here.
> Already mentioned my idea about debbugs. Don't know what mumi is :/
>
I don't know what's mumi either. But I think there's a (relatively new)
web frontend for debbugs: https://issues.guix.info/

> Regards :)
> Laura


signature.asc
Description: PGP signature

Re: manage /boot/grub/grub.cfg without installing grub binaries to disk

[Raghav "RG" Gururajan]

Hi Clement!

The following is the error I got.

config-fail.scm:9:0: error: inherit: unbound variable
hint: Did you forget a `use-modules' form?

 Original Message 
On 14 Feb 2019, 13:07, Raghav "RG" Gururajan wrote:

> Hi Clement!
>>
>> Thanks! Will do.
>>
>> @Jack. Can you also try this and let me know. My system is running dd 
>> command for 2TB HDD. So gonna take a while.
>>
>> Thanks!
>  Original Message 
> On 14 Feb 2019, 12:15, Clément Lassieur wrote:
>
>> Hi Jack and Raghav,
>>
>> Could you try this?
>>
>> --8<---cut here---start->8---
>> (bootloader-configuration
>> (bootloader
>> (bootloader
>> (inherit grub-bootloader)
>> (installer #~(const #t)
>> --8<---cut here---end--->8---
>>
>> Clément

publickey - raghavgururajan@protonmail.ch - 0xE1982130.asc
Description: application/pgp-keys

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

[Amin Bandali]

Marius,

On 2019-02-16  5:33 PM, Marius Bakke wrote:

[...]

>
> Can you point out one or more files with an unclear license?  Do we have
> any reason to distrust what's written in the LICENSE file?
>

I don’t have a direct example of one such file off top of my head, but
looking at the large reported chromium issue[1], I see there are a
number of open blocking issues linked to that one.  Also, I was looking
at [2] and [3] from a little over a year ago, which included the results
of running licensecheck on the chromium tree, but I wasn’t able to
download any of the resulting txt files there.  So I thought I’d clone a
fresh copy of chromium and run licensecheck from the Debian Stretch repo
on all the files as follows:

git clone --depth 1 https://chromium.googlesource.com/chromium/src.git
cd src
git rev-parse HEAD  # result: eda06a0b859a08d15a1ab6a6850e42e667530f0b
licensecheck -c '.*' -r * > ../licensecheck-chromium-eda06a0b859a.txt

I’ve attached a gzipped version of the above text file.  Granted, there
are caveats: firstly, that the above invocation of licensecheck examines
/all/ of the files in the repo, including test html files which are not
relevant and should be filtered out; and secondly, the output contains a
very large number of “UNKNOWN” results which may be false positives.

Link [3] mentioned running FSD Script Aid on the chromium tree as well,
but I don’t have enough time at the moment to do so.

Hope this is of some help.

[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=28291
[2]: https://lists.gnu.org/r/directory-discuss/2017-11/msg00014.html
[3]: https://directory.fsf.org/wiki/Talk:Chromium

Best,
amin

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

[Adonay Felipe Nogueira]

Em 16/02/2019 12:18, Julie Marchant escreveu:
> libre? The only argument I've seen on the matter is the way copyright
> works, but Chromium is under the Modified BSD License according to
> documentation I was able to find. If some files are not actually covered

For what is worth, what I learned with projects that don't follow the
Open Source Definition (I know that I shouldn't support this term here,
but I had to mention it) is that they mask their non-compliance behind a
license. Of course we don't intend to foster open source here, as this
project, having the goal to provide a package manager that is under the
GNU project, also aims to create a system distribution that follows the
GNU FSDG and uses such package manager

If the norm would be to only check the licenses, then we would have for
example, taken ages to figure out that the kernel source files from
upstream of GNU Linux-libre was/is non-free.

Having a requirement for a package to be first throughly reviewed
eliminates some of the possibility of having non-free functional data or
non-distributable non-functional data. It's not a perfect protection
(since the package in review might have implemented things from other
works that one of the reviewers might not be aware of).

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].


[1] https://directory.fsf.org/wiki/Talk:Chromium
[2] https://directory.fsf.org/wiki/Review:Chromium-REV-ID-1



signature.asc
Description: OpenPGP digital signature

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

[Brett Gilio]

Adonay Felipe Nogueira writes:

> Em 16/02/2019 12:18, Julie Marchant escreveu:
>> libre? The only argument I've seen on the matter is the way copyright
>> works, but Chromium is under the Modified BSD License according to
>> documentation I was able to find. If some files are not actually covered
>
> For what is worth, what I learned with projects that don't follow the
> Open Source Definition (I know that I shouldn't support this term here,
> but I had to mention it) is that they mask their non-compliance behind a
> license. Of course we don't intend to foster open source here, as this
> project, having the goal to provide a package manager that is under the
> GNU project, also aims to create a system distribution that follows the
> GNU FSDG and uses such package manager
>
> If the norm would be to only check the licenses, then we would have for
> example, taken ages to figure out that the kernel source files from
> upstream of GNU Linux-libre was/is non-free.
>
> Having a requirement for a package to be first throughly reviewed
> eliminates some of the possibility of having non-free functional data or
> non-distributable non-functional data. It's not a perfect protection
> (since the package in review might have implemented things from other
> works that one of the reviewers might not be aware of).
>
> 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].
>
>
> [1] https://directory.fsf.org/wiki/Talk:Chromium
> [2] https://directory.fsf.org/wiki/Review:Chromium-REV-ID-1

Adonay, thank you for taking the initiative here! I think this is a
needed step forward.

Brett Gilio

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

[Brett Gilio]

Brett Gilio writes:

> Adonay Felipe Nogueira writes:
>
>> Em 16/02/2019 12:18, Julie Marchant escreveu:
>>> libre? The only argument I've seen on the matter is the way copyright
>>> works, but Chromium is under the Modified BSD License according to
>>> documentation I was able to find. If some files are not actually covered
>>
>> For what is worth, what I learned with projects that don't follow the
>> Open Source Definition (I know that I shouldn't support this term here,
>> but I had to mention it) is that they mask their non-compliance behind a
>> license. Of course we don't intend to foster open source here, as this
>> project, having the goal to provide a package manager that is under the
>> GNU project, also aims to create a system distribution that follows the
>> GNU FSDG and uses such package manager
>>
>> If the norm would be to only check the licenses, then we would have for
>> example, taken ages to figure out that the kernel source files from
>> upstream of GNU Linux-libre was/is non-free.
>>
>> Having a requirement for a package to be first throughly reviewed
>> eliminates some of the possibility of having non-free functional data or
>> non-distributable non-functional data. It's not a perfect protection
>> (since the package in review might have implemented things from other
>> works that one of the reviewers might not be aware of).
>>
>> 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].
>>
>>
>> [1] https://directory.fsf.org/wiki/Talk:Chromium
>> [2] https://directory.fsf.org/wiki/Review:Chromium-REV-ID-1
>
> Adonay, thank you for taking the initiative here! I think this is a
> needed step forward.
>
> Brett Gilio

Also, maybe it would be of some help to involve somebody from the FSF to
be a neutral mediator on this process until we come to some reasonable
conclusion?

Marius,

I think you can probably go ahead and push that patch, knowing full well
that Bill warned a bug report will be filed against the Guix source tree
until such time that an audit concludes or Adonay's suggestion is
followed through with.

Bill,

What do you think here?

Brett Gilio

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

[Alex Griffin]

On Sat, Feb 16, 2019, at 7:48 PM, Adonay Felipe Nogueira wrote:
> If the norm would be to only check the licenses, then we would have for
> example, taken ages to figure out that the kernel source files from
> upstream of GNU Linux-libre was/is non-free.

The Linux kernel was included in GNU distributions until a concrete problem was 
identified, exactly the opposite of what is being demanded here. AFAICT Marius 
has expended quite a bit of effort to resolve every known problem with the 
package, and what is left is literally just FUD (fear, uncertainty, doubt).

-- 
Alex Griffin

Re: manage /boot/grub/grub.cfg without installing grub binaries to disk

[Raghav "RG" Gururajan]

@clement

This is the actual error.

/etc/config-fail.scm:9:0: error: extraneous field initializers 
(bootloader-configuration)

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Saturday, February 16, 2019 6:58 PM, Raghav "RG" Gururajan 
 wrote:

> Hi Clement!
> 

> The following is the error I got.
> 

> config-fail.scm:9:0: error: inherit: unbound variable
> hint: Did you forget a `use-modules' form?
> 

>  Original Message 
> On 14 Feb 2019, 13:07, Raghav "RG" Gururajan < raghavgurura...@protonmail.ch> 
> wrote:
> 

> > Hi Clement!
> > >
> > > Thanks! Will do.
> > >
> > > @Jack. Can you also try this and let me know. My system is running dd 
> > > command for 2TB HDD. So gonna take a while.
> > >
> > > Thanks!
> >  Original Message 
> > On 14 Feb 2019, 12:15, Clément Lassieur < clem...@lassieur.org> wrote:
> > 

> > > Hi Jack and Raghav,
> > > 

> > > Could you try this?
> > > 

> > > --8<---cut here---start->8---
> > > (bootloader-configuration
> > > (bootloader
> > > (bootloader
> > > (inherit grub-bootloader)
> > > (installer #~(const #t)
> > > --8<---cut here---end--->8---
> > > 

> > > Clément

publickey - raghavgururajan@protonmail.ch - 0xE1982130.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: manage /boot/grub/grub.cfg without installing grub binaries to disk

[Clément Lassieur]

Hi Raghav,

Raghav RG Gururajan  writes:

> @clement
>
> This is the actual error.
>
> /etc/config-fail.scm:9:0: error: extraneous field initializers 
> (bootloader-configuration)

Yes, you need to use the (gnu bootloader) module.

I actually use the (gnu) module as shown in the docs, which exports (gnu
bootloader) and some other stuff too.

Clément

> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Saturday, February 16, 2019 6:58 PM, Raghav "RG" Gururajan 
>  wrote:
>
>> Hi Clement!
>> 
>
>> The following is the error I got.
>> 
>
>> config-fail.scm:9:0: error: inherit: unbound variable
>> hint: Did you forget a `use-modules' form?
>> 
>
>>  Original Message 
>> On 14 Feb 2019, 13:07, Raghav "RG" Gururajan < 
>> raghavgurura...@protonmail.ch> wrote:
>> 
>
>> > Hi Clement!
>> > >
>> > > Thanks! Will do.
>> > >
>> > > @Jack. Can you also try this and let me know. My system is running dd 
>> > > command for 2TB HDD. So gonna take a while.
>> > >
>> > > Thanks!
>> >  Original Message 
>> > On 14 Feb 2019, 12:15, Clément Lassieur < clem...@lassieur.org> wrote:
>> > 
>
>> > > Hi Jack and Raghav,
>> > > 
>
>> > > Could you try this?
>> > > 
>
>> > > --8<---cut here---start->8---
>> > > (bootloader-configuration
>> > > (bootloader
>> > > (bootloader
>> > > (inherit grub-bootloader)
>> > > (installer #~(const #t)
>> > > --8<---cut here---end--->8---
>> > > 
>
>> > > Clément

Re: manage /boot/grub/grub.cfg without installing grub binaries to disk

[Raghav "RG" Gururajan]

@clement

Thanks! Btw, shouldn't the first line be "(boot loader 
(bootloader-configuration)" in the code snippet you sent??

 Original Message 
On 16 Feb 2019, 17:11, Clément Lassieur wrote:

> Hi Raghav,
>
> Raghav RG Gururajan  writes:
>
>> @clement
>>
>> This is the actual error.
>>
>> /etc/config-fail.scm:9:0: error: extraneous field initializers 
>> (bootloader-configuration)
>
> Yes, you need to use the (gnu bootloader) module.
>
> I actually use the (gnu) module as shown in the docs, which exports (gnu
> bootloader) and some other stuff too.
>
> Clément
>
>> Sent with ProtonMail Secure Email.
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Saturday, February 16, [2019 6](tel:20196):58 PM, Raghav "RG" Gururajan 
>>  wrote:
>>
>>> Hi Clement!
>>>
>>
>>> The following is the error I got.
>>>
>>
>>> config-fail.scm:9:0: error: inherit: unbound variable
>>> hint: Did you forget a `use-modules' form?
>>>
>>
>>>  Original Message 
>>> On 14 Feb [2019](tel:2019), 13:07, Raghav "RG" Gururajan < 
>>> raghavgurura...@protonmail.ch> wrote:
>>>
>>
>>> > Hi Clement!
>>> > >
>>> > > Thanks! Will do.
>>> > >
>>> > > @Jack. Can you also try this and let me know. My system is running dd 
>>> > > command for 2TB HDD. So gonna take a while.
>>> > >
>>> > > Thanks!
>>> >  Original Message 
>>> > On 14 Feb [2019](tel:2019), 12:15, Clément Lassieur < 
>>> > clem...@lassieur.org> wrote:
>>> >
>>
>>> > > Hi Jack and Raghav,
>>> > >
>>
>>> > > Could you try this?
>>> > >
>>
>>> > > --8<---cut here---start->8---
>>> > > (bootloader-configuration
>>> > > (bootloader
>>> > > (bootloader
>>> > > (inherit grub-bootloader)
>>> > > (installer #~(const #t)
>>> > > --8<---cut here---end--->8---
>>> > >
>>
>>> > > Clément

publickey - raghavgururajan@protonmail.ch - 0xE1982130.asc
Description: application/pgp-keys

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

[bill-auger]

On Sat, 16 Feb 2019 09:18:58 -0500 Julie wrote:
> In justice
> systems, we adopt an "innocent until proven guilty" system because you
> can't really prove innocence, only guilt.   

i wondered if someone would bring that up - 

there is a huge difference with this (and i have already made this
clear, BTW) - the default state for copyright is not "innocent" - the
default state is "no permission granted" - according to this analogy,
software is guilty until proven innocent under the existing copyright
laws - that is not something we can decide to re-interpret


On Sat, 16 Feb 2019 09:18:58 -0500 Julie wrote:
> As far as I know, and correct
> me if I'm wrong here, no one in the entire history of this claim  

yes they have - the original bug report noted several; and those were
said to be fixed


On Sat, 16 Feb 2019 09:18:58 -0500 Julie wrote:
> this, though, then it seems to me that the correct action to take
> would be to address that issue, if not upstream, then in a fork.  
 
i agree - at the very least, i would to see that original bug report
closed by the upstream - its continued presence is looms ominously and
dubiously

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

[bill-auger]

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

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

[bill-auger]

Alex -

you are really mis-characterizing the situation here - this really has
very little to do with chromium specifically - the problem is when some
FSDG distro decide for themselves that *any* program qualifies as "free
software" when the others have agreed that it does not - this plants the
seeds for an uncomfortable family fued which could be best avoided
i dont know that anyone really cares enough about this browser to
waste their time spreading FUD about it - we just want everyone to
agree whether it is "free software" or it is not, and for all FSDG
distros to endorse or OR reject as a unified group - whichever the case
may actually be is not central to the discussion

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

[bill-auger]

On Sat, 16 Feb 2019 17:33:21 +0100 Marius wrote:
> Do we have
> any reason to distrust what's written in the LICENSE file?  

based on your own account, you very explicitly distrust the code
released by those authors in terms of privacy - so why would you
implicitly trust it in terms of licensing - there seems to be a
disjunct in logic there

Re: Using GPG Subkeys with git/savannah

[Laura Lazzati]

Hi!
Thank you very much to all of you
I am playing with them :)
Regards :)
Laura

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

[Julie Marchant]

On 02/16/2019 08:37 PM, bill-auger wrote:
> On Sat, 16 Feb 2019 09:18:58 -0500 Julie wrote:
> yes they have - the original bug report noted several; and those were
> said to be fixed

Ah, perfect. Then the problem is solved, no? Those issues, as you say,
were fixed by the Chromium team (according to them, and since you don't
point to evidence that the problems remain, I assume that means they
don't), and the Ungoogled-Chromium project has apparently fixed all
other problems. Unless you are aware of another unaddressed problem,
that is.

> there is a huge difference with this (and i have already made this
> clear, BTW) - the default state for copyright is not "innocent" - the
> default state is "no permission granted" - according to this analogy,
> software is guilty until proven innocent under the existing copyright
> laws - that is not something we can decide to re-interpret

I already responded to this, but it appears it went past your radar for
some reason, or perhaps I just didn't make myself clear enough, so let
me restate it. I'll be talking about how copyright works, so let me just
state upfront that I'm not a lawyer and no one should take this as legal
advice.

Copyright is based on declarations. That is, when someone declares that
you are allowed to do something, as long as they are the rightful
copyright holder, you are allowed to do that thing. It's the same sort
of deal as any other permission you might have to get from someone else.
So what you need is proof of such a declaration of permission. That's
what license statements are for.

So looking at the Chromium source code tree, we see a number of text
files. Of particular note, you see a file called "LICENSE", which is
simply a copy of the Modified BSD License. It doesn't specify what files
it applies to, and obviously, there are files it doesn't. But the fact
that they label it this way strongly implies that Chromium is generally
speaking under that license. And when you look through files, that
assumption is reaffirmed with statements that look like this:

// Copyright 2017 The Chromium Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.

So given this, any differently-licensed file would be an exception, and
it would be very easy to point these exceptions out and then fix them.
The same is true of Linux, by the way, and apparently there was no
problem simply identifying proprietary pieces and removing them.

Hence, I think, if someone says they've produced a version of Chromium
with all freedom-related problems solved, and no one has any evidence to
the contrary, that version of Chromium should be accepted.

-- 
Julie Marchant
http://onpon4.github.io

Encrypt your emails with GnuPG:
https://emailselfdefense.fsf.org

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

[bill-auger]

Julie -

that was all just a long winded re-statement of the "we should always
trust the upstream blindly" argument - i think the Great Wise Old Gnu
would conclude that is a very unwise general policy; and especially
unwise when that particular upstream is well-known for its code being
non-FSDG free

[PATCH] shepherd: Delete the socket file upon exit.

[宋文武]

Yes, I have the 'rm /run/user/1000/shepherd/socket' workaround in my session
script too...

According to 'man 2 bind', the socket pathname should be deleted when no
longer required, so a patch to fix this bug:

>From f171f6adb2fc6ee3bf4d25378c2e7bba109b43d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Sun, 17 Feb 2019 11:27:28 +0800
Subject: [PATCH] shepherd: Delete the socket file upon exit.

Fixes .

* modules/shepherd.scm (call-with-server-socket): New procedure.
(main): Use it instead of 'open-server-socket'.
---
 modules/shepherd.scm | 65 ++--
 1 file changed, 39 insertions(+), 26 deletions(-)

diff --git a/modules/shepherd.scm b/modules/shepherd.scm
index e241e7a..314b989 100644
--- a/modules/shepherd.scm
+++ b/modules/shepherd.scm
@@ -49,6 +49,17 @@
   (listen sock 10)
   sock)))
 
+(define (call-with-server-socket file-name proc)
+  "Call PROC, passing it a listening socket at FILE-NAME and deleting the
+socket file at FILE-NAME upon exit of PROC.  Return the values of PROC."
+  (let ((sock (open-server-socket file-name)))
+(dynamic-wind
+  noop
+  (lambda () (proc sock))
+  (lambda ()
+(close sock)
+(delete-file file-name)
+
 
 ;; Main program.
 (define (main . args)
@@ -256,32 +267,34 @@
   ;; Get commands from the standard input port.
   (process-textual-commands (current-input-port))
   ;; Process the data arriving at a socket.
-  (let ((sock   (open-server-socket socket-file)))
-
-;; Possibly write out our PID, which means we're ready to accept
-;; connections.  XXX: What if we daemonized already?
-(match pid-file
-  ((? string? file)
-   (with-atomic-file-output pid-file
- (cute display (getpid) <>)))
-  (#t (display (getpid)))
-  (_  #t))
-
-(let next-command ()
-  (define (read-from sock)
-(match (accept sock)
-  ((command-source . client-address)
-   (setvbuf command-source (buffering-mode block) 1024)
-   (process-connection command-source))
-  (_ #f)))
-  (match (select (list sock) (list) (list) (if poll-services? 0.5 #f))
-(((sock) _ _)
- (read-from sock))
-(_
- #f))
-  (when poll-services?
-(check-for-dead-services))
-  (next-command)))
+  (call-with-server-socket
+   socket-file
+   (lambda (sock)
+
+ ;; Possibly write out our PID, which means we're ready to accept
+ ;; connections.  XXX: What if we daemonized already?
+ (match pid-file
+   ((? string? file)
+(with-atomic-file-output pid-file
+  (cute display (getpid) <>)))
+   (#t (display (getpid)))
+   (_  #t))
+
+ (let next-command ()
+   (define (read-from sock)
+ (match (accept sock)
+   ((command-source . client-address)
+(setvbuf command-source (buffering-mode block) 1024)
+(process-connection command-source))
+   (_ #f)))
+   (match (select (list sock) (list) (list) (if poll-services? 0.5 #f))
+ (((sock) _ _)
+  (read-from sock))
+ (_
+  #f))
+   (when poll-services?
+ (check-for-dead-services))
+   (next-command
 
 ;; Start all of SERVICES, which is a list of canonical names (FIXME?),
 ;; but in a order where all dependencies are fulfilled before we
-- 
2.19.2

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

[bill-auger]

On Sat, 16 Feb 2019 14:34:38 -0200 Alexandre wrote:
> Maybe you have actually completed the steps that were missing in the
> auditing or Chromium to conclude it's Free, or at least some of the
> remaining tasks can be checked off.

that would be something wonderful, indeed

nothing would please me more at this time than to declare chromium as
FSDG-free, to finally put this controversy behind us in the past, and
never to speak of chromium nor qt5-webengine nor electron again - never
again to devote precious time liberating and re-packaging yet another
KDE program, for such a trivial reason as the frivolous presumption,
that the year 2019, demands their 20 year old system monitor GUI to
embed it's own web browser

im not making this up - the 'kde-plasma-desktop' became un-installable
on parabola this week, for exactly that reason

it should not be surprising that most have been satisfied thus far, to
throw this insidious chromiumm/webengine/electron thing under the bus
and move on; but it cant stay that way forever - at some point, a real
solution will be imperative, as this "javascript-on-the-desktop" trend
continues to infect the system

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

[Julie Marchant]

On 02/16/2019 09:42 PM, bill-auger wrote:
> Julie -
> 
> that was all just a long winded re-statement of the "we should always
> trust the upstream blindly" argument - i think the Great Wise Old Gnu
> would conclude that is a very unwise general policy; and especially
> unwise when that particular upstream is well-known for its code being
> non-FSDG free

Just to repeat the disclaimer, I'm not a lawyer and none of this is
legal advice.

I don't see why you're bringing "trust" into this. I've been trying to
argue that it has nothing to do with the issue. If the copyright holder
of a work says you're allowed to use it under X conditions, you are.
There's no "trust" there. You can't say that someone is allowed to do X
and then claim later that they weren't *really* allowed to do X.

I feel like I already gave this analogy at some point, but it's like
your "trust" that Walmart permits you to enter the store and shop. You
don't demand proof that you're allowed to shop at Walmart; it's implied
by the fact that the doors are unlocked and the building is enticing you
to go in. Similarly, Walmart can't just retroactively claim you weren't
really allowed in, even though you obviously were, and have you arrested
for trespassing. No, because of the conditions, if a Walmart wants to
keep you out, you have to be specifically told that you're not welcome.
They can't just call the police one day and have you arrested for
trespassing. Ergo, you don't need "trust".

The same sort of thing would apply to a licensing situation like this.
If the Chromium team says that Chromium is under the Modified BSD
License, then it *is* under the Modified BSD License, unless a
particular file says otherwise. The same applies to ungoogled-chromium
and its maintainer.

-- 
Julie Marchant
http://onpon4.github.io

Encrypt your emails with GnuPG:
https://emailselfdefense.fsf.org

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

[bill-auger]

the difference there is that chromium is not one piece of software
written by one person or even one modestly sized team - it is a
conglomeration of perhaps 100s of different projects written by perhaps
1000s of authors - for some files, it may not actually be known who the
author is, never mind which license they chose, or when - the word
"trust" comes into play there, because it is not clear that any one
single person on the chromium team can honestly account for everything
in the code-base, much less to authoritatively vouch for all of the
authors and various licensing

it is a more reasonable argument to make for projects with a much,
much fewer number of files and many, many fewer devs; but i think a
program this size is far beyond the benefit of reasonable doubt - and,
of course, on the other hand, if the project had many fewer files and
many fewer devs, then a comprehensive audit would not be as absurdly
difficult - so i think that is a moot point in this case

per your analogy, this is more like the owners of one building giving
you permission to go anywhere in the city, because they believe that
every other building in the city shares their trespassing policy -
though, they can not themselves, demonstrate that they have precise
knowledge of the exact number of buildings in the city, nor who their
owners are, nor their owners' trespassing policies

o/c someone could probably raise exactly the same doubts about mozilla -
luckily for us though, we are not aware of any, and so are not yet so
uncomfortably compelled to address them

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

if we can not all agree on how to interpret the FSDG, and apply it
uniformly to all distro, then the FSDG endorsement has no value and the
FSDG work-group serves no meaningful purpose to the world - we may as
well just go our own separate ways, and satisfy our own individual
fancies

that is what is truly at stake here - not this particular: "yet another
web browser"