Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On Sun 2018-04-08 11:53:31 AM - Sam wrote:
> 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


pgpeAohlji5RX.pgp
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[Sam Geeraerts]

Op Fri, 6 Apr 2018 08:51:26 -0400
schreef 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.

Re: [GNU-linux-libre] DSFG in perpetuity

[Donald Robertson]

On 04/06/2018 08:06 AM, Adonay Felipe Nogueira wrote:
>> 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]
> .
> 
> [2] .
> 

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.
-- 
Donald R. Robertson, III, J.D.
Licensing & Compliance Manager
Free Software Foundation
51 Franklin Street, Fifth Floor
Boston, MA 02110
Phone +1-617-542-5942
Fax +1-617-542-2652 ex. 56

Re: [GNU-linux-libre] DSFG in perpetuity

[Adonay Felipe Nogueira]

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

[2] .

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

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On Thu 2018-04-05 09:45:57 PM - KRT wrote:
> 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

Re: [GNU-linux-libre] DSFG in perpetuity

[KRT Listmaster]

On 04/05/2018 03:01 PM, Luke wrote:
> 
> 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

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

-- 
This email account is used for list management only.
https://strangetimes.observer/

Re: [GNU-linux-libre] DSFG in perpetuity

[Luke]

On 04/04/2018 11:53 PM, KRT Listmaster wrote
>>> 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)

Re: [GNU-linux-libre] DSFG in perpetuity

[KRT Listmaster]

On 04/04/2018 04:39 PM, Luke wrote:
> On 04/04/2018 11:58 AM, KRT Listmaster wrote:
>> On 04/03/2018 05:18 PM, Luke wrote:
>>
>> [...]
>>
>>> 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=%22www.googleapis.com%22==%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!
> 
> 
> 


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 

Re: [GNU-linux-libre] DSFG in perpetuity

[Luke]

On 04/04/2018 11:58 AM, KRT Listmaster wrote:
> On 04/03/2018 05:18 PM, Luke wrote:
>
> [...]
>
>> 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=%22www.googleapis.com%22==%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!

Re: [GNU-linux-libre] DSFG in perpetuity

[Henry Jensen]

Am 4. April 2018 17:58:51 MESZ schrieb 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

Re: [GNU-linux-libre] DSFG in perpetuity

[KRT Listmaster]

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

[...]

> 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


-- 
This email account is used for list management only.
https://strangetimes.observer/

Re: [GNU-linux-libre] DSFG in perpetuity

[Luke]

On 04/03/2018 05:32 PM, Luke Shumaker wrote:
> On Tue, 03 Apr 2018 16:40:09 -0400,
> Isaac David wrote:
>>> - 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
>> 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?
>
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=tvcm=

Re: [GNU-linux-libre] DSFG in perpetuity

[Luke]

