[GNU-linux-libre] what of the distros that have already asked for consideration or have been partially evaluated?

[bill-auger]

i just re-worded the work-flow related headings on the "incoming
distros" wiki page to avoid confusion - most notably the former heading:
"Distros ready to be evaluated by the FSF licensing team" which had four
distros listed beneath - that was changed to: "Distros that have
requested consideration"

those four distros are:

* connochaetos
* freeslack
* hyperbola
* libertybsd

the problem is that there is no indication here that those dostros
actually have requested consideration - previously, these entries have
been nominated by anyone (and perhaps without even informing the mailing
list) so it is not clear if all of these are actually interested in
endorsement - the ones that i added personally ('gnuinos' and 'heads')
were requested by their maintainers and i added their contact info to
the listing - i think contact info should be added for the others as
well - connochaetos and hyperbola i do know have a demonstrable history
on the mailing list of the maintainers interest so i added their contact
info - it is not clear though if freeslack or libertybsd have explicitly
expressed interest - without combing over the history myself, does
anyone know the history of these on this list?

or, should the "slate be wiped clean" and connochaetos, hyperbola, and
possibly the others be asked to start from the beginning of the new
protocol?

[bill-auger]

krt send this to me personally - i will repost

[...]

Post by bill-auger
info - it is not clear though if freeslack or libertybsd have explicitly
expressed interest - without combing over the history myself, does
anyone know the history of these on this list?

Yes, definitely the FreeSlack devs expressed explicit interest on this
list,

https://lists.nongnu.org/archive/html/gnu-linux-libre/2016-08/msg00003.html

and I would say the same for LibertyBSD as well.

https://lists.nongnu.org/archive/html/gnu-linux-libre/2014-12/msg00002.html
https://lists.nongnu.org/archive/html/gnu-linux-libre/2015-02/msg00003.html

thanks,
- krt

BTW - the actual OP for free-slack is here:
https://lists.nongnu.org/archive/html/gnu-linux-libre/2016-07/msg00021.html


ok thanks krt - those links are pretty convincing - so the real question
is "should these be grandfathered into the process and their entries
moved from "Distros that have requested consideration" to "Distros
currently being evaluated by the community" and have an evaluation
results page created for them immediately - or should they be asked to
start from the begining of the new protocol by sending email to the GNU
webmasters

if bypassing the GNU webmasters for these, the new protocol requires at
least that each be assigned a community review manager now

[KRT Listmaster]

Post by bill-auger
krt send this to me personally - i will repost

oops, I musta hit the wrong reply button. silly mistake on my part.
Thanks for catching, that, Bill, and for finding the original FreeSlack
post.

- krt

[Ivan Zaigralin]

A pretty good and very current summary of FreeSlack review process can be
found here:

https://www.freeslack.net/forum/index.php?t=msg&th=7&goto=15&#msg_15

[Henry Jensen]

Hi,

I just visited the website of freeslack and noted there is a link to
Eric Hameleers website right on the front page. On his website he does
prominently offer and links to several third-party packages, including
complete proprietary software, such as Adobe Flash Player.

Since this website is mentioned in a positive way on freeslack.net
one may be tempted to install this non-free software. I suggest to
remove this link.

Regards,

Henry



Am Wed, 21 Mar 2018 13:34:11 -0700

Post by Ivan Zaigralin
A pretty good and very current summary of FreeSlack review process
https://www.freeslack.net/forum/index.php?t=msg&th=7&goto=15&#msg_15

[KRT Listmaster]

Post by Henry Jensen
Hi,
I just visited the website of freeslack and noted there is a link to
Eric Hameleers website right on the front page. On his website he does
prominently offer and links to several third-party packages, including
complete proprietary software, such as Adobe Flash Player.
Since this website is mentioned in a positive way on freeslack.net
one may be tempted to install this non-free software. I suggest to
remove this link.
Regards,
Henry

That's a good point, thanks for pointing it out, it might indeed be
worth removing. Questions: should this criterion be applied across the
board? How does this differ from say, the PureOS website[1] having a
link to the Purism website[2] in the footer, which mentions plenty of
non-free software, including a tutorial on how to enable their own
non-free repo[3]. Just curious....

thanks,

- krt

[1] https://pureos.net/
[2] https://puri.sm/
[3]
https://puri.sm/posts/purism-patches-meltdown-and-spectre-variant-2-both-included-in-all-new-librem-laptops/

[Ivan Zaigralin]

Thanks for pointing this out, we can definitely improve the presentation here.

A quick nitpick: we do not mention Bob's website in a positive way. We mention
Slackware developers' and Bob's *efforts* in a positive way. To link a website
is not the same as to endorse its entire contents.

I think we can all agree that mere url linking cannot be construed as an
endorsement without a context to support that. In our case, the link from

https://freeslack.net/

is a bit iffy in that it provides no context and can be misinterpreted as an
endorsement. For this reason, and also because of the redundancy, I just
removed that blurb completely.

On the wiki page, though,

https://freeslack.net/dokuwiki/doku.php?id=start

