[GNU-linux-libre] DSFG in perpetuity

[bill-auger]

i have been assuming that the FSDG is intended to be ongoing
requirements and not only a guide for initial consideration; and that
the post-review adfeno and i did last summer may have been the first,
not because it was unwelcome, but only because no one had yet taken the
initiative to do it

that being said, if the FSDG is to be applied perpetually; that puts
several such issues on the table presently:

* BLAG does not exist - this triggers multiple criteria ("Complete
Distro", "Actively maintained") - not that i want to see it go away; but
i think there should be, at the very least, some communication with it's
former maintainers regarding any future plans - if no one takes on it's
stewardship soon, then maybe it should be retired to a "historical
mention" category

* no one associated with proteanos answers the mailing list or
participates in the distro's IRC channel; which still has a few
straggling users that have not seen the maintainer in many months
(perhaps a year now) - as with BLAG, i wrote to the mailing list asking
about its future and got no response - i do think "Actively maintained"
should be read to imply "answer your email" or "join you own IRC channel
once in a while"

* ututo completely uprooted their distro from a gentoo to a ubuntu base
- should the new release be subject to a fresh review? or grandfathered
in on good faith?

* pureos has a long-standing open request to remove chromium in
solidarity with the other FSDG distros - that issue is o/c a separate
can of worms; but i think all distros should be projecting a uniform
message, however vague the circumstance, until such controversies are
resolved - or *at the very least*, all distros affected by the
controversy should be participating in the discussions on this list

* then, the other can of worms regarding the debian kernel - if this is
what has been preventing connochaetos from being endorsed, then pureos
and any future candidates should be held to that same standard without
exception - again, at the very least, all distros affected by the
controversy should be expected to participate in the discussion on this list

admittedly, i have been kicking pureos a lot lately - mainly because i
have been hoping to see someone from pureos defend it - it seems quite
clear to me that no one from pureos is reading this list - i would
propose that one of the FSDG requirements should be for each distro to
elect a delegate to follow, if not actively participate in the
discussions on this list on behalf of the distro - and ideally, to stand
uniformly with the greater community in the grey areas of the FSDG such
as the current chromium issue and the debian kernel

[Jason Self]

I don't understand the desire to boot distros off over how
"maintained" they are. (Like how often releases happen, etc.) Both
Blag and Ututo have been removed before. That can be seen in the log
from the version control system [0]. One of the cited reasons, for
Blag, was "it was last updated in 2011." My recollection for Ututo is
that it was along similar lines. But, as you can see, they were both
re-added (you can check the version control system log for that.)

My recollection of why they were put back is that the notion of if a
distro was actively maintained or not was supposed to be based on how
the maintainers of the distro classified it and not on some
externally-measurable thing like when the last release was, how
current the program versions are, or whatever. This allows, for
example, for distros that are slow-moving because of a lack of people
power to not find themselves kicked off the list because of a
popularity contest. And that's exactly what it would become: "I'm
sorry, but there are more people helping with Distro X and not Distro
Y so Distro Y hasn't been making much progress and hasn't had a
release in a while so you're gone." It's not supposed to be a
popularity contest and, if anything, slower-moving distros that have
less people power probably need more help than the more active &
popular ones do rather than condemnation and a push to remove them.

Distros are expected to fix freedom problems but I don't know that the
FSDG can be read that a distro must provide support to its users
beyond providing for a way to report freedom problems.

Your question of "should the new release be subject to a fresh review
or grandfathered in on good faith" seems very similar to what you
asked in the other thread. And so that brings up all of those same
responses I wrote. There's no reason someone can't go do a review of
any FSF-endorsed distro. I think the reason that they're not done is a
lack of people power. Please feel free to start a review of Ututo or
any other one. I don't have the free time to do that myself right now
but I'm not going to stop anyone else that wants to do.

AFAIK, no one has done the deep-dive into Chromium needed to make a
determination one way or the other. I don't think there's any harm in
distros removing Chromium (or any particular thing) if they want to --
after all, I don't think the FSDG can be read to compel any particular
distro to carry any particular program -- but at the same time if a
distro wants to instead wait until a particular issue has been
properly researched and confirmed as valid so as to avoid
unnecessarily removing packages only to put them back in later, I
don't see how that would not be FSDG compliant. Especially on a large
program like Chromium where much effort is required. The GNU Bucks
program, for example, conditions getting the Buck not merely on
*allegation* of a problem but "after the maintainer has confirmed that
the bug is valid." Why not tie program removal to that same standard?
That still wouldn't prevent distros from going further if they elected
to. Like it doesn't require distros to remove programs over patent
problems or require that non-functional data (I'm thinking wallpapers,
etc.) be under a free culture license but at the same time it wouldn't
prevent a distro from having such a policy either.

Post by bill-auger
admittedly, i have been kicking pureos a lot lately - mainly because
i have been hoping to see someone from pureos defend it - it seems
quite clear to me that no one from pureos is reading this list - i
would propose that one of the FSDG requirements should be for each
distro to elect a delegate to follow, if not actively participate in
the discussions on this list on behalf of the distro

That does seem a good idea.

[0]
http://web.cvs.savannah.gnu.org/viewvc/www/www/distros/free-distros.html?view=log

[bill-auger]

Post by Jason Self
I don't understand the desire to boot distros off over how
"maintained" they are.

before i read the rest of this - my desire is not to kick any off - i
only am trying to clarify the grey areas

"actively maintained" is one of the criteria - so what does that entail
exactly? - surely, at the very least, "it must still exist"? and "there
must be some indication that a human maintainer still exists"

[Julie Marchant]

Post by Jason Self
My recollection of why they were put back is that the notion of if a
distro was actively maintained or not was supposed to be based on how
the maintainers of the distro classified it and not on some
externally-measurable thing like when the last release was, how
current the program versions are, or whatever. This allows, for
example, for distros that are slow-moving because of a lack of people
power to not find themselves kicked off the list because of a
popularity contest. And that's exactly what it would become: "I'm
sorry, but there are more people helping with Distro X and not Distro
Y so Distro Y hasn't been making much progress and hasn't had a
release in a while so you're gone." It's not supposed to be a
popularity contest and, if anything, slower-moving distros that have
less people power probably need more help than the more active &
popular ones do rather than condemnation and a push to remove them.

I sent an email to this list not too long ago suggesting a set of rules
for determining if a distro is considered to be current or not. Let's see...

Ah, here it is:

http://lists.nongnu.org/archive/html/gnu-linux-libre/2018-01/msg00011.html

I suggested the following rules:

1. The distro's maintainers should annually do one of the following: (a)
publish a new release; (b) publish a post summarizing work done on the
distro in the prior year which directly impacts the distros users (for
example, such a post could note important packages which have been
updated in the current release and what these updates mean to the
users); (c) write to the FSF to explain why no updates have been
necessary in the respective year (and, in particular, why the security
and hardware compatibility implications of this are unimportant).

2. The distro should ensure one of the following: (a) that all known
security vulnerabilities are fixed for users of the current release of
the distro in a reasonable timeframe; (b) that new, non-technical users
of the distro can see that it has or may have security vulnerabilities,
e.g. via a warning on the distro's website that security updates are not
always delivered.

3. The distro should either: (a) be reasonably expected to be compatible
with computers that can currently be bought from mainstream retailers;
(b) indicate on its website what hardware it is compatible with.

I came up with this set of rules to address specific potential concerns:

* Concerns that the FSF may be recommending distros that are useless due
to use of very old software.
* Concerns that the FSF may be recommending distros that are unsafe to use.
* Concerns that the FSF may be recommending distros that don't work on
modern hardware, due to reliance on a very old version of Linux.
* Concerns that addressing these other concerns would cause distros that
don't need frequent updates to be unfairly affected.

I understand the idea that shafting unpopular distros is undesirable,
but the FSF's list is supposed to serve a particular purpose: to suggest
distros for users to use. If a suggestion is for a distro that is
vulnerable and never updated (e.g. BLAG), a user goes with that
suggestion, and that user gets their credit card information stolen
because of some really old vulnerability, who do you think they're going
to blame? BLAG, possibly, but also the FSF for recommending it in the
first place.

[bill-auger]

geez, these reactions like: "condemnation" and "punishment" - im really
only addressing the most extreme (stick a fork in it) cases here - i did
not realize any were ever demoted for any reason for any period of time
in the past - that is really all i hoped to establish as a baseline for

Post by Jason Self
Distros are expected to fix freedom problems but I don't know that the
FSDG can be read that a distro must provide support to its users
beyond providing for a way to report freedom problems.

sure, BLAG and proteanos do have mailing lists on which freedom problems
could be reported - but they are quite pointless if the maintainers do
not read their mail

Post by Jason Self
The GNU Bucks
program, for example, conditions getting the Buck not merely on
*allegation* of a problem but "after the maintainer has confirmed that
the bug is valid." Why not tie program removal to that same standard?

well, because i am of the mind that software should be considered
non-free until proven otherwise - and probably a court would agree if it
ever came to that - so such a program probably should have never gotten
into a FSDG distro the first place if it has never been established as
being distributable - one should hope that the question of whether or
not a program is freely licensed is something objectively verifiable and
in fact verified; rather than something to be subjectively decided by
the each downstream

i have said it again and again: i dont care what the actual answer is in
this case - i just want everyone to agree what the answer is

but if that is impossible to determine objectively, then the size of
this program IS itself it's own worst problem; justifying, on that fact
alone, not to provide this opaque behemoth to users - if no one
(including it's own maintainers) can so much as determine the licensing
of such a massive program; then HTF can anyone be confident enough to
endorse what the executable code may or may not do once running on the
users machine?

[bill-auger]

Post by Jason Self
Please feel free to start a review of Ututo or
any other one.

ok - that is precisely the intention of this thread to determine if such
a review were done and if there were blatent problems then would
anything actually be done about that situation

im glad you said this because i have been biting my tongue on speaking
to that point - i regret that i must spell this out so blatantly but we
did such a post review last summer and still, to this day, not one iota
of my findings has been addressed or even acknowledged publicly by
anyone with the authority to do anything about them - (i qualified that
with "publicly" because i think donald did thank me privately) - the
community was vocally pleased that we did it; but nothing actually came
of it

as julie pointed out though, some lengthy discussion did result
regarding opinions on defunct or possibly "dangerous" distros ;) - but
the website still says that ututo is a gentoo derivative - that has been
false information for a long time - that was the only attention that was
required for which no discussion was necessary - a ten-second task ...
delete the words "based on Gentoo" - but no one has

and i hope i do not appear to be griping - people are busy ... ok fine -
i like to be busy too - but very practically speaking, if people are too
busy to address the problems then there is little point in looking for them

so most of the items i raised in this thread are those items still
dangling from last summer - the new public workflow protocol for
evaluations is very encouraging; but it is not at all obvious that
ongoing reviews will receive due attention - that is why i am drawing
this out so painfully and plainly now

that being said, i was not really asking if a new review of the new
ututo was acceptable or welcome as such - i was asking more strongly
*should it* be made the policy for it (and any other) to be subjected to
a fresh review on the justification that it is technically an entirely
different distro than the one that was originally endorsed - or is it
reasonable to blindly endorse forevermore, anything they publish under
the same name, purely on good faith

[Robert Call]

Post by bill-auger
i have been assuming that the FSDG is intended to be ongoing
requirements and not only a guide for initial consideration; and that
the post-review adfeno and i did last summer may have been the first,
not because it was unwelcome, but only because no one had yet taken the
initiative to do it
...
admittedly, i have been kicking pureos a lot lately - mainly because i
have been hoping to see someone from pureos defend it - it seems quite
clear to me that no one from pureos is reading this list - i would
propose that one of the FSDG requirements should be for each distro to
elect a delegate to follow, if not actively participate in the
discussions on this list on behalf of the distro - and ideally, to stand
uniformly with the greater community in the grey areas of the FSDG such
as the current chromium issue and the debian kernel

Some of the issues mentioned are critical issues, but not all of them.
I don't think kicking distros off the list is a good approach (unless
they show they are not willing to fix real freedom issues). As for
kicking distros that don't release frequently, a better approach might
be to get them the help they need instead of punishing them. Writing
press releases or reaching out in our networks to find people wiling to
help would make a world of difference instead of shrinking the choices
of libre distros.

--
Robert Call (Bob)
***@bobcall.me
https://librecmc.org

[bill-auger]

Post by Robert Call
I don't think kicking distros off the list is a good approach (unless
they show they are not willing to fix real freedom issues). As for
kicking distros that don't release frequently, a better approach might
be to get them the help they need instead of punishing them.

i hear ya, bob - i dont intend any disrespect to anyone - as for these
current examples. i would not see it as punishing anyone - just to avoid
recommending distros that can not attend to their users needs for
whatever reason

as for BLAG, it is not so much that they have not released recently; but
it actually does not exist - both the distro and its maintainers seem to
have evaporated

and as for proteanos, if no one reads their mailing list, or
communicates with their community in any way, then surely that qualifies
as "not willing"

i agree that it would be better if they could get help - i have
expressed the sentiment recently that it would have been better for
pureos to offer help to gnewsense instead of launching a new brand - but
in any case, before anyone could offer help, the current maintainers
first need to be contacted and asked if they want help - and for that to
happen, they need to answer their mail or, at least, read this list

i am not at all the type to just "throw it over the fence" and say:
"*someone* should really do that thing" - i could probably be convinced
to take over BLAG myself if i thought that anyone actually wanted to use
it - i sent another message to the BLAG mailing list today to ask
someone to join this discussion regarding their possible removal - so
what to do if no one from the project as much as offers to defend it's
very existence? is it really worth endorsing further?

o/c *all* of these distros could use more help - a counter-point could
easily be made that there are too many now for the small number of
maintainers that are keeping them all going - and that it would be
healthier to merge a few of them

on the other hand, there are new ones coming in now - even if several of
them merged or were demoted now, it would still be a net gain in the
number of distros over the course of the next year

[Zlatan Todoric]

Post by bill-auger
* pureos has a long-standing open request to remove chromium in
solidarity with the other FSDG distros - that issue is o/c a separate
can of worms; but i think all distros should be projecting a uniform
message, however vague the circumstance, until such controversies are
resolved - or *at the very least*, all distros affected by the
controversy should be participating in the discussions on this list

You have our tracker to comment on that and can't expect us to be all
the time everywhere, especially not on list that proved itself as a
bashing field. We do read it, we just don't jump anymore in discussions
here as they tend to go south for various reasons that I don't want to
spend time nor energy on it. Simply removing chromium is a disservice
for average user and it shouldn't be a task taken easily. Also, while it
would nice for distros to have solidarity with each other, that is not
happening and PureOS is often taken into hostage situation most likely
because it is funded by Purism which in my opinion should be celebrated
that one commercial company is willing to put funds into such project
and not the other way around. I have now fully requested removal and
blockade of chromium package but next time please go to our bugtracker
and report a bug there and start discussion (we are actively working on
PureOS. Also all current PureOS staff are Debian Developers as well, we
also have other duties so you can't take against us that we have lack of
time and energy to be everywhere).

https://tracker.pureos.net/T57

Post by bill-auger
* then, the other can of worms regarding the debian kernel - if this is
what has been preventing connochaetos from being endorsed, then pureos
and any future candidates should be held to that same standard without
exception - again, at the very least, all distros affected by the
controversy should be expected to participate in the discussion on this list