On 04/03/2018 04:40 PM, Isaac David wrote:
> 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
>
> Luke wrote :
>> [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.
>>
>> 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
>
> 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.

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

>
>> - There may still be connections made to Google API.
>> https://github.com/qt/qtwebengine-chromium/search?p=2=%22www.googleapis.com%22==%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.

Re: [GNU-linux-libre] DSFG in perpetuity

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

Luke wrote :

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

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


This doesn't tell us much unfortunately.


- 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


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=%22www.googleapis.com%22==%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.

--
Isaac David
GPG: 38D33EF29A7691134357648733466E12EC7BA943
Ring: c8ba5620e080bef9470efb314c257304ff9480f5
Tox: 
0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C

Re: [GNU-linux-libre] DSFG in perpetuity

[Luke]

On 04/02/2018 09:21 PM, Luke Shumaker wrote:
> On Mon, 02 Apr 2018 18:53:25 -0400,
> Luke wrote:
>> 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.




signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[Luke Shumaker]

On Mon, 02 Apr 2018 18:53:25 -0400,
Luke wrote:
> 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

Re: [GNU-linux-libre] DSFG in perpetuity

[Luke]

On 04/01/2018 11:13 PM, Isaac David wrote:
> Luke  wrote :
>> 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=%22www.googleapis.com%22==%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.





signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[Isaac David]

Luke  wrote :

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


--
Isaac David
GPG: 38D33EF29A7691134357648733466E12EC7BA943
Ring: c8ba5620e080bef9470efb314c257304ff9480f5
Tox: 
0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C

Re: [GNU-linux-libre] DSFG in perpetuity

[Luke Shumaker]

On Mon, 26 Mar 2018 07:09:47 -0400,
bill-auger wrote:
> 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.

-- 
Happy hacking,
~ Luke Shumaker

Re: [GNU-linux-libre] DSFG in perpetuity

[Luke]

> Subject: Re: [GNU-linux-libre] DSFG in perpetuity
> Date: Mon, 26 Mar 2018 16:41:52 -0400
> From: bill-auger <bill-auger@peers.community>
> Reply-To: Workgroup for fully free GNU/Linux distributions
> <gnu-linux-libre@nongnu.org>
> To: gnu-linux-libre@nongnu.org
>
> On 03/26/2018 03:27 PM, Donald Robertson wrote:
>> 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 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 +
From:   Luke <g...@openmailbox.org>
To: r...@gnu.org



On 01/30/2017 02:49 AM, Richard Stallman wrote:

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

Re: [GNU-linux-libre] DSFG in perpetuity

[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


On 03/28/2018 01:30 AM, Jean Louis wrote:
> 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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[Jean Louis]

On Tue, Mar 27, 2018 at 02:28:39PM -0400, bill-auger wrote:
> 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

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/27/2018 02:28 PM, bill-auger wrote:
> 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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/27/2018 09:39 AM, Chris Lamb wrote:
> 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
> 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


On 03/27/2018 09:39 AM, Chris Lamb wrote:
> "Clobbered" is, again, not quite accurate; there was indeed a "pureos2"
> upload but it did not revert or change anything related to the above:

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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

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

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

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

> > initramfs-tools_0.130pureos2 has already clobbered
> > initramfs-tools_0.130pureos1

"Clobbered" is, again, not quite accurate; there was indeed a "pureos2"
upload but it did not revert or change anything related to the above:

> > or the debian patch:

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,

-- 
Chris Lamb
https://puri.sm

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/26/2018 09:26 PM, Isaac David wrote:
> 
> [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/msg3.html
[2]:
https://lists.gnu.org/archive/html/directory-discuss/2017-12/msg8.html




signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/26/2018 09:26 PM, Isaac David wrote:
> in my mind it's only the [case against Qt-Webengine] (at Parabola)
> that rests of pretty shaky grounds:


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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/26/2018 10:42 PM, Jason Self wrote:
> 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 ?



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[Jason Self]

Isaac David  wrote ..

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

Re: [GNU-linux-libre] DSFG in perpetuity

[Isaac David]

Jason Self wrote :

bill-auger wrote :


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

   Recommended Fix:
 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

--
Isaac David
GPG: 38D33EF29A7691134357648733466E12EC7BA943
Ring: c8ba5620e080bef9470efb314c257304ff9480f5
Tox: 
0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/26/2018 06:02 PM, Jean Louis wrote:
> There must be some reason why there are many
> topics and posts on Trisquel forum:


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/



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[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

On Mon, Mar 26, 2018 at 05:48:20PM -0400, bill-auger wrote:
> 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

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/26/2018 05:35 PM, Donald Robertson wrote:
> 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"



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/26/2018 05:08 PM, Donald Robertson wrote:
> 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*



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[Donald Robertson]

On 03/25/2018 11:58 PM, bill-auger wrote:
> On 03/25/2018 11:35 PM, Robert Call wrote:
>> 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.
-- 
Donald R. Robertson, III, J.D.
Licensing & Compliance Manager
Free Software Foundation
51 Franklin Street, Fifth Floor
Boston, MA 02110
Phone +1-617-542-5942
Fax +1-617-542-2652 ex. 56



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[Donald Robertson]

On 03/26/2018 04:41 PM, bill-auger wrote:
> On 03/26/2018 03:27 PM, Donald Robertson wrote:
>> 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
> 

Yes, I apologize if 'guidance' wasn't clear, I meant that we're going to
make a decision and share that with the list.
-- 
Donald R. Robertson, III, J.D.
Licensing & Compliance Manager
Free Software Foundation
51 Franklin Street, Fifth Floor
Boston, MA 02110
Phone +1-617-542-5942
Fax +1-617-542-2652 ex. 56



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/26/2018 03:27 PM, Donald Robertson wrote:
> 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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/26/2018 10:15 AM, Jason Self wrote:
> 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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[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 . In short, file a bug
with the project, email us at report-nonf...@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
 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.

-- 
Donald R. Robertson, III, J.D.
Licensing & Compliance Manager
Free Software Foundation
51 Franklin Street, Fifth Floor
Boston, MA 02110
Phone +1-617-542-5942
Fax +1-617-542-2652 ex. 56



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[Henry Jensen]

Am Mon, 26 Mar 2018 09:01:51 -0700 (PDT)
schrieb "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. 

Re: [GNU-linux-libre] DSFG in perpetuity

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

Re: [GNU-linux-libre] DSFG in perpetuity

[Jason Self]

Henry Jensen  wrote ..
> 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.

Re: [GNU-linux-libre] DSFG in perpetuity

[Julie Marchant]

On 2018年03月26日 10:31, Jason Self wrote:
> 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?

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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[Henry Jensen]

Am Mon, 26 Mar 2018 07:31:56 -0700 (PDT)
schrieb "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.

Re: [GNU-linux-libre] DSFG in perpetuity

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

Re: [GNU-linux-libre] DSFG in perpetuity

[Henry Jensen]

Am Mon, 26 Mar 2018 06:58:54 -0400
schrieb 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: :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.

Re: [GNU-linux-libre] DSFG in perpetuity

[Jason Self]

bill-auger  wrote ..

> chromium is however not one of those items - and i quote:
> 
>   Recommended Fix:
> 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.

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/26/2018 06:32 AM, Zlatan Todoric wrote:
> 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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/25/2018 05:58 AM, Zlatan Todoric wrote:
> 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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[Zlatan Todoric]

On 03/26/2018 04:24 AM, bill-auger wrote:
> On 03/25/2018 01:26 PM, Zlatan Todoric wrote:
>> 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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/25/2018 11:47 PM, Jason Self wrote:
> 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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/25/2018 11:35 PM, Robert Call wrote:
> 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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[Jason Self]

Robert Call  wrote ..

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

Re: [GNU-linux-libre] DSFG in perpetuity

[Robert Call]

On Sun, 2018-03-25 at 23:17 -0400, bill-auger wrote:
> On 03/25/2018 04:22 PM, Jason Self wrote:
> > 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)
b...@librecmc.org
https://librecmc.org

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/25/2018 01:26 PM, Zlatan Todoric wrote:
> 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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/25/2018 11:28 AM, Robert Call wrote:
> 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


On 03/25/2018 11:28 AM, Robert Call wrote:
> 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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[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


On 03/25/2018 05:58 AM, Zlatan Todoric wrote:
> 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
> 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


On 03/25/2018 05:58 AM, Zlatan Todoric wrote:
> 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 

Re: [GNU-linux-libre] DSFG in perpetuity

[François Téchené]

On 25/03/2018 19:56, Robert Call wrote:
> 
> 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,

-- 
François Téchené
Director of Creative @ Purism

Re: [GNU-linux-libre] DSFG in perpetuity

[Jason Self]

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

> 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

Re: [GNU-linux-libre] DSFG in perpetuity

[Zlatan Todoric]

On 3/25/18 7:56 PM, Robert Call wrote:

On Sun, 2018-03-25 at 19:26 +0200, Zlatan Todoric wrote:

On 3/25/18 5:28 PM, Robert Call wrote:

On Sun, 2018-03-25 at 11:58 +0200, Zlatan Todoric wrote:

On 3/24/18 6:51 PM, bill-auger wrote:

* 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



* 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



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.






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 

Re: [GNU-linux-libre] DSFG in perpetuity

[Robert Call]

On Sun, 2018-03-25 at 19:26 +0200, Zlatan Todoric wrote:
> On 3/25/18 5:28 PM, Robert Call wrote:
> > On Sun, 2018-03-25 at 11:58 +0200, Zlatan Todoric wrote:
> > > On 3/24/18 6:51 PM, bill-auger wrote:
> > > > * 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
> > > 
> > > 
> > > > * 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
> > > 
> > > 
> > > > 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

Re: [GNU-linux-libre] DSFG in perpetuity

[Zlatan Todoric]

On 3/25/18 5:28 PM, Robert Call wrote:

On Sun, 2018-03-25 at 11:58 +0200, Zlatan Todoric wrote:

On 3/24/18 6:51 PM, bill-auger wrote:

* 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



* 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



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.




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 

Re: [GNU-linux-libre] DSFG in perpetuity

[Robert Call]

On Sun, 2018-03-25 at 11:58 +0200, Zlatan Todoric wrote:
> On 3/24/18 6:51 PM, bill-auger wrote:
> > 
> > * 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
> 
> 
> > 
> > * 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
> 
> 
> > 
> > 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)
b...@librecmc.org
https://librecmc.org

Re: [GNU-linux-libre] DSFG in perpetuity

[Zlatan Todoric]

On 3/24/18 6:51 PM, bill-auger wrote:
>
> * 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


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


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

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/24/2018 08:47 PM, Jason Self wrote:
> 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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/24/2018 09:20 PM, Robert Call wrote:
> 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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[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


On 03/24/2018 08:47 PM, Jason Self wrote:
> 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


On 03/24/2018 08:47 PM, Jason Self wrote:
> 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?



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[Julie Marchant]

On 2018年03月24日 20:47, Jason Self wrote:
> 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.

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



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

[Robert Call]

On Sat, 2018-03-24 at 13:51 -0400, bill-auger wrote:
> 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)
b...@bobcall.me
https://librecmc.org

Re: [GNU-linux-libre] DSFG in perpetuity

[bill-auger]

On 03/24/2018 08:47 PM, Jason Self wrote:
> 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"



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] DSFG in perpetuity

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

> 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