This project could not have succeeded without the hard work of Slackware
developers and the alien technology courtesy of Eric Hameleers.

We have three links of interest on this front page: Slackware project front,
Eric's folder with free+libre code we borrowed from, and Eric's personal blog.
Here the context is clear: these are citations. These weblinks are just the
means of specifying which exactly Slackware project, which Eric, and which
free/libre upstream code we are referring to. These cannot and should not be
construed as endorsements. To make things crystal clear we can add to the
paragraph above an unequivocal un-endorsement of both entities (Slackware

While we do not endorse these upstream projects in any way,
our project could not have succeeded without the hard work of Slackware
developers and the alien technology courtesy of Eric Hameleers.

Please let us know your thoughts.

In response to KRT downthread, this kind of reasoning applies to any
free/libre distribution derived from a nonfree one. It would indeed be a
disservice to our users not to *cite* our software sources, especially since
the upstream determines 99.9% of the technical characteristics of our
distribution. It would also be extremely rude not to *credit* the upstream.

Hi,
I just visited the website of freeslack and noted there is a link to
Eric Hameleers website right on the front page. On his website he does
prominently offer and links to several third-party packages, including
complete proprietary software, such as Adobe Flash Player.
Since this website is mentioned in a positive way on freeslack.net
one may be tempted to install this non-free software. I suggest to
remove this link.
Regards,
Henry
Am Wed, 21 Mar 2018 13:34:11 -0700

Post by Ivan Zaigralin
A pretty good and very current summary of FreeSlack review process
https://www.freeslack.net/forum/index.php?t=msg&th=7&goto=15&#msg_15

[bill-auger]

Post by KRT Listmaster
That's a good point, thanks for pointing it out, it might indeed be
worth removing. Questions: should this criterion be applied across the
board? How does this differ from say, the PureOS website having a
link to the Purism website in the footer, which mentions plenty of
non-free software, including a tutorial on how to enable their own
non-free repo. Just curious....

all good questions - more than anything, i want to see *all* of the
rules applied equally across *all* software projects, large and small,
rich or poor, past present and future - what strikes me as notable here
is that (as i understand) the main gripe the FSF has with debian is not
so much that it hosts non-free repos (they are clearly isolated
after-all); but that they intentionally direct users to them and
instructs on how to use them on their website - ive looked over the
entire pureos website in the past and could find no explicit mention of
the non free repos; but if we are to make an issue of the website of
this prospective distro (free-slack) sporting external links to non-free
repos (or links to external sites on which are found links to non-free
repos) then we must, in all fairness, make issue of pureos linking to
the puri.sm website

which leads me back to my last question to this list from yesterday -
namely: "should a distro be grandfathered in all perpetuity once
endorsed with no further scrutiny of their on-going practices?" - the
proper thing to do in such cases is to report a freedom bug to the
distro - but what if they ignore it?[1]

as long as we are nit-picking about external links on distro's websites
- i also just noticed in the top-most navbar on the pureos front page an
icon of a tweeting bird that is a link to https://twitter.com/puri_sm -
so on the face of that one can say that pureos, rather than down-playing
the association with their commercial patron that hosts it's non-free
repos, instead guides users to it (at least indirectly) in multiple ways
- not problematic perhaps in itself, because the main distro site has no
explicit instruction how to use non-free repos; but as krt says the
commercial site does host non-free repos and instructs users on how to
access them

not to harp on that point - but i mention the tweeting bird because i
know that parabola for one, takes great care to remove all such
corporate logos rather than even hint at endorsing them - for example,
when firefox v57 was released and it was noticed that iceweasel v57
shown huge "quick-link" buttons with various website logos chosen by
mozilla on everyone's "new tab" page (of youtube, google, twitter, and
facebook IIRC) forcefully replacing where normally your pinned
"favorites" might be; this was reported as a bug the very same day and
those links were removed the same day - parabola would never knowingly
direct users to any website running non-free SAAS or that requires
non-free javascript to function; especially not intentionally on the
main page of the website - there is even an open ticket to remove the
"awesome" fonts package merely because it includes such logos[2] as glyphs

i just wanted to add that to underline that most of the FSDG distros do
seem to take very diligently to the task of avoiding to steer users in
the direction of proprietary software; but others seem to be very
cavalier about it - im not sure if parabola really needs to quite as
strict as they are; but i would very much like to see all FSDG distros
take some unified stance on such issues, whatever that stance may be -
that is why i hope the review guide page[3] will be used as a consensus
across distros on how to interpret the less defined caveats of the FSDG


[1]: https://tracker.pureos.net/T57
[2]: https://labs.parabola.nu/issues/1648
[3]: https://libreplanet.org/wiki/FSDG_Review_Guide

[bill-auger]

as i understand, the final issue preventing free-slack from being
endorsed is the word "slack" in their name - which is in conflict with
the "no name confusion" criteria

so one other thing to point out for the sake of equality is that the
connochaetos website refers to the repos it hosts as "The slack-n-free repo"