Debian kernel itself is entirely free but there was issues with messages
that was brought to us and we worked on it both in PureOS and Debian at
same time.

https://tracker.pureos.net/T362

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888405

Post by bill-auger
admittedly, i have been kicking pureos a lot lately - mainly because i
have been hoping to see someone from pureos defend it - it seems quite
clear to me that no one from pureos is reading this list - i would
propose that one of the FSDG requirements should be for each distro to
elect a delegate to follow, if not actively participate in the
discussions on this list on behalf of the distro - and ideally, to stand
uniformly with the greater community in the grey areas of the FSDG such
as the current chromium issue and the debian kernel

Kicking PureOS is just doing disfavor to what are you trying - if you
kick me don't expect me to be nice, that is not how things work
especially in volunteer based projects. You are also doing false
assumptions and that is again bringing me to first point - this list is
toxic for no reason, if you can't work nicely you shouldn't work at all.
You have bug tracker for PureOS if you want to work with PureOS
community and not stretch us on dozen of sides.

Z

[Robert Call]

Post by Zlatan Todoric

Post by bill-auger
* pureos has a long-standing open request to remove chromium in
solidarity with the other FSDG distros - that issue is o/c a
separate
can of worms; but i think all distros should be projecting a
uniform
message, however vague the circumstance, until such controversies are
resolved - or *at the very least*, all distros affected by the
controversy should be participating in the discussions on this list

You have our tracker to comment on that and can't expect us to be all
the time everywhere, especially not on list that proved itself as a
bashing field. We do read it, we just don't jump anymore in
discussions
here as they tend to go south for various reasons that I don't want to
spend time nor energy on it. Simply removing chromium is a disservice
for average user and it shouldn't be a task taken easily. Also, while it
would nice for distros to have solidarity with each other, that is not
happening and PureOS is often taken into hostage situation most likely
because it is funded by Purism which in my opinion should be
celebrated
that one commercial company is willing to put funds into such project
and not the other way around. I have now fully requested removal and
blockade of chromium package but next time please go to our
bugtracker
and report a bug there and start discussion (we are actively working on
PureOS. Also all current PureOS staff are Debian Developers as well, we
also have other duties so you can't take against us that we have lack of
time and energy to be everywhere).
https://tracker.pureos.net/T57

Post by bill-auger
* then, the other can of worms regarding the debian kernel - if this is
what has been preventing connochaetos from being endorsed, then pureos
and any future candidates should be held to that same standard without
exception - again, at the very least, all distros affected by the
controversy should be expected to participate in the discussion on this list

Debian kernel itself is entirely free but there was issues with messages
that was brought to us and we worked on it both in PureOS and Debian at
same time.
https://tracker.pureos.net/T362
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888405

Post by bill-auger
admittedly, i have been kicking pureos a lot lately - mainly
because i
have been hoping to see someone from pureos defend it - it seems quite
clear to me that no one from pureos is reading this list - i would
propose that one of the FSDG requirements should be for each distro to
elect a delegate to follow, if not actively participate in the
discussions on this list on behalf of the distro - and ideally, to stand
uniformly with the greater community in the grey areas of the FSDG such
as the current chromium issue and the debian kernel

Kicking PureOS is just doing disfavor to what are you trying - if you
kick me don't expect me to be nice, that is not how things work
especially in volunteer based projects. You are also doing false
assumptions and that is again bringing me to first point - this list is
toxic for no reason, if you can't work nicely you shouldn't work at all.
You have bug tracker for PureOS if you want to work with PureOS
community and not stretch us on dozen of sides.

Yelling "this list is toxic" does not help you or anyone else. Both
Purism and PureOS did this to themselves with the long list of problems
from the start. While I don't agree with Bill's stance, I would say
that more time is needed to get over these issues. Being entailed and
asserting that everyone must forgive you for past issues right now is
not going to get you very far and you must have the patience.

Many of us are willing to forgive PureOS and Purism for past issues,
but it is going to take more time for Purism and PureOS to show they
are dedicated to the Free Software movement. Many of us in the Free
Software community are still concerned about some of the current
actions and behavior of Purism and the lack of community around PureOS.

If you are wanting to fix these issues, it is going to take time and I
encourage Purism and the PureOS team to reach out to those who have
been a part of the Free Software community for a while instead of
making guesses and taking a few stabs in the dark. Many of us have been
doing this for a long time and we have the wounds to show for it. If in
doubt, reach out.


--
Robert Call (Bob)
***@librecmc.org
https://librecmc.org

[Zlatan Todoric]

Post by Robert Call

Post by Zlatan Todoric

Post by bill-auger
* pureos has a long-standing open request to remove chromium in
solidarity with the other FSDG distros - that issue is o/c a
separate
can of worms; but i think all distros should be projecting a
uniform
message, however vague the circumstance, until such controversies are
resolved - or *at the very least*, all distros affected by the
controversy should be participating in the discussions on this list

You have our tracker to comment on that and can't expect us to be all
the time everywhere, especially not on list that proved itself as a
bashing field. We do read it, we just don't jump anymore in
discussions
here as they tend to go south for various reasons that I don't want to
spend time nor energy on it. Simply removing chromium is a disservice
for average user and it shouldn't be a task taken easily. Also, while it
would nice for distros to have solidarity with each other, that is not
happening and PureOS is often taken into hostage situation most likely
because it is funded by Purism which in my opinion should be
celebrated
that one commercial company is willing to put funds into such project
and not the other way around. I have now fully requested removal and
blockade of chromium package but next time please go to our
bugtracker
and report a bug there and start discussion (we are actively working on
PureOS. Also all current PureOS staff are Debian Developers as well, we
also have other duties so you can't take against us that we have lack of
time and energy to be everywhere).
https://tracker.pureos.net/T57

Post by bill-auger
* then, the other can of worms regarding the debian kernel - if this is
what has been preventing connochaetos from being endorsed, then pureos
and any future candidates should be held to that same standard without
exception - again, at the very least, all distros affected by the
controversy should be expected to participate in the discussion on this list

Debian kernel itself is entirely free but there was issues with messages
that was brought to us and we worked on it both in PureOS and Debian at
same time.
https://tracker.pureos.net/T362
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888405

Post by bill-auger
admittedly, i have been kicking pureos a lot lately - mainly
because i
have been hoping to see someone from pureos defend it - it seems quite
clear to me that no one from pureos is reading this list - i would
propose that one of the FSDG requirements should be for each distro to
elect a delegate to follow, if not actively participate in the
discussions on this list on behalf of the distro - and ideally, to stand
uniformly with the greater community in the grey areas of the FSDG such
as the current chromium issue and the debian kernel

Kicking PureOS is just doing disfavor to what are you trying - if you
kick me don't expect me to be nice, that is not how things work
especially in volunteer based projects. You are also doing false
assumptions and that is again bringing me to first point - this list is
toxic for no reason, if you can't work nicely you shouldn't work at all.
You have bug tracker for PureOS if you want to work with PureOS
community and not stretch us on dozen of sides.

Yelling "this list is toxic" does not help you or anyone else. Both
Purism and PureOS did this to themselves with the long list of problems
from the start. While I don't agree with Bill's stance, I would say
that more time is needed to get over these issues. Being entailed and
asserting that everyone must forgive you for past issues right now is
not going to get you very far and you must have the patience.

Your behavior is again not acceptable - you're assuming I am yelling and
yet proving the toxicity. While Purism did make claims it could not
stand to it in timeframe it wanted, Purism is still moving thing slowly
forward and even has constitution to defend such stand. Issues you have
with Purism are not part of PureOS and I mentioned Purism only in
context that PureOS gets bashed basically because Purism is behind it.
There is no far or patience part - we went through process, been there
for 2 years, got accepted as endorsed and are committed to it - that has
nothing to do with your or other feelings.

To speak more to topic part - we were pointed to parts for being an
endorsed distro and one is being actively maintained to be accepted, and
that is a good requirement. Being un-maintained is disservice to users
and a security risk as well and such distro should be promoted as new
user will get into trouble and maybe end up blaming FSF and other
distros. PureOS is actively maintained with public bugtracker so bring
your technical issues there.

Post by Robert Call
Many of us are willing to forgive PureOS and Purism for past issues,
but it is going to take more time for Purism and PureOS to show they
are dedicated to the Free Software movement. Many of us in the Free
Software community are still concerned about some of the current
actions and behavior of Purism and the lack of community around PureOS.

We are not here to beg or get your forgiveness, that has nothing to do
with PureOS and we already showed our dedication to the movement in many
ways, but you can ignore it and continue bashing. The issues you see,
please raise but I am aware of lack of community which is also issue for
us - we want to have active community around it and we are already
internally in final process of having community mails with fine-grained
access and permissions to PureOS (and wider Purism) infrastructure. This
should be publicly announced in April most likely (I wanted this couple
of months ago but there are other pressing issues all the time).

Post by Robert Call
If you are wanting to fix these issues, it is going to take time and I
encourage Purism and the PureOS team to reach out to those who have
been a part of the Free Software community for a while instead of
making guesses and taking a few stabs in the dark. Many of us have been
doing this for a long time and we have the wounds to show for it. If in
doubt, reach out.

Reach out what exactly? We will reach out for community activity for
sure but I don't understand your tone - we already passed the distro
review, you can either help us get better (as being an active Free
distro is going to be always WIP) or try to fix review process if you
feel unhappy about it. Many of us in Purism are also long time community
members (decades and decades of experience) and we have also wounds but
don't go around and dictate others how and what should they do. If in
doubt - use the public bugtracker.

Z

[Robert Call]

Post by Zlatan Todoric

Post by Robert Call

Post by Zlatan Todoric

Post by bill-auger
* pureos has a long-standing open request to remove chromium in
solidarity with the other FSDG distros - that issue is o/c a separate
can of worms; but i think all distros should be projecting a uniform
message, however vague the circumstance, until such
controversies
are
resolved - or *at the very least*, all distros affected by the
controversy should be participating in the discussions on this list

You have our tracker to comment on that and can't expect us to be all
the time everywhere, especially not on list that proved itself as a
bashing field. We do read it, we just don't jump anymore in discussions
here as they tend to go south for various reasons that I don't
want
to
spend time nor energy on it. Simply removing chromium is a
disservice
for average user and it shouldn't be a task taken easily. Also,
while
it
would nice for distros to have solidarity with each other, that
is
not
happening and PureOS is often taken into hostage situation most likely
because it is funded by Purism which in my opinion should be celebrated
that one commercial company is willing to put funds into such project
and not the other way around. I have now fully requested removal and
blockade of chromium package but next time please go to our bugtracker
and report a bug there and start discussion (we are actively
working
on
PureOS. Also all current PureOS staff are Debian Developers as
well,
we
also have other duties so you can't take against us that we have
lack
of
time and energy to be everywhere).
https://tracker.pureos.net/T57

Post by bill-auger
* then, the other can of worms regarding the debian kernel - if this is
what has been preventing connochaetos from being endorsed, then pureos
and any future candidates should be held to that same standard without
exception - again, at the very least, all distros affected by the
controversy should be expected to participate in the discussion
on
this list

Debian kernel itself is entirely free but there was issues with messages
that was brought to us and we worked on it both in PureOS and
Debian
at
same time.
https://tracker.pureos.net/T362
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888405

Post by bill-auger
admittedly, i have been kicking pureos a lot lately - mainly because i
have been hoping to see someone from pureos defend it - it
seems
quite
clear to me that no one from pureos is reading this list - i would
propose that one of the FSDG requirements should be for each
distro
to
elect a delegate to follow, if not actively participate in the
discussions on this list on behalf of the distro - and ideally,
to
stand
uniformly with the greater community in the grey areas of the
FSDG
such
as the current chromium issue and the debian kernel

Kicking PureOS is just doing disfavor to what are you trying - if you
kick me don't expect me to be nice, that is not how things work
especially in volunteer based projects. You are also doing false
assumptions and that is again bringing me to first point - this
list
is
toxic for no reason, if you can't work nicely you shouldn't work
at
all.
You have bug tracker for PureOS if you want to work with PureOS
community and not stretch us on dozen of sides.

Yelling "this list is toxic" does not help you or anyone else. Both
Purism and PureOS did this to themselves with the long list of problems
from the start. While I don't agree with Bill's stance, I would say
that more time is needed to get over these issues. Being entailed and
asserting that everyone must forgive you for past issues right now is
not going to get you very far and you must have the patience.

Your behavior is again not acceptable - you're assuming I am yelling
and yet proving the toxicity.

What behavior are you talking about? This is the first time I have
really made any statements in regards to Purism or PureOS. I kept quiet
on most issues even when I wanted to speak up. Is it toxic to work
towards a certain goal and not make compromises on that goal? Taring
and feathering me is not helping. I would go further and ask what other
buzz words are you going to throw at or call me?

Post by Zlatan Todoric
While Purism did make claims it could not
stand to it in timeframe it wanted, Purism is still moving thing slowly
forward and even has constitution to defend such stand. Issues you have
with Purism are not part of PureOS and I mentioned Purism only in
context that PureOS gets bashed basically because Purism is behind it.

What more did you expect when a project is started by a parent company
and pushed for a discrete nvidia GPU for their crowdfunding campaign?
Had it been a truly independent project, that would not have happened.
Projects associated with a parent company always carry the baggage of
the parent company.

Post by Zlatan Todoric
There is no far or patience part - we went through process, been there
for 2 years, got accepted as endorsed and are committed to it - that has
nothing to do with your or other feelings.

"Feelings" are not a part of this. It is about building trust. Trust is
easier to break than it is to build and it takes time. You are not
going to convince many people that you are committed if you smear them
or can't understand that it takes time to build trust. No matter what
one does, it can't be rush or forced.

Post by Zlatan Todoric
To speak more to topic part - we were pointed to parts for being an
endorsed distro and one is being actively maintained to be accepted, and
that is a good requirement. Being un-maintained is disservice to users
and a security risk as well and such distro should be promoted as new
user will get into trouble and maybe end up blaming FSF and other
distros. PureOS is actively maintained with public bugtracker so bring
your technical issues there.

Post by Robert Call
Many of us are willing to forgive PureOS and Purism for past
issues,
but it is going to take more time for Purism and PureOS to show they
are dedicated to the Free Software movement. Many of us in the Free
Software community are still concerned about some of the current
actions and behavior of Purism and the lack of community around PureOS.

We are not here to beg or get your forgiveness, that has nothing to do
with PureOS and we already showed our dedication to the movement in many
ways, but you can ignore it and continue bashing.

I'm not going to bash it just because. I work on a basis of proof and
if I see an issue, I'm going to talk about it. I also don't want to
compromise on freedom.

Post by Zlatan Todoric
The issues you see,
please raise but I am aware of lack of community which is also issue for
us - we want to have active community around it and we are already
internally in final process of having community mails with fine-
grained
access and permissions to PureOS (and wider Purism) infrastructure. This
should be publicly announced in April most likely (I wanted this couple
of months ago but there are other pressing issues all the time).

Post by Robert Call
If you are wanting to fix these issues, it is going to take time and I
encourage Purism and the PureOS team to reach out to those who have
been a part of the Free Software community for a while instead of
making guesses and taking a few stabs in the dark. Many of us have been
doing this for a long time and we have the wounds to show for it. If in
doubt, reach out.

