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