"free-slack"
"slack-n-free"

is it just me? - im not seeing a huge difference there - personally, my
opinion would be that neither are particularly offensive - "slack" is
not exactly "slackware" - just as i see no problem with the free-dora
repos hosted by FSFLA because "dora" is not "fedora" - although these
are all clearly intended to remind the reader that "this is the freed
version of that well-known one"

o/c these are not my rules to make; but please let us apply the same
rules equally to all

[Ivan Zaigralin]

I'd like to register my dislike of the subjective approach to the name
similarity issue as well. Not that it doesn't work. I think it works OK,
because this is not a particularly big deal to begin with. FreeSlack project,
for example, has always been flexible in that respect, as in, fully
cooperative. But it would be better to have an objective criterion, like for
example:

Cannot use nonfree distro name or trademark as a substring in a free distro
name.

A rule like this would prevent "Slackware Libre", but not "FreeSlack". But
more crucially, it would be fair, and no one would ever feel like an
individual reviewer at FSF is yanking their chain just for the fun of it.

Post by bill-auger
as i understand, the final issue preventing free-slack from being
endorsed is the word "slack" in their name - which is in conflict with
the "no name confusion" criteria
so one other thing to point out for the sake of equality is that the
connochaetos website refers to the repos it hosts as "The slack-n-free repo"
"free-slack"
"slack-n-free"
is it just me? - im not seeing a huge difference there - personally, my
opinion would be that neither are particularly offensive - "slack" is
not exactly "slackware" - just as i see no problem with the free-dora
repos hosted by FSFLA because "dora" is not "fedora" - although these
are all clearly intended to remind the reader that "this is the freed
version of that well-known one"
o/c these are not my rules to make; but please let us apply the same
rules equally to all

[Ivan Zaigralin]

P.S. To clarify my personal & institutional bias, here at FreeSlack the
consensus for the distro name is "Freenix" at the moment, so I don't have an
ulterior motive in making these suggestions.

Post by Ivan Zaigralin
I'd like to register my dislike of the subjective approach to the name
similarity issue as well. Not that it doesn't work. I think it works OK,
because this is not a particularly big deal to begin with. FreeSlack
project, for example, has always been flexible in that respect, as in,
fully cooperative. But it would be better to have an objective criterion,
Cannot use nonfree distro name or trademark as a substring in a free distro
name.
A rule like this would prevent "Slackware Libre", but not "FreeSlack". But
more crucially, it would be fair, and no one would ever feel like an
individual reviewer at FSF is yanking their chain just for the fun of it.

Post by bill-auger
as i understand, the final issue preventing free-slack from being
endorsed is the word "slack" in their name - which is in conflict with
the "no name confusion" criteria
so one other thing to point out for the sake of equality is that the
connochaetos website refers to the repos it hosts as "The slack-n-free repo"
"free-slack"
"slack-n-free"
is it just me? - im not seeing a huge difference there - personally, my
opinion would be that neither are particularly offensive - "slack" is
not exactly "slackware" - just as i see no problem with the free-dora
repos hosted by FSFLA because "dora" is not "fedora" - although these
are all clearly intended to remind the reader that "this is the freed
version of that well-known one"
o/c these are not my rules to make; but please let us apply the same
rules equally to all

[KRT Listmaster]

Disclaimer: I find this a particularly interesting conversation, and I
am posing genuine questions and thoughts that come to mind. I am not
trying to ruffle any feathers or step on any toes. With that in mind...

Post by Ivan Zaigralin
I'd like to register my dislike of the subjective approach to the name
similarity issue as well. Not that it doesn't work. I think it works OK,
because this is not a particularly big deal to begin with. FreeSlack project,
for example, has always been flexible in that respect, as in, fully
cooperative. But it would be better to have an objective criterion, like for
Cannot use nonfree distro name or trademark as a substring in a free distro
name.
A rule like this would prevent "Slackware Libre", but not "FreeSlack". But
more crucially, it would be fair, and no one would ever feel like an
individual reviewer at FSF is yanking their chain just for the fun of it.

There's a obvious limit to how far this goes. If this general concept
is pushed to it's logical extreme, then we'd have to drop the GNU-prefix
from everything as well. Because, doesn't the U stand for... Unix?

I started thinking about what a cool name for FreeSlack (which could be
seen as a general term taken from project management theory [1]) would
be if Freenix was rejected for some reason, and FXP wasn't accepted
either.

A couple of joke names came to mind, and I finally settled on:

§NH - which stands for §NH is Not Hyperbola

and was my way of avoiding

§NS , short for §NS is Not Slackware

and, only then I started to wonder if the negation makes things okay.

and then it all clicked into place.

GNU would fail this same criterion if proposed today. Just a thought.

;-)

- krt

[1]
https://www.coursera.org/learn/scope-time-management-cost/lecture/Gsh3x/free-slack

[Ivan Zaigralin]