Reach out what exactly? We will reach out for community activity for
sure but I don't understand your tone - we already passed the distro
review, you can either help us get better (as being an active Free
distro is going to be always WIP) or try to fix review process if you
feel unhappy about it. Many of us in Purism are also long time
community
members (decades and decades of experience) and we have also wounds but
don't go around and dictate others how and what should they do. If in
doubt - use the public bugtracker.

Purism did not reach out about freedom issues with certain hardware and
as a result, some hardware sold (and promised) stopped working a result
of removing firmware. This would not have happened had Purism and
PureOS consulted people who have been working in these areas and care
about non-free software and blobs. The same goes with the reason that
chromium is not a freedom respecting browser.

I want to give Purism and PureOS a chance to redeem themselves, but
personal attacks and smearing won't help bring people to your side or
PureOS as a community project. Getting upset when people point out a
fault won't help build a community. If you don't like my tone, I'm
sorry if text is not the best medium to talk about these issues in a
constructive way.


--
Robert Call (Bob)
***@librecmc.org
https://librecmc.org

[Zlatan Todoric]

Post by Robert Call

Post by Zlatan Todoric

Post by Robert Call

Post by Zlatan Todoric

Post by bill-auger
* pureos has a long-standing open request to remove chromium in
solidarity with the other FSDG distros - that issue is o/c a separate
can of worms; but i think all distros should be projecting a uniform
message, however vague the circumstance, until such
controversies
are
resolved - or *at the very least*, all distros affected by the
controversy should be participating in the discussions on this list

You have our tracker to comment on that and can't expect us to be all
the time everywhere, especially not on list that proved itself as a
bashing field. We do read it, we just don't jump anymore in
discussions
here as they tend to go south for various reasons that I don't
want
to
spend time nor energy on it. Simply removing chromium is a
disservice
for average user and it shouldn't be a task taken easily. Also,
while
it
would nice for distros to have solidarity with each other, that
is
not
happening and PureOS is often taken into hostage situation most likely
because it is funded by Purism which in my opinion should be celebrated
that one commercial company is willing to put funds into such project
and not the other way around. I have now fully requested removal and
blockade of chromium package but next time please go to our
bugtracker
and report a bug there and start discussion (we are actively
working
on
PureOS. Also all current PureOS staff are Debian Developers as
well,
we
also have other duties so you can't take against us that we have
lack
of
time and energy to be everywhere).
https://tracker.pureos.net/T57

Post by bill-auger
* then, the other can of worms regarding the debian kernel - if this is
what has been preventing connochaetos from being endorsed, then pureos
and any future candidates should be held to that same standard without
exception - again, at the very least, all distros affected by the
controversy should be expected to participate in the discussion
on
this list

Debian kernel itself is entirely free but there was issues with messages
that was brought to us and we worked on it both in PureOS and
Debian
at
same time.
https://tracker.pureos.net/T362
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888405

Post by bill-auger
admittedly, i have been kicking pureos a lot lately - mainly because i
have been hoping to see someone from pureos defend it - it
seems
quite
clear to me that no one from pureos is reading this list - i would
propose that one of the FSDG requirements should be for each
distro
to
elect a delegate to follow, if not actively participate in the
discussions on this list on behalf of the distro - and ideally,
to
stand
uniformly with the greater community in the grey areas of the
FSDG
such
as the current chromium issue and the debian kernel

Kicking PureOS is just doing disfavor to what are you trying - if you
kick me don't expect me to be nice, that is not how things work
especially in volunteer based projects. You are also doing false
assumptions and that is again bringing me to first point - this
list
is
toxic for no reason, if you can't work nicely you shouldn't work
at
all.
You have bug tracker for PureOS if you want to work with PureOS
community and not stretch us on dozen of sides.

Yelling "this list is toxic" does not help you or anyone else. Both
Purism and PureOS did this to themselves with the long list of problems
from the start. While I don't agree with Bill's stance, I would say
that more time is needed to get over these issues. Being entailed and
asserting that everyone must forgive you for past issues right now is
not going to get you very far and you must have the patience.

Your behavior is again not acceptable - you're assuming I am yelling
and yet proving the toxicity.

What behavior are you talking about? This is the first time I have
really made any statements in regards to Purism or PureOS. I kept quiet
on most issues even when I wanted to speak up. Is it toxic to work
towards a certain goal and not make compromises on that goal? Taring
and feathering me is not helping. I would go further and ask what other
buzz words are you going to throw at or call me?

I can't nor do I want to keep a personal list of people that pointed
fingers to PureOS without valid reasons (some used even Purism and its
hardware for trying to bash and block PureOS from getting endorsed). I
encourage you to keep working, but also and again for PureOS, please use
our tracker and assign such bugs to me so I get direct notification.

Post by Robert Call

Post by Zlatan Todoric
While Purism did make claims it could not
stand to it in timeframe it wanted, Purism is still moving thing slowly
forward and even has constitution to defend such stand. Issues you have
with Purism are not part of PureOS and I mentioned Purism only in
context that PureOS gets bashed basically because Purism is behind it.

What more did you expect when a project is started by a parent company
and pushed for a discrete nvidia GPU for their crowdfunding campaign?
Had it been a truly independent project, that would not have happened.
Projects associated with a parent company always carry the baggage of
the parent company.

I joined Purism after the mistake with nvidia and I agree it was a huge
mistake but doesn't entitle anyone to attack PureOS even when we are
trying to do right thing. We moved PureOS website and infra outside
Purism infra so it doesn't carry its baggage - PureOS is staying Free as
in Freedom, we just have continue to work on it and we need help as well
(everyone is invited to become PureOS developer, I have even took out my
free Sunday to continue writing policies around it).

Post by Robert Call

Post by Zlatan Todoric
There is no far or patience part - we went through process, been there
for 2 years, got accepted as endorsed and are committed to it - that has
nothing to do with your or other feelings.

"Feelings" are not a part of this. It is about building trust. Trust is
easier to break than it is to build and it takes time. You are not
going to convince many people that you are committed if you smear them
or can't understand that it takes time to build trust. No matter what
one does, it can't be rush or forced.

PureOS has its legacy from Debian main, so it was already good enough
and we just continued to make it more freedom respecting - it was never
compromised nor it ignored such requests. Purism is also dedicated to
Freedom of software and hardware but acknowledges that during that path
it might accept lost battle to move forward towards ultimate win -
believe it or not, we are here in same boat.

Post by Robert Call

Post by Zlatan Todoric
To speak more to topic part - we were pointed to parts for being an
endorsed distro and one is being actively maintained to be accepted, and
that is a good requirement. Being un-maintained is disservice to users
and a security risk as well and such distro should be promoted as new
user will get into trouble and maybe end up blaming FSF and other
distros. PureOS is actively maintained with public bugtracker so bring
your technical issues there.

Post by Robert Call
Many of us are willing to forgive PureOS and Purism for past
issues,
but it is going to take more time for Purism and PureOS to show they
are dedicated to the Free Software movement. Many of us in the Free
Software community are still concerned about some of the current
actions and behavior of Purism and the lack of community around PureOS.

We are not here to beg or get your forgiveness, that has nothing to do
with PureOS and we already showed our dedication to the movement in many
ways, but you can ignore it and continue bashing.

I'm not going to bash it just because. I work on a basis of proof and
if I see an issue, I'm going to talk about it. I also don't want to
compromise on freedom.

Neither do I - I joined Debian because the belief of freedom can be
achieved for everyone, I read and got to know about GNU because of
Debian, I became Debian Developer to continue spreading such message and
I assure you, as lead of PureOS, that PureOS is trying to do same but I
admit it is not fast as we want (there is only 4 of us working on PureOS
so again, please join, I am looking forward to more and more community
PureOS developers and eventually the core team to be one with majority
of community members and I am grateful that Purism is funding such
project entirely at this point).

Post by Robert Call

Post by Zlatan Todoric
The issues you see,
please raise but I am aware of lack of community which is also issue for
us - we want to have active community around it and we are already
internally in final process of having community mails with fine-
grained
access and permissions to PureOS (and wider Purism) infrastructure. This
should be publicly announced in April most likely (I wanted this couple
of months ago but there are other pressing issues all the time).

Post by Robert Call
If you are wanting to fix these issues, it is going to take time and I
encourage Purism and the PureOS team to reach out to those who have
been a part of the Free Software community for a while instead of
making guesses and taking a few stabs in the dark. Many of us have been
doing this for a long time and we have the wounds to show for it. If in
doubt, reach out.

Reach out what exactly? We will reach out for community activity for
sure but I don't understand your tone - we already passed the distro
review, you can either help us get better (as being an active Free
distro is going to be always WIP) or try to fix review process if you
feel unhappy about it. Many of us in Purism are also long time community
members (decades and decades of experience) and we have also wounds but
don't go around and dictate others how and what should they do. If in
doubt - use the public bugtracker.

Purism did not reach out about freedom issues with certain hardware and
as a result, some hardware sold (and promised) stopped working a result
of removing firmware. This would not have happened had Purism and
PureOS consulted people who have been working in these areas and care
about non-free software and blobs. The same goes with the reason that
chromium is not a freedom respecting browser.

Not sure to what are you referring here - I know that Todd contacted few
times FSF, even discussed things with RMS. If you are pointing to BT -
well yes, that is sad part of Linux hardware enablement in general but
hardly it can be done something better at this point. Note that due to
constitution, we are dedicated to liberate such piece of hardware or
find new one and write firmware/driver for it. It is a process, not an
static item and anyone with strong WiFi/BT linux kernel driver
knowledge, please feel free to PM me so we can see what can be done.

For chromium - I am not in favor for it and as stated I request complete
removal. The thing is - we must find more productive ways of this
because simply removing things means also we remove productivity for
many people (yes we have fork of Firefox but that is still not 100%
stable and some things work on chromium that don't work on Firefox and
vice versa).

Post by Robert Call
I want to give Purism and PureOS a chance to redeem themselves, but
personal attacks and smearing won't help bring people to your side or
PureOS as a community project. Getting upset when people point out a
fault won't help build a community. If you don't like my tone, I'm
sorry if text is not the best medium to talk about these issues in a
constructive way.

Purism made some choices in past that were not good but that doesn't
mean it ever had ill intentions, also you can't blame all the people in
company - we just work and try our best. Look at Purism constitution -
we made it on purpose so we can be held against it and also even with
investors, the constitution will stand there strongly. Purism puts
freedom (and the ultimate goal is freedom) in front of profit and PureOS
is all about freedom. I am not upset with people pointing on things - I
am upset with false assumption (that we don't read ML or ignore some
requests). I am not a person that likes to be in public, I work mostly
offline to not be distracted but I never ignore any freedom request - I
can at some point have more pressing issues (life, work) but I never
ignore.

Indeed, only reading text makes it hard to know how people intend it to
be (cultural backgrounds, tones in our head) but I will point one more
time - the easiest and most efficient way to get PureOS attention is to
use its public bugtracker (and feel free to mail me directly - whenever
I have time I will jump on IRC/Matrix/WebRTC/Mumble).

Z

[bill-auger]

Post by Zlatan Todoric
For chromium - I am not in favor for it and as stated I request complete
removal. The thing is - we must find more productive ways of this
because simply removing things means also we remove productivity for
many people (yes we have fork of Firefox but that is still not 100%
stable and some things work on chromium that don't work on Firefox and
vice versa).

ah welcome to the club - that is exactly the same predicament that
trisquel and parabola have been in for some time - i know that parabola
has had to drop a large number of programs because of this

if pureos users complain about it, do feel free to point them to this
thread on the fsd mailing list[1] - it lists most everything that is
known about the issue and how other distros have dealt with it - also
some small steps toward scrutinizing it

in case you did not know, this chromium controversy is nearly 10 years
old now and many people want it to be resolved one way or the other -
someone from the FSF even told me that RMS stated an interest recently
in resolving this; but it is a big task

to be clear, it is assumed that the issue pertains to all
chromium-derived browsers and libraries such as iridium, gupzilla,
qt5-webengine, and all electron "apps" such as riot, atom, and vscode -
one fedora developer has said that anything built on electron is
probably a hopeless cause; but a qt5-webengine on the list has stated
that they are interested and will fix any problems found even if the
upstream does not - that is encouraging because clients of qt5-webengine
account for the majority of blacklisted programs


[1]:
https://lists.gnu.org/archive/html/directory-discuss/2017-11/msg00003.html

[François Téchené]

Post by Robert Call
What more did you expect when a project is started by a parent company
and pushed for a discrete nvidia GPU for their crowdfunding campaign?
Had it been a truly independent project, that would not have happened.
Projects associated with a parent company always carry the baggage of
the parent company.

I think that there is some misunderstanding on what the Purism "plan" is
and has always been.

Purism has taken the problem in the other way around and I can
understand that it seems pretty confusing for freedom supporters.
Instead of starting from a fully free hardware, which is very limited in
choice, which requires a tremendous amount of resources to be improved,
and that is not always friendly to the average user, Purism has chosen
to start from a much more common hardware and work on freeing it.

Why doing that? Because nobody else has tried this approach yet and
because we think that it can succeed in being freedom respecting while
bringing freedom to the mass.

Bringing freedom to the mass is what, personally, bothers me the most. I
think that one very important aspect of a freedom respecting technology
is that it is not discriminating anyone, because there is no freedom on
something that one cannot access. A computer that is not matching the
average user's expectations (too technical, not convenient enough,
limited in resources) is discriminating a large part of the population,
no matter how much "educating" about free software we do. This is a fact
and it is not acceptable.

You may not agree with our vision but please, don't judge Purism on what
it started from but what it is going towards instead. See how the Librem
improved in term of freedom since its first version. We keep working on
freeing the BIOS, reverse engineering the remaining blobs and we push
all this work upstream to coreboot. Just like we push PureOS development
to Debian as much as we can. This is just a start. In the long term, we
would love to get enough financial resources to push the development of
truly free technologies like RISC V. Being RYF certified with convenient
modern hardware is on our road-map.

Again, you may no agree with our approach and you are free to have
different ideas on how to manufacture freedom respecting computers _for
everyone_ (I insist). In this case, go ahead, start a project or
contribute to an existing project that is aligned with your ideas and
prove that we were wrong because we may be.

At the end of the day, no matter who was wrong or right in the way to
get there as long as we manage to get there => "freedom for everyone"

Cheers,

[bill-auger]

Post by Zlatan Todoric
we already passed the distro
review, you can either help us get better
or try to fix review process if you
feel unhappy about it.

the assumption here seems to be that distros have no further obligation
after the initial review process, other than remaining active and fixing
bugs; but that is only two of the criteria - the very topic of this
thread is make it clear that the role of this group extends beyond the
initial review process; and holding the FSDG distros accountable to
*all* of the guidelines perpetually - with the invitation to all distros
to participate in the ongoing discussions that affect all

[Zlatan Todoric]

Post by bill-auger

Post by Zlatan Todoric
we already passed the distro
review, you can either help us get better
or try to fix review process if you
feel unhappy about it.

the assumption here seems to be that distros have no further obligation
after the initial review process, other than remaining active and fixing
bugs; but that is only two of the criteria - the very topic of this
thread is make it clear that the role of this group extends beyond the
initial review process; and holding the FSDG distros accountable to
*all* of the guidelines perpetually - with the invitation to all distros
to participate in the ongoing discussions that affect all

I don't have that assumption, being an endorsed distro doesn't mean one
should stop work on it - on contrary this is WIP forever and we are
determined to it to stay that way. Being active and fixing bugs is not
the only criteria but it is the most important ones IMHO - if a distro
isn't active it should be moved in some Inactive/Dormant section because
that distro is not doing anyone favor and is also a security nightmare.

I will also use this mail as reply to other mails - thanks for ongoing
discussion and I again recommend to move inactive distros to some other
section. For having the discussion, I agree that we can have (at least)
one representative from all endorsed distros but what I also propose is
- greater community will always discuss this (awesome) but sometimes
some distro people will not have time to participate in all discussions-
is  that someone from FSF (Donald?) CC's directly all current delegates
from active distros on topic that reached point of need to be discussed
and solved by distros (aka higher priority topic). That way (at least
for me) we will not be stretched on many sides but also such ping would
get our attention and bring us in into discussion. Thoughts?

Z

[bill-auger]

Post by Zlatan Todoric
is  that someone from FSF (Donald?) CC's directly all current delegates
from active distros on topic that reached point of need to be discussed
and solved by distros (aka higher priority topic). That way (at least
for me) we will not be stretched on many sides but also such ping would
get our attention and bring us in into discussion. Thoughts?

that is an interesting suggestion - it reminds me of those consensus
voting/polling websites

surely not everyone is expected to participate in reviews and that is
much of the discussion - but on the other hand, voting on an issue is
not the same as actually discussing it so i would not know where to draw
the line between what should be discussed and what needs a vote or when

i can say though that this list is not always such high volume as it has
been in recent months - it would be good if it continues at this pace
but i do expect it to settle down after the current wave of applicants
passes through

[Luke Shumaker]

On Mon, 26 Mar 2018 07:09:47 -0400,

Post by bill-auger
i can say though that this list is not always such high volume as it has
been in recent months - it would be good if it continues at this pace
but i do expect it to settle down after the current wave of applicants
passes through

To put numbers on it: in 2017 there were 224 messages on this list.
This email that I'm sending makes 198 for 2018.

[Julie Marchant]

While Purism did make claims it could not stand to it in timeframe it
wanted, Purism is still moving thing slowly forward and even has
constitution to defend such stand. Issues you have with Purism are not
part of PureOS and I mentioned Purism only in context that PureOS gets
bashed basically because Purism is behind it.

You can defend Purism or claim that PureOS is separate from Purism;
either way, I have no problem with PureOS at this point. But it's a bit
self-contradictory to try to defend Purism (and even use terms like "we"
and "our" in relation to it) and yet say that complaints about Purism
have nothing to do with PureOS.

Regarding Purism and trust, I would suggest to Todd that he would regain
trust a lot faster if the Purism website didn't have so many
over-inflated propaganda articles. I understand that Purism is a
for-profit company and some propaganda is to be expected, but this list
of pages is just a bit absurd:

https://puri.sm/why-purism/

Personally, I'm perfectly fine at this point with viewing Purism as a
company with roughly the same standards as Think Penguin, and I would
buy a product from them if it appealed to me the best out of all
possible products in my price range. But not everyone is ready to accept
Purism even that way, and what you're saying about Purism critics on
this list isn't helping toward that end. As has already been said, you
can easily destroy trust at the drop of a hat, but you can't just gain
trust at a whim; it takes continual demonstration of trustworthiness
over time through consistently good actions.

[bill-auger]

Post by Robert Call
While I don't agree with Bill's stance

the only sentiments i expressed that qualify as a "stance" are that
everyone should held to the same standards and that each distro should
elect a delegate to participate in these discussions - i should hope
those were agreeable to everyone

if anything else came across as prescriptive; it was not intended that way

Post by Robert Call
Many of us are willing to forgive PureOS and Purism for past issues,

again, i will underline that i literally have no knowledge of any such
past issues; and remain in full suspension of judgment - as such, i
would not presume to make any prescriptions regarding pureos specifically

[bill-auger]

i really can not speak to any experiences you may have had on this list
in the past - i have only been active on this list for about one year
and i have not seen anything particularly negative about pureos in that time

personally, i have insufficient facts to form an opinion of either
pureos or purism; so i would not presume to do so, neither privately nor
publicly - im just glad you joined the discussion - please do pardon any
perceived animosity - none was intended

Post by Zlatan Todoric
next time please go to our bugtracker
and report a bug there and start discussion
Simply removing chromium is a disservice
for average user and it shouldn't be a task taken easily.

the decision to remove chromium was not taken lightly by anyone - this
community has been discussing it for several years - i did not report
that issue to pureos - it had been there already for several months when
i found it - all i could have possibly done in the context of pureos
specifically, would have been to "up-vote" the existing tracker issue
like: "yea me too +1" - but i would not presume to do any such thing -
bug trackers are not popularity polls and software licenses are not
subjective - most objectively speaking, any wad of software is either
freely distributable as a whole or it is not - it is very unfortunate
that down-streams are burdened to determine that subjectively in this
case - but the main purpose of this discussion group is to resolve such
issues that affect all FSDG distros equally - and so, because that issue
affects every FSDG distro equally; the bug tracker of one distro is not
the proper place to discuss it - it is regretful if pureos was ever made
to feel unwelcome to community discussion in the past - i hope we can
change that going forward


On 03/25/2018 05:58 AM, Zlatan Todoric wrote:> Debian kernel itself is
entirely free but there was issues with messages

Post by Zlatan Todoric
that was brought to us and we worked on it both in PureOS and Debian at
same time.

i really can not to speak to that issue at all - that is a sticky mess
that the FSF created and one that only they can resolve; but whatever
determination is reached should be something that all FSDG distros are
bound to equally - just as with the chromium issue, i favor no
particular decision myself - but i do want to see everyone on the same
page - if the pureos folks can solve that kernel logging issue; please
do post the result here on this list - no one here is expected to be
reading the pureos bug tracker and certainly not the debian bug tracker

Post by Zlatan Todoric
You have bug tracker for PureOS if you want to work with PureOS
community and not stretch us on dozen of sides.

if i am interpreting that statement correctly, it reads like an
uncomfortable ultimatum - i think you have this relationship inverted -
and please do not implicate me directly as if i had any obligations here
- i am just a volunteer with no particular interest in pureos other than
the fact that pureos wants to be accepted as part of the greater GNU
community - my intention here is only to encourage all DSFG distros to
participate in the discussions of common issues - discussions of common
issues are more fruitful in a common place; not the issue tracker of one
distro

if pureos hopes to be accepted warmly into the greater GNU community;
then i would think that pureos would be inclined, of it's own
initiative, to participate in the community discussions - then perhaps
some interest would begin flowing in the other direction

it is regretful if anyone working on pureos has taken any personal
offense to any words printed to this mailing list in the past - i could
see this becoming a fruitful relationship between GNU and pureos; but
please try not to take anything personally - myself, i would be the
first one to defend any project if i saw anyone spreading FUD - but on
the other hand, i can not align myself with people who uses such
emotionally charged language in a professional context

people are not "toxic" and neither are opinions or language - chlorine
is toxic - such loaded words are not appropriate in a professional
context - they only serve to inject emotional subjectivity into an
otherwise sane professional context unnecessarily - for example, i am
very much unwilling to "play nice in a work context" - that very request
portrays the speaker's co-workers as children; which is as belittling to
both - i may "play nice" in a play-time context; but in a professional
context, i prefer to "behave as a mature adult" - that is not intending
to be facetious; the particular words people choose are extremely
important, especially in asynchronous digital text form - again, i dont
claim to be any representative of this group - i can only speak to this
for myself; but in my experience, simply avoiding highly emotionally
charged language generally allows people to get along more amicably
through adversities; and is the basis for much-needed diplomacy in this
ever-shrinking world we live in

[bill-auger]

Post by Zlatan Todoric
Debian kernel itself is entirely free but there was issues with messages
that was brought to us and we worked on it both in PureOS and Debian at
same time.
https://tracker.pureos.net/T362

i am curious about this - i thought about tackling it myself at one
point but i was told that it is a very difficult problem to fix - the
work you point took one day - if it were so easy i would have hoped this
would have been fixed many years ago

i found it difficult to learn exactly what you guys did though - this is
what i could determine:

* todd opened an issue named "firmware binary warning should not appear
for non-free binaries"
* a few hours later chris said (paraphrasing) "i dont think debian will
take this"
* he instead offered a patch that removed nothing but added the URL to a
debian wiki page to the log warning
* the next day the issue was closed with: "chris.lamb closed this task
as "Resolved". Fixed in initramfs-tools_0.130pureos1"

how exactly was this issue resolved? the issue title seems spot on but
that patch does not even attempt to address the FSDG issue of the blob
name - it is exactly the solution the connochaetos proposed last august
that was not accepted[1] and the review of connochaetos essentially
halted at that point

the 'pureos1' on the end of the package name conventionally indicates
that the downstream has modified the upstream package - but there was no
patch attached to the issue and the pureos website does not indicate any
dedicated section for code review nor version control so it is not at
all clear that pureos added anything to that package on that day

it seems the only way to find this is in the deb repo - but that only
has the most recent version of each package and
initramfs-tools_0.130pureos2 has already clobbered
initramfs-tools_0.130pureos1 - is there any way i (or anyone) could see
what actually changed in that package when chris declared "i fixed it"?

or could you just tell us what did chris actually fix?
* "firmware binary warning should not appear for non-free binaries"

or the debian patch:
* "add a link to the https://wiki.debian.org/Firmware to 'firmware:
failed to load' log messages"



[1]:
https://lists.nongnu.org/archive/html/gnu-linux-libre/2017-08/msg00039.html

[Zlatan Todoric]

[CC'ing Chris so he can elaborate on this. Side note, he and few other
Purism folks are at LibrePlanet]

Post by bill-auger

Post by Zlatan Todoric
Debian kernel itself is entirely free but there was issues with messages
that was brought to us and we worked on it both in PureOS and Debian at
same time.
https://tracker.pureos.net/T362

i am curious about this - i thought about tackling it myself at one
point but i was told that it is a very difficult problem to fix - the
work you point took one day - if it were so easy i would have hoped this
would have been fixed many years ago
i found it difficult to learn exactly what you guys did though - this is
* todd opened an issue named "firmware binary warning should not appear
for non-free binaries"
* a few hours later chris said (paraphrasing) "i dont think debian will
take this"
* he instead offered a patch that removed nothing but added the URL to a
debian wiki page to the log warning
* the next day the issue was closed with: "chris.lamb closed this task
as "Resolved". Fixed in initramfs-tools_0.130pureos1"
how exactly was this issue resolved? the issue title seems spot on but
that patch does not even attempt to address the FSDG issue of the blob
name - it is exactly the solution the connochaetos proposed last august
that was not accepted[1] and the review of connochaetos essentially
halted at that point
the 'pureos1' on the end of the package name conventionally indicates
that the downstream has modified the upstream package - but there was no
patch attached to the issue and the pureos website does not indicate any
dedicated section for code review nor version control so it is not at
all clear that pureos added anything to that package on that day
it seems the only way to find this is in the deb repo - but that only
has the most recent version of each package and
initramfs-tools_0.130pureos2 has already clobbered
initramfs-tools_0.130pureos1 - is there any way i (or anyone) could see
what actually changed in that package when chris declared "i fixed it"?
or could you just tell us what did chris actually fix?
* "firmware binary warning should not appear for non-free binaries"
failed to load' log messages"
https://lists.nongnu.org/archive/html/gnu-linux-libre/2017-08/msg00039.html

[Chris Lamb]

Dear all,

Apologies for not seeing this thread earlier.

I believe the source of much for the confusion here is because, alas,
not all of the conversation and clarification has occured on the public
tracker and is thus not visible to you.

Some of these chats happened via IRC and some even happened IRL. I
appreciate that this can be rather opaque; indeed, it is frustrating
even for myself as it requires storing state (ew!) and not being able
to rely on a canonical source of truth.

Indeed, even some of the banter that occurred on the linked thread is
not actually funny to someone outside of all the conversations and
small clarifications.

Post by bill-auger
* todd opened an issue named "firmware binary warning should not appear
for non-free binaries"

First, just to clarify, this is to do with seeing firmware quote-errors-
unquote when running update-initramfs and actually nothing to do with
messages originating from the kernel / "dmesg".

Post by bill-auger
it seems the only way to find this is in the deb repo

Alas, this is not quite accurate but not your fault at all. You can
see the corresponding Git commit here:

https://code.puri.sm/pureos/initramfs-tools/commit/005ca5b834fa7ee44bb913d74b4ff2aa542fc9d1

However, I can see that this is not transparent to someone getting
hold of the source. Notably:

https://code.puri.sm/pureos/initramfs-tools/src/005ca5b834fa7ee44bb913d74b4ff2aa542fc9d1/debian/control#L8-L9

.. still refers to the Debian repository. I have gone ahead and made
the following change here to avoid this in future:

https://code.puri.sm/pureos/initramfs-tools/commit/87c0fc5886da32d4895902dba704e4c847546cf9

Post by bill-auger
initramfs-tools_0.130pureos2 has already clobbered
initramfs-tools_0.130pureos1

"Clobbered" is, again, not quite accurate; there was indeed a "pureos2"
This is an entirely separate (from a technical point of view) change
and can be found here:

https://bugs.debian.org/888405

It might not be clear from the above report but this part is, for me,
not yet fully resolved as the aforementioned linked page does not even
*begin* to discourage the usage of non-free software enough.

I trust this, at least, clarifies the technical changes made here.


Best wishes,

[bill-auger]

Post by Chris Lamb
First, just to clarify, this is to do with seeing firmware quote-errors-
unquote when running update-initramfs and actually nothing to do with
messages originating from the kernel / "dmesg".

thats all i was trying to determine - it is the kernel error messages
that this list is interested in - such as discussed in this thread from
2010[1] - although it does appear that this warning would be interesting
as well - i think the important difference is that this one appears as a
"warning" where the other appears to be an "error" (as if the user has
done something wrong by neglecting to acquire the blob)


On 03/27/2018 09:39 AM, Chris Lamb wrote:> However, I can see that this
is not transparent to someone getting

Post by Chris Lamb
hold of the source.

indeed, the pureos website has no indication of this - now i understand
why, because that VCS in on the puri.sm domain - i think it is safe to
assume that this list would be in a fervor if even one link appeared on
the pureos website directing users to the puri.sm domain - i hope that
pureos is working toward separating their infrastructure from purism's -
if pureos is hosting their source code on the puri.sm domain, that
itself may be new FSDG problem to be addressed; but perhaps a
contentious one

Post by Chris Lamb
"Clobbered" is, again, not quite accurate; there was indeed a "pureos2"

i apologize if that was perceived as a loaded word - i meant "clobbered"
only in the most plain, technical sense - it does not mean "reverted" -
it does not even imply intentionality - it only means that some new
thing replaced an old thing, entirely in its place, leaving no trace of
the previous occupant - just as re-assigning a variable blindly evicts
the previous value - in that sense, "clobbered" is entirely accurate and
the appropriate technical term - it implies nothing else


[1]:
https://lists.nongnu.org/archive/html/gnu-linux-libre/2010-12/msg00058.html

[bill-auger]

Post by bill-auger
if pureos is hosting their source code on the puri.sm domain, that
itself may be new FSDG problem to be addressed; but perhaps a
contentious one

to avoid any misunderstanding here; i should qualify that by saying that
this is for no other reason than the non-free repos hosted on that same
domain - the websites of other FSDG distros have links to commercial
supporters - i dont think that alone is any problem