Yes yes. And to continue with examples and policy suggestions, the minimal
length of forbidden substrings should probably be also set to something
specific. Like 3 letters is probably too short, because given a nonfree
project "ion", no one would be able to use names like "Motion" or "Lionheart".
This all may sound like fun and jokes, but I believe these are serious
concerns.

As I am writing this, I am informed that "Freenix" is approved for use :) This
is fantastic news for us, and a perfect prelude to what I will say here. What
is to stop a subjective name censor from rejecting "Freenix", for example, on
the grounds that it's "too similar" to "Unix"? And at what point the censors
will usurp this power to exercise de facto creative control over the
distribution naming? This is essentially an unchecked veto power over the
branding, and I think the best way to confront this problem is by making name
rules completely objective. No system will be perfect with respect to
*accuracy* when it comes to detecting *similarity*, so it makes sense to use a
system which offers OK accuracy, while being perfectly fair and impossible to
abuse from the position of power in the review process.

Once again, this is intended as a mild criticism of the existing process,
which I personally think worked just fine up to now. I am just fearing that
going forward will be wrought with peril, as the free software movement is
picking up steam, and more distributions come into picture, each with its own
individual issues and quirks. Unless the process is made more fair and more
robust, there will inevitably be a build-up of resentment due to subjective
name vetoes. And it won't even matter how well justified these vetoes will be,
really, the trust in the process will start to erode, and it would be great to
fix this issue before it even shows up on the radar.

Post by KRT Listmaster
Disclaimer: I find this a particularly interesting conversation, and I
am posing genuine questions and thoughts that come to mind. I am not
trying to ruffle any feathers or step on any toes. With that in mind...

Post by Ivan Zaigralin
I'd like to register my dislike of the subjective approach to the name
similarity issue as well. Not that it doesn't work. I think it works OK,
because this is not a particularly big deal to begin with. FreeSlack
project, for example, has always been flexible in that respect, as in,
fully cooperative. But it would be better to have an objective criterion,
Cannot use nonfree distro name or trademark as a substring in a free distro
name.
A rule like this would prevent "Slackware Libre", but not "FreeSlack". But
more crucially, it would be fair, and no one would ever feel like an
individual reviewer at FSF is yanking their chain just for the fun of it.

There's a obvious limit to how far this goes. If this general concept
is pushed to it's logical extreme, then we'd have to drop the GNU-prefix
from everything as well. Because, doesn't the U stand for... Unix?
I started thinking about what a cool name for FreeSlack (which could be
seen as a general term taken from project management theory [1]) would
be if Freenix was rejected for some reason, and FXP wasn't accepted
either.
§NH - which stands for §NH is Not Hyperbola
and was my way of avoiding
§NS , short for §NS is Not Slackware
and, only then I started to wonder if the negation makes things okay.
and then it all clicked into place.
GNU would fail this same criterion if proposed today. Just a thought.
;-)
- krt
[1]
https://www.coursera.org/learn/scope-time-management-cost/lecture/Gsh3x/free
-slack
--
This email account is used for list management only.
https://strangetimes.observer/

[bill-auger]

Post by KRT Listmaster
GNU would fail this same criterion if proposed today. Just a thought.

great point - i think it gets right to the core of that somewhat vague
criteria - although indefinite, the intention is clearly to avoid
confusion - there is no reasonable confusion in the name "GNU is not
UINX" - that is very explicitly a disclaimer of any association -
similarly "Free-Slack is not Slackware" should be as acceptable as
"GNU"; whereas "Free-Slackware" could be easily mis-interpreted -
"Free-Slack" falls in the grey area between because "slack" is a common
short-hand or nickname for "slackware"

but i will add that, if taken to the extreme interpretation, the same is
true for *every* distro that ends with *nix and i dont think anyone is
confused that any of them actually *are* associated with UNIX or bell
labs, nor that they are even attempting to imply any such thing -
after-all, the FSF endorsed "musix" - the *ix in that name is surely not
arbitrary; but a tip of the hat to UNIX - and musix was not expected to
disclaim that: "musix is not a musical unix"

"GNU" could be more accurately presented as "GNU is not UNIX - (but it
is very much like UNIX)" - fully acknowledging their work *by name*; but
still with no reasonable confusion or implications of association - the
manor of presentation seems to be very important here; so im not so sure
if this criteria could be made to be both rigid and comprehensive

[Jean Louis]

Post by bill-auger
ok thanks krt - those links are pretty convincing - so the real question
is "should these be grandfathered into the process and their entries
moved from "Distros that have requested consideration" to "Distros
currently being evaluated by the community" and have an evaluation
results page created for them immediately - or should they be asked to
start from the begining of the new protocol by sending email to the GNU
webmasters
if bypassing the GNU webmasters for these, the new protocol requires at
least that each be assigned a community review manager now

My suggestion is that FSF and volunteers skip the
common bureaucracy and skip to community review
manager right now to handle those distributions
that already applied.

Jean

[Jason Self]

https://lists.nongnu.org/archive/html/gnu-linux-libre/2016-07/msg00021.html

OK so freeslack can probably be updated that it's on hold pending a
name change. (Based on Donald's 2017-04-06 email quoted at
https://www.freeslack.net/forum/index.php?t=msg&th=7&goto=15&#msg_15)

Although do we still consider it on hold if it's been over a year?
Things can change in that time; perhaps distros should be expected to
re-apply and start from scratch in cases where a large amount of time
has gone by.

Perhaps this means that the section "Distros that are defunct or do
not comply with the GNU FSDG" needs updating.

[Ivan Zaigralin]

Post by bill-auger
https://lists.nongnu.org/archive/html/gnu-linux-libre/2016-07/msg00021.html
OK so freeslack can probably be updated that it's on hold pending a
name change. (Based on Donald's 2017-04-06 email quoted at
https://www.freeslack.net/forum/index.php?t=msg&th=7&goto=15&#msg_15)
Although do we still consider it on hold if it's been over a year?
Things can change in that time; perhaps distros should be expected to
re-apply and start from scratch in cases where a large amount of time
has gone by.

Erm, you would want distro maintainers to re-do the paperwork because FSF took
a year evaluating a simple query? Or, as it feels more likely in this
particular case, leaving it on the back burner and doing nothing at all?

I think it would be more in line with FSDG evaluation process to simply assume
that no new bugs crept in during this time, based on the fact that no bugs
were made known to maintainers via the mailing list or a private channel. This
is consistent with the existing policy of not continually evaluating the
distro after it's been accepted. Assuming good faith on the part of distro
maintainers, FSF currently hopes that *reported* freedom bugs will be fixed in
a timely manner. If there is an outstanding, reported bug which hasn't been
fixed in a specified period of time, then I think it is suitable to revoke the
certification, or to kick the approval process back to square 1.

In case with FreeSlack though, there are no outstanding freedom issues, and
the only open issue is in the FSF's court. I believe that re-doing the
application would be redundant, and would just waste everyone's time.

[Donald Robertson]

Post by Ivan Zaigralin

Post by bill-auger
https://lists.nongnu.org/archive/html/gnu-linux-libre/2016-07/msg00021.html
OK so freeslack can probably be updated that it's on hold pending a
name change. (Based on Donald's 2017-04-06 email quoted at
https://www.freeslack.net/forum/index.php?t=msg&th=7&goto=15&#msg_15)
Although do we still consider it on hold if it's been over a year?
Things can change in that time; perhaps distros should be expected to
re-apply and start from scratch in cases where a large amount of time
has gone by.

Erm, you would want distro maintainers to re-do the paperwork because FSF took
a year evaluating a simple query? Or, as it feels more likely in this
particular case, leaving it on the back burner and doing nothing at all?
I think it would be more in line with FSDG evaluation process to simply assume
that no new bugs crept in during this time, based on the fact that no bugs
were made known to maintainers via the mailing list or a private channel. This
is consistent with the existing policy of not continually evaluating the
distro after it's been accepted. Assuming good faith on the part of distro
maintainers, FSF currently hopes that *reported* freedom bugs will be fixed in
a timely manner. If there is an outstanding, reported bug which hasn't been
fixed in a specified period of time, then I think it is suitable to revoke the
certification, or to kick the approval process back to square 1.
In case with FreeSlack though, there are no outstanding freedom issues, and
the only open issue is in the FSF's court. I believe that re-doing the
application would be redundant, and would just waste everyone's time.

I don't think we need to ask for any additional paperwork here. As Ivan
pointed out, distros getting to this point should already have the
systems in place for maintaining their freedom status. And my part of
the process still involves a last check over issues. Perhaps if I find
lots of problems with a distro that arrives on my desk I could send it
back to the list for additional help. But we don't have to assume that
is needed just because a lot of time has passed.

[bill-auger]

Post by Donald Robertson
But we don't have to assume that
is needed just because a lot of time has passed.

i think that is a valid concern though - to allow for some "on-hold"
phase and for when it becomes clear that the distro maintainers are
expressing no interest or making significant progress towards
addressing issues - i propose this as an addendum to the protocol
description if this sounds reasonable to everyone:


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

* If at any time, it becomes clear that no significant progress is being
made toward addressing documented criteria discrepancies or
deficiencies, the application manager or the FSF licensing team may move
the distro's entry to the list under the 'Distros that are defunct or do
not comply with the GNU FSDG' heading; where they may sit indefinitely.
This could be considered as an some reasonably brief amount of time
(perhaps to assign a new application manager or grace period for the
distro maintainers to respond); but unless there is timely objection or
discussion by the distro maintainers, this may conclude the review
process and the application manager may be relieved of it's over-sight.
After the application manager steps down, the distro would need to
re-apply to the GNU webmasters to re-start the process. The state of the
checklist page and notes should be retained in order to inform future
reviewers or those who may fork or otherwise assume stewardship of the
distro.

[bill-auger]

Post by bill-auger
This could be considered as an some reasonably brief amount of time

oops - i hit 'cut' - that sentence was intended as:

This could be considered as an "on-hold" phase for some reasonably
brief amount of time

[Ivan Zaigralin]

I agree: if a distro can't fix a freedom bug for an extended period of time,
we should assume utter incompetence or bad faith, and there should be a path
to revoke/reset the certification. To keep things fair, some of that policy
should be written down. At the same time, not all freedom bugs are the same
severity, and not all of them are easy to fix, so it would probably pay to
remain flexible about time frames.

Post by bill-auger

Post by Donald Robertson
But we don't have to assume that
is needed just because a lot of time has passed.

i think that is a valid concern though - to allow for some "on-hold"
phase and for when it becomes clear that the distro maintainers are
expressing no interest or making significant progress towards
addressing issues - i propose this as an addendum to the protocol
----------------------------------
* If at any time, it becomes clear that no significant progress is being
made toward addressing documented criteria discrepancies or
deficiencies, the application manager or the FSF licensing team may move
the distro's entry to the list under the 'Distros that are defunct or do
not comply with the GNU FSDG' heading; where they may sit indefinitely.
This could be considered as an some reasonably brief amount of time
(perhaps to assign a new application manager or grace period for the
distro maintainers to respond); but unless there is timely objection or
discussion by the distro maintainers, this may conclude the review
process and the application manager may be relieved of it's over-sight.
After the application manager steps down, the distro would need to
re-apply to the GNU webmasters to re-start the process. The state of the
checklist page and notes should be retained in order to inform future
reviewers or those who may fork or otherwise assume stewardship of the
distro.

[bill-auger]

Post by Ivan Zaigralin
I agree: if a distro can't fix a freedom bug for an extended period of time,
we should assume utter incompetence or bad faith, and there should be a path
to revoke/reset the certification.

sure for those blatant reasons - but generally just to have a mechanism
to discourage stagnation or "petering out" of interest - to keep at the
least, the review manager and the distro maintainers exhibiting the
ambition to progress forward at some detectable speed - accommodating
also for the event that the distro maintainers are in good faith but
perhaps it is the review manager that is impeding progress

[bill-auger]

This is consistent with the existing policy of
not continually evaluating the distro after it's been accepted.

i dont think that is a formal policy - one of the strict criteria is to
be "actively maintained" - i would like to think that it is only the
case that no one has done any follow-up reviews - adfeno and myself did
just that last summer for perhaps the first time - there were some
significant issues to address and we created a dedicated wiki page[1] to
note them

there has been a long discussion of this recently whereby static
read-only "live" distros could probably be exempt but in most cases, i
think the consensus is that distros that are demonstrably defunct (such
as BLAG) should not be actively endorsed - and that should even perhaps
be extended to include those which exist but are unresponsive to the
community (such as proteanOS)

if it is the policy to distros to be grandfathered in all perpetuity, i
really do think that should be re-considered - at least in the cases
where there is no longer any concrete distro in existence and/or where
there is no maintainer participating on this list - i think these should
perhaps be moved to a category of "historical mention"


[1]: https://libreplanet.org/wiki/Periodic_Distro_Status_Review

[Jason Self]

Post by Ivan Zaigralin
Erm, you would want distro maintainers to re-do the paperwork
because FSF took a year evaluating a simple query?

No I don't. Notice that the date of Don's message to them is April 6
2017. So, I meant a year after the FSF got back to them.

But I see now that I had missed the part where the people of the
distro got back to them with name options so I mistakenly thought that
the FSF was waiting on the distro to change names. Since I now see
it's the opposite it renders my initial point moot.

[Jason Self]

Post by Jean Louis
My suggestion is that FSF and volunteers skip the
common bureaucracy and skip to community review
manager right now to handle those distributions
that already applied.

I had already looked at Hyperbola before the new process started.
Finding no problems I told Don about it and kicked the can over to the
FSF for the final decision.

[Donald Robertson]

Post by bill-auger
i just re-worded the work-flow related headings on the "incoming
"Distros ready to be evaluated by the FSF licensing team" which had four
distros listed beneath - that was changed to: "Distros that have
requested consideration"
* connochaetos
* freeslack
* hyperbola
* libertybsd

I've moved freeslack and libertybsd into the FSF review category, as
they both passed inspection on the list quite some time ago and had
started discussions with the licensing team, which I unfortunately
didn't keep running. But I'll get back on track with them.

Hyperbola had a fairly limited thread on this list.
<http://lists.nongnu.org/archive/html/gnu-linux-libre/2017-09/msg00016.html>.
But it seems to have just petered out. I think it would make sense to
ask if they are still interested, and if they are, to go ahead and run
them as a test case for how we process things on the list (i.e., assign
them a person in charge of their review). They didn't really get much of
a review previously, so I think taking the time to work through it now
would be reasonable.

connochaetos had a much longer discussion, and I believe is still
interested in endorsement (I will doublecheck that), but had an
outstanding issue that the list felt barred their endorsement. This is
the part in the process where we at the FSF have to make the final call.
So it's not quite 'ready for FSF review', but more like 'ready for
appeal'? I'm not quite sure how to word that. But going forward I want
to make sure that someone in their position gets a response from FSF staff.

Post by bill-auger
the problem is that there is no indication here that those dostros
actually have requested consideration - previously, these entries have
been nominated by anyone (and perhaps without even informing the mailing
list) so it is not clear if all of these are actually interested in
endorsement - the ones that i added personally ('gnuinos' and 'heads')
were requested by their maintainers and i added their contact info to
the listing - i think contact info should be added for the others as
well - connochaetos and hyperbola i do know have a demonstrable history
on the mailing list of the maintainers interest so i added their contact
info - it is not clear though if freeslack or libertybsd have explicitly
expressed interest - without combing over the history myself, does
anyone know the history of these on this list?
or, should the "slate be wiped clean" and connochaetos, hyperbola, and
possibly the others be asked to start from the beginning of the new
protocol?

[Henry Jensen]

Hi Donald,

ConnochaetOS maintainer here

Am Thu, 22 Mar 2018 15:57:43 -0400

Post by Donald Robertson
connochaetos had a much longer discussion, and I believe is still
interested in endorsement (I will doublecheck that), but had an
outstanding issue that the list felt barred their endorsement. This is
the part in the process where we at the FSF have to make the final
call. So it's not quite 'ready for FSF review', but more like 'ready
for appeal'? I'm not quite sure how to word that. But going forward I
want to make sure that someone in their position gets a response from
FSF staff.

* Yes, we are still interested in endorsement.

* It wasn't "the list" as such, it was one person on this list who
said because we are using a Debian derived blob-free kernel we
wouldn't fulfill the criteria for endorsement. However, PureOS was
endorsed with using basically the same Debian based kernel.

Regards,

Henry

[André Silva]

Post by Donald Robertson
Hyperbola had a fairly limited thread on this list.
<http://lists.nongnu.org/archive/html/gnu-linux-libre/2017-09/msg00016.html>.
But it seems to have just petered out. I think it would make sense to
ask if they are still interested, and if they are, to go ahead and run
them as a test case for how we process things on the list (i.e., assign
them a person in charge of their review). They didn't really get much of
a review previously, so I think taking the time to work through it now
would be reasonable.

Hi Donald, we are still interested in endorsement, let me know if you
need anything on our side.

By the way, I've improved our main wiki [0] and presentation [1] pages
for further details about our distribution.

[0]:https://wiki.hyperbola.info/doku.php?id=en:start
[1]:https://www.hyperbola.info/about/

[kurtis]

Hello,

I was wondering, should Hyperbola GNU/Linux-libre be moved to "Distros
currently being evaluated by the community" or to "Distros ready for
final review by the FSF" on the LibrePlanet wiki [1]? Has anyone else on
this list had time to review it? I did see it was reviewed at least once
[2].

Current release: Milky Way v0.2.3 [3]

Cordially,
kurtis

[1] https://libreplanet.org/wiki/Incoming_distros
[2]
https://lists.nongnu.org/archive/html/gnu-linux-libre/2017-10/msg00003.html
[3] https://www.hyperbola.info/news/milky-way-v023-install-medium-release/

Post by André Silva

Post by Donald Robertson
Hyperbola had a fairly limited thread on this list.
<http://lists.nongnu.org/archive/html/gnu-linux-libre/2017-09/msg00016.html>.
But it seems to have just petered out. I think it would make sense to
ask if they are still interested, and if they are, to go ahead and run
them as a test case for how we process things on the list (i.e., assign
them a person in charge of their review). They didn't really get much of
a review previously, so I think taking the time to work through it now
would be reasonable.

Hi Donald, we are still interested in endorsement, let me know if you
need anything on our side.
By the way, I've improved our main wiki [0] and presentation [1] pages
for further details about our distribution.
[0]:https://wiki.hyperbola.info/doku.php?id=en:start
[1]:https://www.hyperbola.info/about/

[bill-auger]

Post by kurtis
Hello,
I was wondering, should Hyperbola GNU/Linux-libre be moved to
"Distros
currently being evaluated by the community" or to "Distros ready for
final review by the FSF" on the LibrePlanet wiki [1]? Has anyone else on
this list had time to review it? I did see it was reviewed at least once
[2].
Current release: Milky Way v0.2.3 [3]
Cordially,
kurtis

that suggestion was noted about a month ago on this list

https://lists.nongnu.org/archive/html/gnu-linux-libre/2018-03/msg00016.
html

the message that you quoted was actually a direct reply to that
suggestion - and that reply says that there was not very much
evaluation of hyperbola noted on the list; and suggests that it would
be a good test run of the new protocol if hyperbola would start at the
beginning

[André Silva]

Post by bill-auger
that suggestion was noted about a month ago on this list
https://lists.nongnu.org/archive/html/gnu-linux-libre/2018-03/msg00016.
html
the message that you quoted was actually a direct reply to that
suggestion - and that reply says that there was not very much
evaluation of hyperbola noted on the list; and suggests that it would
be a good test run of the new protocol if hyperbola would start at the
beginning

I've responded to Donald that we are still interested in endorsement.
[0] So, i don't see problems if you would start at the beginning to test
run the new protocol for Hyperbola. :)

[0]:https://lists.nongnu.org/archive/html/gnu-linux-libre/2018-03/msg00025.html

[bill-auger]

Post by André Silva
I've responded to Donald that we are still interested in endorsement.
[0] So, i don't see problems if you would start at the beginning to test
run the new protocol for Hyperbola. :)

awesome so the procedure is detailed on the libreplenet wiki now[0] -
the very first step is note:

"The process begins with an application sent to <***@gnu.org>
for an initial review."

i think the idea there for that is for someone officially associated
with the distro initiates the process personally - to avoid having
distros where the distro themselves may not be interested being
proposed by outsiders


[0]: https://libreplanet.org/wiki/Incoming_distros#Endorsement_Process

[André Silva]

Post by bill-auger

Post by André Silva
I've responded to Donald that we are still interested in endorsement.
[0] So, i don't see problems if you would start at the beginning to test
run the new protocol for Hyperbola. :)