[Jean Louis]

Post by bill-auger
indeed, the pureos website has no indication of this - now i understand
why, because that VCS in on the puri.sm domain - i think it is safe to
assume that this list would be in a fervor if even one link appeared on
the pureos website directing users to the puri.sm domain - i hope that
pureos is working toward separating their infrastructure from purism's -
if pureos is hosting their source code on the puri.sm domain, that
itself may be new FSDG problem to be addressed; but perhaps a
contentious one

There are links to puri.sm notebooks, and that is
most logical. The company with notebooks is
sponsoring the pure OS. And so there shall be
links, and there are devices on the notebook that
need attention in terms of handling them by the
tracker and such devices have their names and
references to notebooks and it should be so.

Company producing notebooks is making the
PureOS. It is very simple. The company shall be
credited and referenced whenever necessary.

Finally, PureOS appears to be commercially
sponsored, which is good thing for a free software
distribution. It appears to me that people working
on that distribution are paid, and they may
dedicate their time and efforts in making
distribution free. Those people depend of sales,
and notebook is apparently "free hardware" and
there shall be sales of free hardware.

I would not agree on placing links only if the
links are pointed to non-free hardware, however,
the notebooks and their intentions are to make and
sell fully free hardware and they are changing the
game in the world, and in that sense everybody who
likes free hardware including PureOS shall point
back to makers of free hardware.

Jean Louis

[bill-auger]

yes i apologize for my poor choice of words there - that issue i raised
has nothing to do with commercial associations - in fact, the FSDG fully
allows for the distro itself to be a commercially operated entity - that
is, as i understand, essentially what ututo is - but, as far as i know,
the ututo parent company does not provide non-free software to it's
users, nether directly nor indirectly - please do correct me if i am
wrong about that

i attempted to back-paddle that about five minutes later - i do not to
intend cast any judgments myself - i like to think that i am just
shining a light in any grey areas that i stumble onto - let the
community decide how to interpret what is to be seen there

one could probably imagine RMS barking: "users looking for the free
source code for their system should not be directed to a server where
non-free software can be found for that same system" - of course, the
opinion depends on who you ask - some people are real sticklers about
that sort of thing

Post by Jean Louis
It appears to me that people working
on that distribution are paid, and they may
dedicate their time and efforts in making
distribution free.

you make a good point there - in theory that could be a very healthy
thing for the distro

[Henry Jensen]

Am Mon, 26 Mar 2018 06:58:54 -0400

Post by bill-auger
how exactly was this issue resolved? the issue title seems spot on but
that patch does not even attempt to address the FSDG issue of the blob
name - it is exactly the solution the connochaetos proposed last
august that was not accepted[1] and the review of connochaetos
essentially halted at that point

we are dealing with two different issues here.

1. The freedom bug at the PureOS bug tracker
https://tracker.pureos.net/T362 deals with the messages that originates
from initramfs-tools, like this one:

W: Possible missing firmware /lib/firmware/i915/bxt_dmc_ver1_07.bin for
module i915

According to the bug tracker, this issue has been fixed in PureOS.

ConnochaetOS never had this issue of printing warnings about missing
firmware when generating the initramfs, because we don't use Debian's
initramfs-tools.


2. A complete different issue is about printing messages about
failed-to-load firmware to the log file. These messages originate from
the kernel itself, they read like this:

iwlwifi: 0000:03:00.0 firmware: failed to load iwlwifi-6000g2a-6.ucode

This issue have been addressed by ConnochaetOS by printing a warning
message next to the "firmware: failed to load" line that the
requested fimrware file is possibly non-free.

This solution wasn't "not accepted" - there was no response at all on
this list regarding this solution.

As far as I know this issue haven't been addressed yet at all by PureOS.

[Julie Marchant]

Post by Henry Jensen
2. A complete different issue is about printing messages about
failed-to-load firmware to the log file. These messages originate from
iwlwifi: 0000:03:00.0 firmware: failed to load iwlwifi-6000g2a-6.ucode
This issue have been addressed by ConnochaetOS by printing a warning
message next to the "firmware: failed to load" line that the
requested fimrware file is possibly non-free.
This solution wasn't "not accepted" - there was no response at all on
this list regarding this solution.

FWIW, that sounds like a good solution to me.

[Jason Self]

Post by Zlatan Todoric
For chromium - I am not in favor for it and as stated I request
complete removal. The thing is - we must find more productive ways
of this because simply removing things means also we remove
productivity for many people (yes we have fork of Firefox but that
is still not 100% stable and some things work on chromium that don't
work on Firefox and vice versa).

Sure, I agree. My understanding is that the only reason people have
brought up Chromium is because it's still listed from many years ago
[0]. As I understand it, upstream has said that they've since fixed
the problems that were raised. AFAIK no one has since done a deep dive
into Chromium to confirm and determine if any other issues exist. If
anything there is some evidence to suggest that it may very well just
be a years-old outdated report and is not valid anymore. But until
someone goes and checks...

But I don't think that the FSDG requires distros to remove a program
over allegations of freedom problems. Waiting until they're actually
confirmed also seems to follow with the FSDG, and might even be better
because it avoids removing packages only to re-add them later in cases
where the report turns out to be wrong. Or perhaps merely changing a
program would be sufficient, not a full removal. Either way, waiting
for an in-depth analysis and confirmation of any particular problem
seems a better solution.

Post by Zlatan Todoric
You have our tracker to comment on that and can't expect us to be
all the time everywhere, especially not on list that proved itself
as a bashing field.
the easiest and most efficient way to get PureOS attention is to
use its public bugtracker (and feel free to mail me directly -
whenever I have time I will jump on IRC/Matrix/WebRTC/Mumble).

I agree that this mailing list has its challenges but freedom problems
are usually not limited to just one distro. So it is good to have a
place where all of the FSF-endorsed distros can communicate and work
together on such things in a cooperative way. It would be more
difficult to organize communication to such things if the discussion
on problems were spread out among the ticketing systems of all 12
endorsed distros. For this reason I hope that you (or someone working
on PureOS) will remain involved here. Hopefully everyone involved can
keep things civil and on-topic.

[0]
https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines#chromium-browser

[bill-auger]

Post by Jason Self
But I don't think that the FSDG requires distros to remove a program
over allegations of freedom problems.

no, but the FSDG does specify "No software from the List of software
that does not respect the FSDG" - so until the day chromium is removed
from that list, i think it's blacklisting is compulsory in lieu of any
known liberation procedure

[Robert Call]

Post by bill-auger

Post by Jason Self
But I don't think that the FSDG requires distros to remove a
program
over allegations of freedom problems.

no, but the FSDG does specify "No software from the List of software
that does not respect the FSDG" - so until the day chromium is
removed
from that list, i think it's blacklisting is compulsory in lieu of any
known liberation procedure

That is not part of the FSDG! It would only be if they did not
cooperate or if they did not make a commitment to removing non-free
software! So, should libreCMC be removed or blacklisted if we found
some non-obvious freedom issue or bug? Mistakes and misunderstanding do
happen and you can't ignore that.

--
Robert Call (bob)
***@librecmc.org
https://librecmc.org

[bill-auger]

Post by Robert Call
That is not part of the FSDG!

it is one of the checklist items that donald put on the newly codified
criteria last week[1] - you are correct though, that it is not specified
on the guidelines web page[2] - maybe it will be added soon - i dunno

of course everyone should be allowed the benefit of doubt to fix
problems once found - i was not implying the distro would be blacklisted
- i was saying that software on that list needs to be blacklisted from
the distro repos unless some liberating procedure is found

[1]: https://libreplanet.org/wiki/Template:FSDG_Checklist
[2]: https://www.gnu.org/distros/free-system-distribution-guidelines.html

[Donald Robertson]

Post by bill-auger

Post by Robert Call
That is not part of the FSDG!

it is one of the checklist items that donald put on the newly codified
criteria last week[1] - you are correct though, that it is not specified
on the guidelines web page[2] - maybe it will be added soon - i dunno
of course everyone should be allowed the benefit of doubt to fix
problems once found - i was not implying the distro would be blacklisted
- i was saying that software on that list needs to be blacklisted from
the distro repos unless some liberating procedure is found
[1]: https://libreplanet.org/wiki/Template:FSDG_Checklist
[2]: https://www.gnu.org/distros/free-system-distribution-guidelines.html

I just want to clarify that I view that list as a tool for flagging
potential issues; things to discuss/review. I don't think it needs to be
made a criteria of FSDG. The criteria is already "no nonfree", this is
just a resource for identifying common packages that have potential
issues with that criteria. I think I agreed earlier that 'blacklist'
wasn't appropriate for what that resource is. Like Jason said there are
things on the list that had issues in the past, or there are potential
fixes. So let's treat it as a resource for helping work through common
issues.

You've done a lot of really nice work on the checklist template Bill. It
looks great, and rather than having me bork it up, would you mind
updating it so that the list is not being treated as a blacklist? Thank you.

[bill-auger]

Post by Donald Robertson
would you mind
updating it so that the list is not being treated as a blacklist? Thank you.

sure, i did interpret it that way myself - i had already named the data
key 'non-dsfg-software-cleansed' - on the presumption that it is not a
strict blacklist but that many or most entries do have remedies that
could allow them to be made acceptable

so how about this:

"Programs commonly known to have freedom issues are liberated or excluded"

[Jason Self]

Post by Robert Call
That is not part of the FSDG!

Right. And a lot of entries in there have "use version X or later" as
a fix. So even once Chromium is sorted out it'd still be on there but
with a similar recommended fix. So it's not so much a blacklist
anymore these days but more of a list of minimum versions to use.

[bill-auger]

Post by Jason Self
Right. And a lot of entries in there have "use version X or later"

chromium is however not one of those items - and i quote:

Recommended Fix:
Remove program/package
Use GNU IceCat, or equivalent

surely that list needs some attention - i suppose it's maintenance will
be a new task for this group

i suggested recently on the FSD mailing list of expending it greatly
using the parabola blacklist data which could help keep it updated in an
automated way

[Jason Self]

Post by bill-auger
Remove program/package
Use GNU IceCat, or equivalent

Yes, although it's presence there is based on a report from 2009 that
upstream has said (on more than one occasion as I recall) has been
addressed. And so, that recommended fix may indeed not be applicable
anymore. There is some evidence that suggests it's outdated (i.e.,
Debian has added Chromium into Main without the -dfsg string in the
package version number which suggests that they didn't need to make
any changes to Chromium to fit with their criteria. While the DFSG and
the FSF's own criteria are not identical this is nevertheless a good
sign.) So I'd not hold distros to removing a package that is possibly
based on outdated information, at least until someone can review it
and make a determination. I've mentioned before that this whole thing
that we're doing isn't supposed to be some blind, automated, rote process.

[Isaac David]

Post by Jason Self

Post by bill-auger
Remove program/package
Use GNU IceCat, or equivalent

Yes, although it's presence there is based on a report from 2009 that
upstream has said has been
addressed. [...] There is some evidence that suggests it's outdated
(i.e.,
Debian has added Chromium into Main without the -dfsg string in the
package version number which suggests that they didn't need to make
any changes to Chromium to fit with their criteria.

right off the bat, Debian's Chromium steers users towards nonfree
addons, just like their version of Firefox... obviously unacceptable
to FSF standards.

what the libreplanet wiki documented --namely unclear license
headers-- was but one issue, likely addressed upstream by now. it's
also likely that Debian isn't building Chromium from sources
completely, as explained by [Ungoogled Chrommium], unless they went to
great length similarly patching the build process.

that last bit may not be part of the Guidelines, but worries me
still. not to mention all the built-in spyware.

in my mind it's only the [case against Qt-Webengine] (at Parabola)
that rests of pretty shaky grounds: a vague indication that Arch
Linux's [sic] build in particular activated nonfree addons, and fears
that Chromium's problems could be contagious, despite statements to
the contrary made by Qt-Webengine developers themselves.

[Ungoogled Chromium]: https://github.com/Eloston/ungoogled-chromium
[case against Qt-Webengine]: https://labs.parabola.nu/issues/1167

[bill-auger]

Post by Isaac David
in my mind it's only the [case against Qt-Webengine] (at Parabola)

are you saying that you think qt5-webengine is probably acceptable as it is?

but chromium still has problems? (and probably iridium and ungoogled)

if that were true, i would happy to drop the subject this very moment -
even if that meant keeping chromium and friends on the blacklist
indefinitely

[bill-auger]

Post by Isaac David
[Ungoogled Chromium]: https://github.com/Eloston/ungoogled-chromium
[case against Qt-Webengine]: https://labs.parabola.nu/issues/1167

little need to post links about chromium now - this is becoming very old
news - there is a master thread on the FSD list[1] - something of an
anthology of chromium woes - including links to the parabola mega-issue,
the original upstream bug report from 2009 (still open), and many
conversations over the years

i have been told that 'ungoogled' and 'iridium' devs were asked and had
no information whatsoever regarding the phantom unlicensed files; so i
never bothered to research those projects - someone from qt-webengine
mentioned on that thread that they had no information either but were
willing to fix anything found

one particular post is an interesting read of fedora's experiences[2]



[1]:
https://lists.gnu.org/archive/html/directory-discuss/2017-11/msg00003.html
[2]:
https://lists.gnu.org/archive/html/directory-discuss/2017-12/msg00008.html

[Jason Self]

keep it updated in an automated way

I'm not sure I'd be onboard with that idea. My understanding is that the
Parabola folk will blacklist a package as soon as an allegation is made, as
part of a "blacklist first, research second" type of policy. I don't mean
to criticize the Parabola folk for this though because such a policy
probably does not conflict with the FSDG but I think a list of common
freedom problems that we're asking other distros to take action on should
only consist of ones that have been researched and confirmed to be valid,
which is how that list has historically been maintained. So an automated
rote importing would probably not be a good idea, IMHO.

[bill-auger]

Post by Jason Self
I'm not sure I'd be onboard with that idea. My understanding is that the
Parabola folk will blacklist a package as soon as an allegation is made

that seems an accurate perception to me - in it's current state it is
not fit for the task - i would not want to implement that at all until
each entry had clearly noted precisely what the problems are and what
was done to correct them - but the libreplanet list is not so complete
in that way either

i think the idea has potential though - it is far from a witch hunt but
more of a rescue mission - the majority of packages on the parabola
blacklist have been modified to fit the FSDG and are available in
parabola renamed like 'foo-libre' - what is missing from too many is the
documentation trail that could inform others how to liberate them in
other distros - that would need to be made a more rigorous policy to
make this a viable reference for all

from reading the documentation that is there though, it seems clear that
the original intention was to keep the parabola blacklist and the
libreplanet list in sync - as mutual references for each other

[Jason Self]

Post by Henry Jensen
This solution wasn't "not accepted" - there was no response at all on
this list regarding this solution.

Yes, I stopped responding because of the push back to fix this in the way
that the other distros have. I quietly deemed the push back to fixing the
problem as lacking in the "Commitment to Correct Mistakes" area (which is
probably the most important part of the entire FSDG because as long as
that's there any other problems can be solved) and stopped doing any
further review of the distro.

But, if you want a response, the FSDG contains a prohibition to not steer
users towards obtaining any nonfree information for practical use, or
encouraging them to do so. It doesn't say that this becomes OK if the
user is warned; it only says not to do it. There is no further guidance
or conditionals given.

So I think that such a change would also not be acceptable under the FSDG
either, because the message is still there, and given the lack of further
conditionals in the FSDG, the prohibition would remain in place no matter
how strongly a distro might try to "warn" the user.

[Henry Jensen]

Am Mon, 26 Mar 2018 07:31:56 -0700 (PDT)

Post by Jason Self
But, if you want a response, the FSDG contains a prohibition to not
steer users towards obtaining any nonfree information for practical use,
or encouraging them to do so.

It depends on how you define "to steer". Just to mention a file name or
any other non-free program isn't hardly "steering". And it seems that
this is also the view at the FSF. Otherwise PureOS wouldn't have been
endorsed in the first place.

As for ConnochaetOS: quite the opposite is true. Since the the kernel in
warns about possible non-free firmware it is leading users
away and discourages them from installing it.

[Julie Marchant]

Post by Jason Self
But, if you want a response, the FSDG contains a prohibition to not steer
users towards obtaining any nonfree information for practical use, or
encouraging them to do so. It doesn't say that this becomes OK if the
user is warned; it only says not to do it. There is no further guidance
or conditionals given.
So I think that such a change would also not be acceptable under the FSDG
either, because the message is still there, and given the lack of further
conditionals in the FSDG, the prohibition would remain in place no matter
how strongly a distro might try to "warn" the user.

This is something I don't understand regarding that. Why is simply
mentioning the name of a missing file considered to be a recommendation?
A file name is a file name, and any executable can be given any file
name. Yeah, I get it, people can Google file names and find proprietary
files, but what if someone Googles some libre recommended program and
for one reason or another the search returns a similar proprietary
program instead? Where exactly is the line here?

[bill-auger]

Julie

this is how it was explained to me - i was a bit mixed up yesterday
myself - but henry's first message today made it clear

the main problem is not so much mentioning the name of the blob but that
the message is presented as an error - "failed to load this blob" - that
gives the impression that the user has done something wrong by "failing"
to acquire that blob

i had never actually seen that error - so what i found puzzling
yesterday looking at the pureos patch was that it was only a (W) warning
and did not actually read like a hard error - now i understand the
pureos patch not only doesnt address the problem but it is not even in
the same package where the problem exists

[Jason Self]

Post by Henry Jensen
It depends on how you define "to steer". Just to mention a file name or
any other non-free program isn't hardly "steering". And it seems that
this is also the view at the FSF. Otherwise PureOS wouldn't have been
endorsed in the first place.

We're going in circles. We had that discussion before. I pointed to the
earlier messages on this mailing list where RMS had said it amounted to
that in our earlier conversation, and how PureOS was probably an oversight.
It doesn't seem fair to point to a mistake and want it to continue to
happen going forward. After all, "we don't reject a distribution over
mistakes. Our requirement is for the distribution developers to have a firm
commitment to promptly correct any mistakes that are reported to them."

And here things are again, continuing to push back on making the change.

[Henry Jensen]

Am Mon, 26 Mar 2018 09:01:51 -0700 (PDT)

Post by Jason Self
We're going in circles. We had that discussion before. I pointed to
the earlier messages on this mailing list where RMS had said it
amounted to that in our earier conversation, and how
PureOS was probably an oversight. It doesn't seem fair to point to a
mistake and want it to continue to happen going forward.

RMS mail from 7 years ago was vague and sounded that he didn't had all
the facts back then (he wrote "it sounds like ..."). The fact that
PureOS was endorsed in the meantime indicates that also.

I've gone trough the entire history again. So far, the argument that
PureOS was a "mistake" or an "oversight" was only made by you (and the
PureOS developer on this list objected)

PureOS worked for two years with the FSF to become endorsed. I found it
hard to believe that they, of all things, didn't look at the kernel.
And if even so, in the 3 month that have passed since my intial mail
nobody reported this as a freedom bug in the PureOS bug tracker, as you
suggested.

As long as this isn't accepted as a valid freedom bug by PureOS or the
FSF I think the facts are clear.

[Jason Self]

Julie Marchant wondered about this.

Past discussions of this are in the list archives and probably on the
Linux-libre mailing list too. The general summary is that it's one thing
when someone goes and does something on their own. It's another thing
when their system tells them.

And people have shown up on distro mailing lists asking how to install
the stuff that the kernel was telling them to. There was an example of
this on the Trisquel forms not too long ago when a microcode request was
not properly changed in Linux-libre, resulting in the kernel telling the
person to install the updated microcode. So they showed up asking how to
do that.

To make a quote from https://www.gnu.org/philosophy/compromise.en.html

"The issue here is not whether people should be 'able' or 'allowed' to
install nonfree software; a general-purpose system 'enables' and 'allows'
users to do whatever they wish. The issue is whether we guide users
towards nonfree software. What they do on their own is their
responsibility; what we do for them, and what we direct them towards, is
ours. We must not direct the users towards proprietary software as if it
were a solution, because proprietary software is the problem."

[Donald Robertson]

Sorry I couldn't jump in sooner on this thread, I've been a bit busy at
LibrePlanet.

In terms of de-listing or other action plans for currently endorsed
distros, that's something for us at the FSF to handle.

What you all can do to help is to file freedom-related bugs where
applicable for any currently endorsed distro and follow the instructions
at <https://www.gnu.org/help/gnu-bucks.en.html>. In short, file a bug
with the project, email us at report-***@fsf.org with a link to that
bug, and your physical mailing address should you want to receive a GNU
Buck.

I understand the concerns with some of these older distros, but we have
a mechanism in place for making sure they keep working on
freedom-related issues, we just have to keep working at that. And if
they're having trouble meeting those obligations, we at the FSF will
discuss with them the best way to move forward.

And that goes for any distro; if there are issues, file bugs and let
<report-***@fsf.org> know, and we'll monitor the situation. We
require every distro to maintain a way to accept bugs, so I don't think
we need to use this list as a bug tracker.

In terms of discussing whether a particular issue is actually a freedom
problem, that can be really important work we can do here on the list.
But I think we've built a good base of information and opinion here on
the issues discussed, and at this point we at the FSF need to bring some
guidance. So please give me some time to move forward our internal
discussions on these issues.

I know the system in the past hasn't worked very well, and that's my
fault. I've got a lot of work to do to get things back up and running
properly, and I thank you all for your help in revamping things. While
that is going on, let's keep in mind we're all working towards the same
goal here. We are all on the same team. But I'm the one ultimately
responsible for keeping things running when it comes to endorsed
distros, so if you're feeling frustration, please direct it at me. Let's
keep our eye on the prize here on the list, and I think we can really
accomplish a lot.

[bill-auger]

and at this point we at the FSF need to bring some guidance.

there has been a healthy flurry of activity on this list recently and i
think the will exists to forgot about any friction in the past and move
forward - but i must firmly say that "guidance" is too weak of a word
for what the FSF needs to do to in order to smooth over the past
wrinkles - as i understand, tensions have gotten high in the past and
many are still not at ease - there are at least 2 issues that the
community has argued over for years that only the FSF should decide
definitively - namely:

* are the debian kernel blob error log messages acceptable or are they
unacceptable? *regardless of the distro*

* what to do about chromium - now i think it is finally removed from all
FSDG distros - should we just let that dog lie? - i am happy to tell
users "forget it - she is a lost cause" (that probably is the case for
'electron') - but i was told that RMS was interested in doing something
about it - so maybe the answer should be "not now - but maybe someday" -
even that distinction would make a difference - i happen to know we have
the co-operation of qt5-webengine - if only that library could be deemed
acceptable, it would have the greatest impact

i do think it is imperative that the FSF makes a final decision on these
two issues and apply them equally to all distros - these should not be
left to the subjectivity of each distro - either they are acceptable for
all or they are unacceptable for all - to leave these to the subjective
determinations of each distro is a great source of friction amoung them

[Donald Robertson]

Post by bill-auger

and at this point we at the FSF need to bring some guidance.

there has been a healthy flurry of activity on this list recently and i
think the will exists to forgot about any friction in the past and move
forward - but i must firmly say that "guidance" is too weak of a word
for what the FSF needs to do to in order to smooth over the past
wrinkles - as i understand, tensions have gotten high in the past and
many are still not at ease - there are at least 2 issues that the
community has argued over for years that only the FSF should decide
* are the debian kernel blob error log messages acceptable or are they
unacceptable? *regardless of the distro*
* what to do about chromium - now i think it is finally removed from all
FSDG distros - should we just let that dog lie? - i am happy to tell
users "forget it - she is a lost cause" (that probably is the case for
'electron') - but i was told that RMS was interested in doing something
about it - so maybe the answer should be "not now - but maybe someday" -
even that distinction would make a difference - i happen to know we have
the co-operation of qt5-webengine - if only that library could be deemed
acceptable, it would have the greatest impact
i do think it is imperative that the FSF makes a final decision on these
two issues and apply them equally to all distros - these should not be
left to the subjectivity of each distro - either they are acceptable for
all or they are unacceptable for all - to leave these to the subjective
determinations of each distro is a great source of friction amoung them

Yes, I apologize if 'guidance' wasn't clear, I meant that we're going to
make a decision and share that with the list.

[bill-auger]

Post by Donald Robertson
Yes, I apologize if 'guidance' wasn't clear, I meant that we're going to
make a decision and share that with the list.

2 decisions please :)

i presume the "a decision" you referred to was the kernel issue - but i
can see the issue with 'qt5-webengine' being the next sticky widget on
this list - if not, i would like to make so myself, presently

as it is, although pureos has removed chromium, i quite expect that they
have no intention of removing 'qt5-webengine' and it's many dependents -
sure, i could file a freedom bug report against it; but they could
rightfully say (perhaps 10 months later) "its not on the blacklist so we
are no compelled" - after which, the matter would need to be referred
back to you anyways - so it is well to be addressed now, so that i dont
need to register on the pureos bug tracker just to open a rift of
contention where none should be necessary

i want to say one general thing to everyone about this - the sentiment
from pureos yesterday when they reluctantly removed chromium was of the
sort: "this is a dis-service to users" - that instinct is perhaps
understandable, but when you really think about it, is it really? how is
is it a dis-service for a freedom-respecting distro to remove a program
that is not known to be free software? (oh - but our users *like* that
program) - parabola users liked those programs too; but parabola removed
them on the principle that their removal was in the best service to
freedom-minded users; even if the users wept - tough love, son

it is not the objective of the FSDG to allow exceptions for certain
high-profile programs to pass scrutiny only because users may complain
of their absence - if those users would want to use those program even
though they are not known to be free; then those users may as well be
using a proprietary OS - furthermore, the users can always go to
www.krome.oogle and grab the binary if they desire it so much - but we
are not here to cater to that desire - i would like to think that all
software is to be considered non-free until proven otherwise - with no
exceptions because *users like it anyways*

[Jean Louis]

Well said.

I do like a commercial company such as Purism to
support fully free GNU distribution. That is so
much needed and wanted. And I like that PureOS is
approved.

Yet there is that sense and feeling that it is not
because that group is really dedicated to free
software, my feeling is that they are simply using
the free software as marketing gimick -- which is
then again alright, yet maybe not complete and
integrated dedication to free software. No need to
argue on that please, it is my opinion (not a fact).

It may hurt. Yet, Zlatan, don't take this opinion
as toxic. I am sorry, I do not feel comfortable
with Purism group of people. It is not attracting
me. To me friendliness and dedication to free
software means much. I cannot feel it on Purism
pages. I have tried my best.

Zlatan your way of discussing with people is then
corrected by your director and his public relation
speech. Fine fine, but that is simply not way how
I am used, so it simply does not fit to me.

GNU Guix and GuixSD
https://www.gnu.org/software/guix/ would be my
preference, then Trisquel and Gnewsense.

There must be some reason why there are many
topics and posts on Trisquel forum:
https://trisquel.info/en/forum and friendliness
and dedication and welcoming attitude, even if not
the FSDG rule, is for me one major decision
points. So when choosing which distribution to
install on a computer in University in Uganda I
would choose GuixSD or Trisquel.

Jean

Post by bill-auger
i want to say one general thing to everyone about this - the sentiment
from pureos yesterday when they reluctantly removed chromium was of the
sort: "this is a dis-service to users" - that instinct is perhaps
understandable, but when you really think about it, is it really? how is
is it a dis-service for a freedom-respecting distro to remove a program
that is not known to be free software? (oh - but our users *like* tha

[bill-auger]

Post by Jean Louis
There must be some reason why there are many

i would not use forum activity as any measure of the distro itself - if
anything, that is only a measure of the community - most of the
discussions on the trisquel forum are not at all related to trisquel;
but mainly more general discussions of political issues relating to free
software - IMHO those sort of discussions should be on a forum dedicated
for that purpose - such as https://freepo.st/

[Luke]

Subject: Re: [GNU-linux-libre] DSFG in perpetuity
Date: Mon, 26 Mar 2018 16:41:52 -0400
Reply-To: Workgroup for fully free GNU/Linux distributions

and at this point we at the FSF need to bring some guidance.

there has been a healthy flurry of activity on this list recently and i
think the will exists to forgot about any friction in the past and move
forward - but i must firmly say that "guidance" is too weak of a word
for what the FSF needs to do to in order to smooth over the past
wrinkles - as i understand, tensions have gotten high in the past and
many are still not at ease - there are at least 2 issues that the
community has argued over for years that only the FSF should decide
* are the debian kernel blob error log messages acceptable or are they
unacceptable? *regardless of the distro*
* what to do about chromium - now i think it is finally removed from all
FSDG distros - should we just let that dog lie? - i am happy to tell
users "forget it - she is a lost cause" (that probably is the case for
'electron') - but i was told that RMS was interested in doing something
about it - so maybe the answer should be "not now - but maybe someday" -
even that distinction would make a difference - i happen to know we have
the co-operation of qt5-webengine - if only that library could be deemed
acceptable, it would have the greatest impact.

I would also be interested in where the FSF stands on Chromium,  and how
to proceed moving forward.
Below is the article from last January which was apparently withheld
from publishing.

------------------

-------- Forwarded Message --------
Subject: Re: Article: Chromium's subtle freedom flaws
Date: Mon, 30 Jan 2017 23:33:15 +0000

[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Would you like the FSF to publish your article?
If so, please send me the latest version.

Hello,

You may publish it. Here is the latest text. HTML / formatting can also
be adjusted as needed.

Thank you.

Sincerely,
Luke
Parabola GNU/Linux-libre Packager.
---------------------------------------------------------------------------
Chromium's subtle freedom flaws

As free software activists, we all enjoy using the latest and greatest
in free software, but we need to make sure that the software we are
using really does respect our freedom. Many users have expressed to us
their desire to run Chromium web browser, since it appears to be fully
free software, but it still fails in several ways.

In our research, we discovered that the situation is improving. Just a
few years ago, there were over one thousand unlicensed files which were
considered to be non-free. Thanks to Debian's Lintian Reports and
efforts, this number has come down to under 100 files as of this
writing. Licensing the remaining code with GPL-compatible licensing is
fairly trivial and is expected to be completed soon - the majority of it
being minified javascript.[1]

However, Chromium, by default, still has a number of issues that are of
concern for free software users - even if all the source code is
licensed properly.


-What are the issues?-


Queries to Google
---

By default, Chromium source code still has many lines of code that makes
direct internet connections to Google.
When building the software unpatched, much of your browsing experience
is under the control of Google's online web services.
As mentioned in our article "Who does that server really serve?"[2],
free software is only free when you are in control and should not be
dependant on third-party web services. Some work has already been done
to free Chromium from this problem, including the removal of "Google
OK", a Google web service plugin used for voice recognition, after user
outcry.[3]

Pre-built Binaries
---

By default, Chromium still includes some pre-built binaries to aid in
faster compiling. In order to have fully free software, we require all
software to be built from source. Packagers should not use
"use_prebuilt" as a compile option.

DRM and Proprietary Codecs
---

Chromium supports the use of Widevine DRM, Adobe Pepper Flash, and
third-party codecs which are non-free. Packagers must ensure that these
are removed and disabled in the makefile options prior to compiling in
order to be free software.


Privacy problems
---

While not specific to free software, we would like for users to have
control over their private information. Chromium has a number of
reported privacy concerns which made it ineligible for use with Tor.
Issues include outstanding proxy bugs which leak a user's IP address,
fingerprinting issues that leak the computers hostname and hardware, and
timing issues that enable timing attacks even in the browser's
"Incognitio" mode. Free software users should be aware of these issues
and work to patch them upstream and in their packages as needed.[4]


A work in progress
---

There is work being done to remove queries to Google and pre-built
binaries, as well as strengthen user-privacy.

The patch-set called ungoogled-chromium, which itself is a combination
of inox, iridium, and Debian patches is one such effort.[5]
Free software advocates are advised to use these patchsets and help
contribute to their maintenance, while pushing for a self-contained
version of Chromium with these fixes built-in. With each consecutive
Chromium release a new patchset must be created to remove Google
specific code and binaries which affect your freedom. Having a
self-contained version ensures that no one will be forced to
accidentally use non-free software during these updates.


-The Bigger Picture-

Chromium is also being used as an embedded framework in various projects.

Users should be aware that QTWebengine is based on Chromium and
therefore contains many of the same flaws. Proprietary codecs and other
anti-features must be disabled at compile time to ensure user's freedom
is respected.[6] Due to QT being a primary component of KDE and many
applications, ensuring it is compiled correctly and removing non-free
software is of even greater importance to the free software movement.

For our freedom's sake, free software projects should take care about
all kinds of freedom issues when deciding what components to depend on.

We are hopeful that the various projects currently working with Chromium
source code will make Chromium fully respect both users' freedom and
users' privacy, making the internet safer, as well as more freedom
respecting, for everyone.


1.
https://lintian.debian.org/maintainer/pkg-chromium-***@lists.alioth.debian.org.html#chromium-browser
2. https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
3.
http://www.pcworld.com/article/2940499/ok-google-hotword-detection-yanked-from-chromium-after-user-revolt.html
4.
https://trac.torproject.org/projects/tor/wiki/doc/ImportantGoogleChromeBugs
5. https://github.com/Eloston/ungoogled-chromium
6. http://doc.qt.io/qt-5/qtwebengine-features.html#audio-and-video-codecs

This is Free work, you can redistribute it and/or modify it under the
terms of either:
The Creative Commons Attribution-ShareAlike 4.0 International License as
published by Creative Commons; either version 4.0, or (at your option)
any later version, or
The GNU Free Documentation License as published by the Free Software
Foundation; either version 1.3, or (at your option) any later version;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts

-------------------------



Sincerely,
Luke

[Isaac David]

Post by Luke
Users should be aware that QTWebengine is based on Chromium and
therefore contains many of the same flaws.

This assertion in particular raises some alarms. I don't
think that was ever established to be the case; and
insofar as the suspicion goes, both KDE and Qt developers
denied it[1][2] and even updated their documentation in
accordance to our concerns[3].

Is your view still that Qt Webengine poses a problem to
free distros, and if so, why?

PS: as for the proprietary codecs, it seems to me that
Arch-based distros are one comment away[4] from building
a fully FSDG-compliant version.

[1]:
http://lists.qt-project.org/pipermail/qtwebengine/2017-January/000409.html
[2]: https://bugs.kde.org/show_bug.cgi?id=374808
[3]: https://wiki.qt.io/QtWebEngine
[4]:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/qt5-webengine#n45

[Luke]

Post by Isaac David

Post by Luke
Users should be aware that QTWebengine is based on Chromium and
therefore contains many of the same flaws.

This assertion in particular raises some alarms. I don't
think that was ever established to be the case; and
insofar as the suspicion goes, both KDE and Qt developers
denied it[1][2] and even updated their documentation in
accordance to our concerns[3].
Is your view still that Qt Webengine poses a problem to
free distros, and if so, why?

When I asked their development team whether or not they use
ungoogled-chromium patches, they continued to say those patches do not
apply to them as they used a "stripped down version".
(e.g. they delete large parts of the /browser and /ui directories) I
haven't done extensive review, but as of the date of the e-mail there
was still some freedom issues and plenty of links to Google.com which
could still be stripped out.

List of good patches:
https://github.com/Eloston/ungoogled-chromium/tree/master/resources/patches

Compare to QTWebengine's (outdated) Chromium:
https://github.com/qt/qtwebengine-chromium

Among the issues that stuck out to me were...
- WideVine DRM support.
https://github.com/qt/qtwebengine-chromium/tree/b45f07bfbe74c333f1017810c2409e1aa6077a1b/chromium/third_party/widevine/cdm
- Debian freedom patches not applied, e.g. files missing licenses:
https://github.com/Eloston/ungoogled-chromium/blob/077e441e6654e4658de37c9d665e58f61b262961/resources/packaging/debian/buster/source/lintian-overrides
https://github.com/qt/qtwebengine-chromium/blob/b45f07bfbe74c333f1017810c2409e1aa6077a1b/chromium/tools/trace/trace_data.js
- There may still be connections made to Google API.
https://github.com/qt/qtwebengine-chromium/search?p=2&q=%22www.googleapis.com%22&type=&utf8=%E2%9C%93

Having the /browser folder removed is certainly a good start, I'm just
not convinced they completely resolved it in their fork. So far
ungoogled-chromium is the only project I've compiled and ran with
Wireshark that did not have random connections to Google.com while the
browser is idling.

[Luke Shumaker]

On Mon, 02 Apr 2018 18:53:25 -0400,

Post by Luke
Among the issues that stuck out to me were...
- WideVine DRM support.
https://github.com/qt/qtwebengine-chromium/tree/b45f07bfbe74c333f1017810c2409e1aa6077a1b/chromium/third_party/widevine/cdm

Is libwidevinecdm.so, or a way to download it, ending up in the build?
If not, this isn't a issue. I don't see the libwidevinecdm.so binary,
and I don't see any of the URLs where it can be downloaded.

--
Happy hacking,
~ Luke Shumaker

[Luke]

Post by Luke Shumaker
On Mon, 02 Apr 2018 18:53:25 -0400,

Post by Luke
Among the issues that stuck out to me were...
- WideVine DRM support.
https://github.com/qt/qtwebengine-chromium/tree/b45f07bfbe74c333f1017810c2409e1aa6077a1b/chromium/third_party/widevine/cdm

Is libwidevinecdm.so, or a way to download it, ending up in the build?
If not, this isn't a issue. I don't see the libwidevinecdm.so binary,
and I don't see any of the URLs where it can be downloaded.
--
Happy hacking,
~ Luke Shumaker

By default the support is there for the plugin, but the plugin itself
does not appear in the build.

As per the AUR:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=qt5-webengine-widevine
the plugin has to be downloaded separately, at which point it can be used.
So not a major issue, so as long as the non-free plugin is not on the
users system. This and the ability to have a -proprietary-codecs useflag
are good improvements that the QT team has done.

[Isaac David]

I was about to say that, although worrisome, spyware capabilities
have no impact in determining whether a piece of software belongs
in a FSDG distro or not. Good thing I double-checked with the
guidelines, because they actually do.

[A]s of the date of the e-mail there
was still some freedom issues and plenty of links to Google.com which
could still be stripped out.
https://github.com/Eloston/ungoogled-chromium/tree/master/resources/patches
https://github.com/qt/qtwebengine-chromium

This doesn't tell us much unfortunately.

https://github.com/Eloston/ungoogled-chromium/blob/077e441e6654e4658de37c9d665e58f61b262961/resources/packaging/debian/buster/source/lintian-overrides
https://github.com/qt/qtwebengine-chromium/blob/b45f07bfbe74c333f1017810c2409e1aa6077a1b/chromium/tools/trace/trace_data.js

What does that mean exactly? If I were to guess, lintian incorrectly
confused trace_data.js for a blob, and ungoogled-chromium is reversing
that overstep.

- There may still be connections made to Google API.
https://github.com/qt/qtwebengine-chromium/search?p=2&q=%22www.googleapis.com%22&type=&utf8=%E2%9C%93
I'm just
not convinced they completely resolved it in their fork. So far
ungoogled-chromium is the only project I've compiled and ran with
Wireshark that did not have random connections to Google.com while the
browser is idling.

By *the only project* do you mean you also tested with Qt
Webengine-based programs? Conclusions about Chromium need
not apply to Qt Webengine.

[Luke Shumaker]

On Tue, 03 Apr 2018 16:40:09 -0400,

Post by Isaac David

Post by Luke
https://github.com/Eloston/ungoogled-chromium/blob/077e441e6654e4658de37c9d665e58f61b262961/resources/packaging/debian/buster/source/lintian-overrides
https://github.com/qt/qtwebengine-chromium/blob/b45f07bfbe74c333f1017810c2409e1aa6077a1b/chromium/tools/trace/trace_data.js

What does that mean exactly? If I were to guess, lintian incorrectly
confused trace_data.js for a blob, and ungoogled-chromium is reversing
that overstep.

IDK about the trace_data bits, but the jsmin license bits look like
real freedom issue:

# temporarily allowing (need to fix path in Files-Excluded)
license-problem-json-evil third_party/trace-viewer/tracing/third_party/tvcm/third_party/rjsmin/bench/jsmin.c
license-problem-json-evil third_party/trace-viewer/tracing/third_party/tvcm/third_party/rjsmin/bench/jsmin.py

That said, it seems that that code was purged from upstream Chromium
in 2009 / v1.3.14 (based on the ChangeLog)?

So... why is it coming up?

[Luke]

Post by Luke Shumaker
On Tue, 03 Apr 2018 16:40:09 -0400,

Post by Isaac David

Post by Luke
https://github.com/Eloston/ungoogled-chromium/blob/077e441e6654e4658de37c9d665e58f61b262961/resources/packaging/debian/buster/source/lintian-overrides
https://github.com/qt/qtwebengine-chromium/blob/b45f07bfbe74c333f1017810c2409e1aa6077a1b/chromium/tools/trace/trace_data.js

What does that mean exactly? If I were to guess, lintian incorrectly
confused trace_data.js for a blob, and ungoogled-chromium is reversing
that overstep.

IDK about the trace_data bits, but the jsmin license bits look like
# temporarily allowing (need to fix path in Files-Excluded)
license-problem-json-evil third_party/trace-viewer/tracing/third_party/tvcm/third_party/rjsmin/bench/jsmin.c
license-problem-json-evil third_party/trace-viewer/tracing/third_party/tvcm/third_party/rjsmin/bench/jsmin.py
That said, it seems that that code was purged from upstream Chromium
in 2009 / v1.3.14 (based on the ChangeLog)?
So... why is it coming up?

That file appears to have been removed on the most recent upstream sync,
as you said, so no longer an issue.
https://github.com/qt/qtwebengine-chromium/search?utf8=%E2%9C%93&q=tvcm&type=

[Luke]

Post by Isaac David
I was about to say that, although worrisome, spyware capabilities
have no impact in determining whether a piece of software belongs
in a FSDG distro or not. Good thing I double-checked with the
guidelines, because they actually do.

Yes, per: "The distro must contain no DRM, no back doors, and no spyware."
https://www.gnu.org/distros/free-system-distribution-guidelines.html

Post by Isaac David

[A]s of the date of the e-mail there
was still some freedom issues and plenty of links to Google.com which
could still be stripped out.
https://github.com/Eloston/ungoogled-chromium/tree/master/resources/patches
https://github.com/qt/qtwebengine-chromium

This doesn't tell us much unfortunately.

The patches mention various places where Google API and pre-compiled
binaries are being removed, obviously QT is 4 years behind the latest
patches which makes it more difficult to do a 1:1 comparison.
I would say many of the issues are resolved due to their scrubbing.

Post by Isaac David

https://github.com/Eloston/ungoogled-chromium/blob/077e441e6654e4658de37c9d665e58f61b262961/resources/packaging/debian/buster/source/lintian-overrides
https://github.com/qt/qtwebengine-chromium/blob/b45f07bfbe74c333f1017810c2409e1aa6077a1b/chromium/tools/trace/trace_data.js

What does that mean exactly? If I were to guess, lintian incorrectly
confused trace_data.js for a blob, and ungoogled-chromium is reversing
that overstep.

Yes, it was presumed to be a blob by Debian (and it is currently missing
license header)

Post by Isaac David

- There may still be connections made to Google API.
https://github.com/qt/qtwebengine-chromium/search?p=2&q=%22www.googleapis.com%22&type=&utf8=%E2%9C%93
I'm just
not convinced they completely resolved it in their fork. So far
ungoogled-chromium is the only project I've compiled and ran with
Wireshark that did not have random connections to Google.com while the
browser is idling.

By *the only project* do you mean you also tested with Qt
Webengine-based programs? Conclusions about Chromium need
not apply to Qt Webengine.

Of the projects I've tested: Ungoogled-chromium - no google connections
found presently, Inox - Leaks google account data on settings page
(fixed in recent commit)
I have not used QTWebengine in over a year and never ran a leak test. -
If someone has the time to do this and verify there are no freedom
issues, they can be removed from the conclusion as you mentioned.

[KRT Listmaster]

On 04/03/2018 05:18 PM, Luke wrote:

[...]

Post by Luke
I have not used QTWebengine in over a year and never ran a leak test. -
If someone has the time to do this and verify there are no freedom
issues, they can be removed from the conclusion as you mentioned.

I've been monitoring QupZilla 2.0.1 (with the built-in adblocker turned
off) using Qt5 5.7.1 and QtWebEngine 5.6.1 through Wireshark 2.4.5 and I
see absolutely no outgoing requests that aren't due to NTP or handshakes
with my LAN router. With this configuration, there are no domains or IP
addresses that I cannot account for based on background system connectivity.

Even with the latest IceCat, I see plenty of requests to *.mozilla.com
and *.mozaws.com, for example.

Almost every functional browser I've tried has at least a few outgoing
requests. However, during the past hour of solid monitoring with
QupZilla idling and no other applications open, there is nothing
happening in WireShark at all that isn't system related, much to my
pleasant surprise.

I will try some newer versions of Qt5 as well as a newer version of
QupZilla just to see if there are any differences. However, from my
preliminary investigations, I would be willing to say that QtWebEngine
(5.6.1) does not, by itself, make outgoing requests while idling.

Is there anything more specific I should be looking for? Other behavior
besides idling, for example? There were some requests from QupZilla
before I turned of the native adblocker, so I eliminated that to focus
only on the QtWebEngine.

thanks,

-krt

[Henry Jensen]

Am 4. April 2018 17:58:51 MESZ schrieb KRT Listmaster <***@beauxbead.com>:
.

Post by KRT Listmaster
I will try some newer versions of Qt5 as well as a newer version of
QupZilla just to see if there are any differences. However, from my
preliminary investigations, I would be willing to say that QtWebEngine
(5.6.1) does not, by itself, make outgoing requests while idling.

Thanks for sharing your findings. Please note, that qupzilla is deprecated and the devs recommend to switch to Falkon browser [0].

Regards,

Henry

[0] https://www.falkon.org

[Luke]

Post by KRT Listmaster
[...]

Post by Luke
I have not used QTWebengine in over a year and never ran a leak test. -
If someone has the time to do this and verify there are no freedom
issues, they can be removed from the conclusion as you mentioned.

I've been monitoring QupZilla 2.0.1 (with the built-in adblocker turned
off) using Qt5 5.7.1 and QtWebEngine 5.6.1 through Wireshark 2.4.5 and I
see absolutely no outgoing requests that aren't due to NTP or handshakes
with my LAN router. With this configuration, there are no domains or IP
addresses that I cannot account for based on background system connectivity.
Even with the latest IceCat, I see plenty of requests to *.mozilla.com
and *.mozaws.com, for example.
Almost every functional browser I've tried has at least a few outgoing
requests. However, during the past hour of solid monitoring with
QupZilla idling and no other applications open, there is nothing
happening in WireShark at all that isn't system related, much to my
pleasant surprise.
I will try some newer versions of Qt5 as well as a newer version of
QupZilla just to see if there are any differences. However, from my
preliminary investigations, I would be willing to say that QtWebEngine
(5.6.1) does not, by itself, make outgoing requests while idling.
Is there anything more specific I should be looking for? Other behavior
besides idling, for example? There were some requests from QupZilla
before I turned of the native adblocker, so I eliminated that to focus
only on the QtWebEngine.
thanks,
-krt

Thanks for testing!

Keep in mind that QTWebengine can be compiled/configured a variety of ways.
You'll want try to trigger these parts of code:
https://github.com/qt/qtwebengine-chromium/search?p=2&q=%22www.googleapis.com%22&type=&utf8=%E2%9C%93
GeoLocation/GDrive/Gaia/GoogleNow/etc. This will likely vary depending
on the front-end you're using. Projects using the engine can be
configured to not execute this code, which is how it should be.

Testing Faclon could be a good next step as Henry mentioned.

Re: IceCat... They've not removed several background preferences, but
that is another issue outside the scope of this thread. It's important
to test all applications for such leaks if you're in an environment
where not having an IP leak is essential.
You can view the comments here for reference:
https://git.hyperbola.info:50100/packages/extra.git/tree/iceweasel-hardened-preferences/iceweasel-branding.js#n1009
Any additional testing/research you can do is good for the free software
movement, and appreciated!

[KRT Listmaster]

Post by Luke

Post by KRT Listmaster
[...]

Post by Luke
I have not used QTWebengine in over a year and never ran a leak test. -
If someone has the time to do this and verify there are no freedom
issues, they can be removed from the conclusion as you mentioned.

I've been monitoring QupZilla 2.0.1 (with the built-in adblocker turned
off) using Qt5 5.7.1 and QtWebEngine 5.6.1 through Wireshark 2.4.5 and I
see absolutely no outgoing requests that aren't due to NTP or handshakes
with my LAN router. With this configuration, there are no domains or IP
addresses that I cannot account for based on background system connectivity.
Even with the latest IceCat, I see plenty of requests to *.mozilla.com
and *.mozaws.com, for example.
Almost every functional browser I've tried has at least a few outgoing
requests. However, during the past hour of solid monitoring with
QupZilla idling and no other applications open, there is nothing
happening in WireShark at all that isn't system related, much to my
pleasant surprise.
I will try some newer versions of Qt5 as well as a newer version of
QupZilla just to see if there are any differences. However, from my
preliminary investigations, I would be willing to say that QtWebEngine
(5.6.1) does not, by itself, make outgoing requests while idling.
Is there anything more specific I should be looking for? Other behavior
besides idling, for example? There were some requests from QupZilla
before I turned of the native adblocker, so I eliminated that to focus
only on the QtWebEngine.
thanks,
-krt