awesome so the procedure is detailed on the libreplenet wiki now[0] -
for an initial review."
i think the idea there for that is for someone officially associated
with the distro initiates the process personally - to avoid having
distros where the distro themselves may not be interested being
proposed by outsiders
[0]: https://libreplanet.org/wiki/Incoming_distros#Endorsement_Process

I've sent an application to <***@gnu.org> around September 2017
and it was ticketed as "gnu.org #1239092" and responded by Jason Self. [0]

Should i send a new request to webmasters email or continue from
"gnu.org #1239092" application?

[0]:https://lists.hyperbola.info/pipermail/dev/2017-September/000035.html

[bill-auger]

Post by André Silva
and it was ticketed as "gnu.org #1239092" and responded by Jason Self. [0]
Should i send a new request to webmasters email or continue from
"gnu.org #1239092" application?
[0]:https://lists.hyperbola.info/pipermail/dev/2017-September/000035.
html

yea - i would just do that - that may be the fastest way to kick things
into gear - send them another request and include that ticket number -
as the procedure says, this initial phase should be very brief - all
they really need to do is verify that the distro exists and that you
are an authorized representative of the project - i would expect that
would take no more than a few days in any case - but this case is about
the easiest they would ever see - some people on this list have already
used hyperbola - along with the fact that your email address end in
@hyperbola - there should be very little for GNU to do in this case,
other than turn around and give the official "go ahead"