Thanks for testing!
Keep in mind that QTWebengine can be compiled/configured a variety of ways.
https://github.com/qt/qtwebengine-chromium/search?p=2&q=%22www.googleapis.com%22&type=&utf8=%E2%9C%93
GeoLocation/GDrive/Gaia/GoogleNow/etc. This will likely vary depending
on the front-end you're using. Projects using the engine can be
configured to not execute this code, which is how it should be.
Testing Faclon could be a good next step as Henry mentioned.
Re: IceCat... They've not removed several background preferences, but
that is another issue outside the scope of this thread. It's important
to test all applications for such leaks if you're in an environment
where not having an IP leak is essential.
https://git.hyperbola.info:50100/packages/extra.git/tree/iceweasel-hardened-preferences/iceweasel-branding.js#n1009
Any additional testing/research you can do is good for the free software
movement, and appreciated!

Thank you for pointing me towards Falkon. I didn't see that in relation
to my current distro (Slackware-based), so I spun up a virtual machine
and installed the latest Manjaro iso, and quickly installed both
Wireshark 2.5.1 and Falkon 3.0.0 (based on QtWebEngine 5.10.1) and
started monitoring.

I had to turn off the built-in adblocker again, same reason as before,
and I also turned off an unrelated NetworkManager connectivity ping to
archlinux.org that was confusing me at first.

After setting Falkon to start up on a blank page, I restarted the
Wireshark monitor and restarted Falkon. Literally, for the last hour,
the ONLY requests I'm seeing at all are ICMPv6 router requests (probably
related to the VM) about once every 15 minutes, even without the browser
open. From Falkon, I see nothing, it's total crickets.

I spent some time fiddling around in the preferences menu, but that
triggered no requests at all. I eventually went to a website that I
control that I know has no external requests, and I let it sit there for
another hour. All I saw there were keepalive requests that specific
domain and nothing else.

I gotta say, even the latest Falkon built on QtWebEngine 5.10.1 seems to
not make any outgoing requests while idling at all. The only reason I
mentioned IceCat before was just to point out "Yep, I am catching idling
browser requests, even from browsers that I use and trust regularly, so
this Wireshark thing really works...". I wasn't trying to pick on
IceCat at all, quite the contrary. Just using it as a reference
browser, for comparison.

I might not have time right away to start rebuilding Qt5 from source
with different flags (it's a huge package, takes forever on my systems).
I think the point of this exercise was to evaluate a stock browser
based on QtWebEngine without having to tweak it too much (just turned
off the adblocker is all), and see what outgoing requests were being
made, if any. Contrast this with an idling Chromium, which spewed out
countless google.com and gstatic.com requests on an ongoing basis, for
example. It seems that whatever googliness that is baked into Chromium
has indeed really been stripped out of QtWebEngine as the developers
suggest. I don't see any evidence to the contrary.

Are there any relatively simple ways of checking for the other request
triggers you mentioned beyond recompiling Qt5 with different flags? The
stock build seems fairly clean to me.

thanks,

- krt

[Luke]

Post by KRT Listmaster
I might not have time right away to start rebuilding Qt5 from source
with different flags (it's a huge package, takes forever on my systems).
I think the point of this exercise was to evaluate a stock browser
based on QtWebEngine without having to tweak it too much (just turned
off the adblocker is all), and see what outgoing requests were being
made, if any. Contrast this with an idling Chromium, which spewed out
countless google.com and gstatic.com requests on an ongoing basis, for
example. It seems that whatever googliness that is baked into Chromium
has indeed really been stripped out of QtWebEngine as the developers
suggest. I don't see any evidence to the contrary.
Are there any relatively simple ways of checking for the other request
triggers you mentioned beyond recompiling Qt5 with different flags? The
stock build seems fairly clean to me.
thanks,
- krt

Good to see Falcon came clean, I don't know any easy ways of thoroughly
testing it since each program can be configured differently.
Falcon can probably be white-listed as free software now.

Per QT Docs, as long as QTLocation is not compiled then Google APIs for
Geolocation should not execute.
https://wiki.qt.io/QtWebEngine/Features#HTML5_Geolocation

Also Per QT, Google OAth shouldn't execute so as long as the Google API
key is not included in the software.
http://blog.qt.io/blog/2017/01/25/connecting-qt-application-google-services-using-oauth-2-0/
(The same is true for Mozilla Firefox in both cases)

[KRT Listmaster]

Post by Luke
Per QT Docs, as long as QTLocation is not compiled then Google APIs for
Geolocation should not execute.
https://wiki.qt.io/QtWebEngine/Features#HTML5_Geolocation

Ah, ok, that makes sense. So, I browsed to http://browserleaks.com/geo/

in Falkon, and I did see some Google API activity happening in the
background that seemed as if the QtLocation is still compiled into this
version, at least. Bummer....

Post by Luke
Also Per QT, Google OAth shouldn't execute so as long as the Google API
key is not included in the software.
http://blog.qt.io/blog/2017/01/25/connecting-qt-application-google-services-using-oauth-2-0/
(The same is true for Mozilla Firefox in both cases)

I'm not sure if this is as easy to test as the other, because I don't
even have a google account to be authorized with. But if the Geolocation
feature is a hint, then I'd assume this is still turned on as well, at
least in this package, by default.

So, how would one go about testing OAuth? Would I need to have a google
account to test with? And if I can log into something like
openstreetmaps.org using my Google account info, is that OAuth, or am I
oversimplifying things?

And the solution for privacy-minded folks then would be to either avoid
QtWebEngine entirely, or else compile your own with these turned off at
compile time? Seems like a hassle....

thanks for helping me explore,

- krt

[bill-auger]

Post by KRT Listmaster
And the solution for privacy-minded folks then would be to either
avoid QtWebEngine entirely, or else compile your own with these
turned off at compile time? Seems like a hassle....

but that is exactly why this is being discussed here

if it can be determined precisely which FSDG problems exist, and ideally
the steps needed to make each program acceptable, then the FSDG distros
should address them, so that users do not need to

any concrete results should be noted on the libreplanet wiki[1] for
reference - the parabola your-freedom-blacklist[2] serves that same
purpose for parabola and the your-privacy-blacklist[3] does so
analogously for the ultra-privacy concerns that go beyond the FSDG -
even if each distro does not apply those, the recommendations on such a
list could be informative to users who would like to apply them
theirselves

it is hoped that these discussions can inform the actions of all FSDG
distros - if problems can be solved then i would hope to see
all FSDG distros apply those changes - if no solutions are found,
then i would hope to see all FSDG distros remove those programs until
appropriate solutions are found


[1]: https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines
[2]: https://git.parabola.nu/blacklist.git/tree/blacklist.txt
[3]: https://git.parabola.nu/blacklist.git/tree/your-privacy-blacklist.txt

[Adonay Felipe Nogueira]

Post by bill-auger
any concrete results should be noted on the libreplanet wiki[1] for
reference - the parabola your-freedom-blacklist[2] serves that same

I don't have enough time to work on evaluating Chromium now, but I must
point out that at Free Software Directory we do want evaluation of
famous software that deserves scrutiny ([1]), and I started an
evaluation of Chromium ([2]), although, again, I don't have time to
continue it. Feel free to continue it and update the torrent file for
the .csv or for the licensecheck output.

[1]
<https://directory.fsf.org/wiki/Free_Software_Directory:Free_software_evaluation>.

[2] <https://directory.fsf.org/wiki/Talk:Chromium>.
--
- Formas de contato: https://libreplanet.org/wiki/User:Adfeno#vCard

- Ativista do /software/ livre (não confundir com gratuito). Avaliador
da liberdade de /software/ e de /sites/.

- Membro do LibrePlanet Brasil:
https://libreplanet.org/wiki/Group:LibrePlanet_Brasil

- Comunicações sociais federadas padronizadas, onde o "social"
permanece independente do fornecedor.

- #DeleteWhatsApp. Use o pai dele, #XMPP, federado e com padrão
internacional: https://libreplanet.org/wiki/XMPP.pt

- #DeleteFacebook #DeleteInstagram #DeleteTwitter #DeleteYouTube. Use
redes sociais federadas que suportam #ActivityPub, padrão
internacional, como a rede Mastodon: https://joinmastodon.org/

- #DeleteNetflix #CancelNetflix. Evite #DRM:
https://www.defectivebydesign.org/

- Quer enviar arquivos para mim? Veja:
https://libreplanet.org/wiki/User:Adfeno#Arquivos

- Quer doar para mim, ou me contratar? Veja:
https://libreplanet.org/wiki/User:Adfeno#Suporte

- Minhas contribuições:
https://libreplanet.org/wiki/User:Adfeno#Contributions

[Donald Robertson]

Post by Adonay Felipe Nogueira

Post by bill-auger
any concrete results should be noted on the libreplanet wiki[1] for
reference - the parabola your-freedom-blacklist[2] serves that same

I don't have enough time to work on evaluating Chromium now, but I must
point out that at Free Software Directory we do want evaluation of
famous software that deserves scrutiny ([1]), and I started an
evaluation of Chromium ([2]), although, again, I don't have time to
continue it. Feel free to continue it and update the torrent file for
the .csv or for the licensecheck output.
[1]
<https://directory.fsf.org/wiki/Free_Software_Directory:Free_software_evaluation>.
[2] <https://directory.fsf.org/wiki/Talk:Chromium>.

I'd like to also encourage people here on the list to help out with the
Directory. A lot of the same issues we discuss here are relevant when
looking to add things to the Directory as well. Each week there is a
meeting in #fsf on freenode from 12pm EDT until 3pm EDT (16:00 - 19:00
UTC). If you want to chat about this or any other software freedom
question, or just dive in and help updating the Directory, we'd be glad
to have you there.

[Sam Geeraerts]

Op Fri, 6 Apr 2018 08:51:26 -0400

Post by Donald Robertson
I'd like to also encourage people here on the list to help out with
the Directory. A lot of the same issues we discuss here are relevant
when looking to add things to the Directory as well.

I feel like there's an opportunity for integration of the FSDG
blacklist and the Directory, but I'm not sure how. I think free
software with (past) issues can fit in the Directory, but not the
non-free software.

It seems like a shame to have 2 tools that list and discuss freedom
information per application when 1 might be sufficient.

[bill-auger]

Post by Sam Geeraerts
I feel like there's an opportunity for integration of the FSDG
blacklist and the Directory,

David Hedlund has recently begun an effort to cross-reference and
integrate them[1] and is looking for someone to help maintain it


[1]:
https://directory.fsf.org/wiki/Free_Software_Directory:Free_software_evaluation

[Jason Self]

Post by Isaac David
right off the bat, Debian's Chromium steers users towards nonfree
addons, just like their version of Firefox... obviously unacceptable
to FSF standards.

Yes, I know. This stems from a little bit of hand waving on my part. I
tried to touch on it with my comment that "while the DFSG and the
FSF's own criteria are not identical..." This conversation's been
about the licensing of the browser itself and, solely for that
purpose, Debian's decision is relevant there because the criteria are
the same. The add-on thing also needs addressing too. A repo to point
to consisting of free add-ons would be good. Perhaps something along
the lines of what was done for IceCat plugins to have a list of free
ones on the FSF's Free Software Directory would be a good thing.

[bill-auger]

Post by Jason Self
A repo to point
to consisting of free add-ons would be good. Perhaps something along
the lines of what was done for IceCat plugins to have a list of free
ones on the FSF's Free Software Directory would be a good thing.

free-domium ?
freedom-onium ?