[André Silva]

Post by bill-auger

Post by André Silva
and it was ticketed as "gnu.org #1239092" and responded by Jason Self. [0]
Should i send a new request to webmasters email or continue from
"gnu.org #1239092" application?
[0]:https://lists.hyperbola.info/pipermail/dev/2017-September/000035.
html

yea - i would just do that - that may be the fastest way to kick things
into gear - send them another request and include that ticket number -
as the procedure says, this initial phase should be very brief - all
they really need to do is verify that the distro exists and that you
are an authorized representative of the project - i would expect that
would take no more than a few days in any case - but this case is about
the easiest they would ever see - some people on this list have already
used hyperbola - along with the fact that your email address end in
@hyperbola - there should be very little for GNU to do in this case,
other than turn around and give the official "go ahead"

Ok, thanks for you explanation, then i will do that and send a CC to
here to you follow it too.

[Jason Self]

Post by bill-auger
which leads me back to my last question to this list from yesterday -
namely: "should a distro be grandfathered in all perpetuity once
endorsed with no further scrutiny of their on-going practices?"

I don't think that this is intended.

One of the FSF's high priority projects is "Help GNU/Linux
distributions be committed to freedom."

In that entry on the high priority list one of the things that they
mention is to explore the list of free GNU/Linux distributions, and
contribute to them. Surely "contributions" could include checking them
for FSDG compliance, right?

And, their page about volunteering suggests people "volunteer as a
"Freedom Verifier" to check whether a given distribution contains only
free software, so it can be included on the list of free
distributions." Surely that's not just new ones to add right?

Anyway, a lack of reviewing currently-endorsed distros is probably
more due to a lack of people power than anything else. After all, look
at how hard it's been to handle the backlog.

Post by bill-auger
the proper thing to do in such cases is to report a freedom bug to
the distro - but what if they ignore it?[1]

One of the criteria is the FSDG is that the people behind the distro
be committed to correcting mistakes. If they ignore freedom bugs then
that does not seem very committed to me.

There has been precedent to remove distros over freedom problems.
Anyone remember Kongoni? Search for it in
http://web.cvs.savannah.gnu.org/viewvc/www/www/distros/free-distros.html?view=log

But, the FSF can't do anything if they don't know about it right? I
think that this is probably at least one of the reasons for the GNU
Bucks program: To both encourage people to check for stuff and also
give the FSF a chance to monitor things.

And, giving people GNU Bucks as an encouragement to look at things
circles back to my earlier point that I don't think the intention is
to ignore distros once they're added.

https://www.gnu.org/help/gnu-bucks.en.html