Re: [GNU-linux-libre] emulators and other hosts of foreign applications

[Ivan Zaigralin]

I accidentally replied to RMS only, so this is a slightly edited version 
of my original post.



On 7/12/23 19:03, Richard Stallman wrote:
>> Moreover, I would suggest that FSF should not be in the business of
>> advising people at large not to use nonfree software, and to my very
>> limited understanding, it does not have such a mission.
>> That is part of the FSF's mission and the FSF does it frequently.

Thanks for clarifying that.

> Using nonfree software by yourself is not unethical, but it is bad for
> you in practical ways and moral ways.  A nonfree program is always an
> injustice.  Our mission includes leading people away from that and not
> towards it.

Playing a legacy nonfree game via a free emulator for fun is not bad for 
the user in either practical or moral ways, because there is no 
detectable harm to the user or anyone else. And if no one is harmed, 
then suggesting to others that they have this option is not unethical 
either. This is the core of my argument, and I did not see this 
addressed in your reply. In this specific case of ScummVM, no user is 
being deprived of any rights they would want or find useful to exercise, 
no one is being subjugated, no one is taking advantage of anyone else. 
On the contrary, ScummVM grants the users additional rights for using 
the software that was initially designed to be completely nonfree.


The mere absence of the source code does not make the software use or 
even distribution unethical. One has to look at who is using the 
software and the purpose for which the software is used, and ask what 
benefit is lost or gained when the code is free versus nonfree. In many 
cases, perhaps the vast majority of cases, the nonfree software is 
harmful for the user and therefore unethical to propagate. In rare cases 
when it is not harmful to anyone, it is perfectly ethical to even 
propagate, and certainly to archive, study, and simply enjoy, which is 
what ScummVM is for.


Perhaps FSF wants to continue to lump ScummVM together with something 
like Firefox, which leads users to install a DRM module, which is then 
used to run nonfree drive-by software from the Internet, which is 
actively harmful and takes the rights away that most users would rather 
keep, like the right to privacy. This is entirely within FSF's purview, 
but I am not convinced that's a valid moral stance. It is even less 
clear to me that FSF does any good by telling OS distributors they 
better do the same. And moreover, I am convinced that this type of 
behavior on the part of FSF is borderline bigotry. To wit:


Is FSF telling me that I am a bad person, when I tell my friend they can 
play Monkey Island via ScummVM?


--
Ivan G. Zaigralin
Mathematics Professor
Cosumnes River College

Re: [GNU-linux-libre] emulators and other hosts of foreign applications

[Ivan Zaigralin]

On 7/8/23 19:53, Richard Stallman wrote:

   > this part just went full-circle back to a few weeks ago
   > "emulators and other hosts of foreign applications"
   > https://lists.nongnu.org/archive/html/gnu-linux-libre/2023-06/msg00088.html

You're focusing on abstract classifications of programs, but that's
not what this issue is about.

This issue is not about distinguishing emulators from interpreters, or
any such classification of programs.  Because it is not about making
rules to apply to those classifications.  It is not about rigid rules
at all.

The issue here is: given a specific free program that can
(occssionally, or theoretically) be used to run some free software,
but in practice is nearly always used to run nonfree software, which
of these approaches should we choose about that program?  Which

All of these approaches are legitimate and ethical according to our
philosophy.  But each can be more or less beneficial to the cause.

1. treat it like any other free program -- pay it no special
attention.

2. Urge free distros to reject it, becsuse in practice distributing
it to users only legitimizes the nonfree programs that depend on it.

3. Tell free distros to reject it, for that same reason.

4. Tell free distros they can redistribute it provided they remove all
information about finding the nonfree programs it can run.

Right now we are thinking about the ScummVM case.  I do NOT expect we
will want to treat all such cases alike.  I expect that in thinking
about various cases, we will find reasons for treating various cases
in various ways.


I completely agree that the solution to this question will depend on a 
specific case, and I would like to express my opinion on ScummVM, and 
other similar cases.


I will state some of my assumptions first, and then try to argue from 
them, just for structure.


It is not intrinsically unethical to use nonfree software. It is, to 
contrast, unethical to develop nonfree software with the intent to 
distribute it and then to exploit the user. There are yet other 
unethical things one can do with nonfree software, but merely using it 
is not one of them. In a case of something like playing a single-player 
video game for fun, the user is not harming anyone (not even 
themselves), so I fail to see how this can be unethical. In general, in 
the absence of harmed parties, whose harm results from the use of 
nonfree software, the harm which is possible or likely precisely because 
the software is nonfree, I do not see an ethical argument against using 
the software, but may be I am missing something.


Moreover, I would suggest that FSF should not be in the business of 
advising people at large not to use nonfree software, and to my very 
limited understanding, it does not have such a mission. I just want to 
make it clear that even if it does, it should not. FSF encourages the 
use of free software, as well as advocating for its use, goals both very 
important and ethically valid in my opinion, but that is not at all the 
same as encouraging not using nonfree software. Merely using nonfree 
software is not unethical, and campaigning against that would be nothing 
but condescending, to speak politely. In specific cases where the use is 
linked to harm, FSF can and should raise its voice, of course.


Now I want to address the case of ScummVM, but pretty much everything I 
say here will be true of other emulators which are primarily or 
significantly used for emulating old games. What harm (to users) is 
there from playing old games via ScummVM, dosbox, pcsx2, or even recent 
games via yuzu and the like? Even multiplayer games? There is a very 
slight chance that malicious software will break out of the emulator and 
cause actual harm. Given the specifics of the case, no one should expect 
anything more serious than game crashes. How can an old game 
purposefully exploit an emulator that was created much later, I will 
leave for all of you to imagine. Aside from this, I struggle to identify 
any harm done to anyone, and this is where someone can perhaps meet my 
argument and show me something I missed.


On the other hand, consider all the good things these emulators do for 
their users. Perhaps most obviously, they effectively grant the user 
freedom 0 for the software they emulate, which is a gateway to obtaining 
other freedoms, even if via reverse-engineering. As a consequence, they 
also help the scientific community to study the history of software, by 
serving as an essential archival tool. I would even argue, they serve 
this purpose pretty much upon release, because the pace of software 
evolution is so great, and many commercial video game developers have 
plans to make game/console/platform obsolete by the next upgrade, even 
as they develop the current one. But even without the goodies, I think, 
no harm should imply no foul.


Therefore, in my opinion, the most appropriate course of action in the 
case of something like ScummVM is


> 1. treat it 

Re: [GNU-linux-libre] is this work-group still serving the community?

[Ivan Zaigralin]

On 10/31/21 18:03, bill-auger wrote:


rather than each distro repeating the same auditing work and
deciding for itself what "libre" means; it would be more
efficient if a collaborative team audited contentious software
for all distros, and presented the results to the FSF for the
final decision, binding upon all distros - IMHO, it would be more
respectable as well; because it demonstrates a base-line
consensus among the FSDG distros, regarding the minimal
liberation procedures

thats not to mention, that these are among the grunt-work for
any distro - its not the fun or sexy stuff that any dev perfers
to spend time on - people should be eager to pool their efforts
on these boring administrative chores


I agree, this seems like a more efficient way of doing things. I am
not sure that FSDG, as it is today, allows this to happen in an
objective manner.


i believe that most FSDG issues are purely objective questions
with clear answers and solutions, requiring no re-interpretation
of the FSDG; so any conflicting interpretation would be easily
proven erroneous

eg: which licenses?
 which files do each license apply to?
 are these two licenses compatible?

in most cases, there should be no disagreement about such
obvious properties


This would be great, though even the licenses can be vague enough that
it becomes hard to decide, even from the legal point of view, whether
they are free, or whether they are compatible, and then I don't see
why FSF's legal opinion should be taken over some other competent
legal opinion.

But this aside, FSDG has really problematic parts: problematic for the
program envisioned above.

> A free system distribution must not steer users towards obtaining any
> non-free information for practical use, or encourage them to do so. The
> system should have no repositories for non-free software and no
> specific recipes for installation of particular non-free programs. Nor
> should the distribution refer to third-party repositories that are not
> committed to only including free software; even if they only have free
> software today, that may not be true tomorrow. Programs in the system
> should not suggest installing non-free plugins, documentation, and so
> on.
>
> For instance, a free system distribution must not contain browsers
> that implement EME, the browser functionality designed to load DRM
> modules.

These are the clauses which were/are instrumental for arguments
against including things like Firefox (includes a catalog of addons,
some of which are non-free) or Debian-style kernels (load non-free
firmware blobs if those are present).

There are several tacit assumptions here which I would like to
challenge. First one is the assumption that it's the job of the
Operating System or the Distribution as a whole to determine whether
every piece of software out there is free or non-free. As distro
maintainers, we already spend resources on trying to determine whether
the software we include directly is free or non-free. And if a piece
of software we included talks to a repository or a library of any
kind, or merely mentions it, FSDG implies we are now responsible for
vetting that repo, continuously. And if that repo is itself an
aggregate of some other sources, we have to vet those sources
too. Couple it with the fact that nearly every complicated piece of
software these days will have at least one community repository of
auxiliary code, or plugins, or what have you, and now the distro
maintainers end up combing the entire software ecosystem: free and the
fringes of non-free, to figure out if any one of literally thousands
of separate free software packages can be seen as "steering" towards
non-free resources, of which there must be millions now.

I believe this assumption should be regarded as wrong, for practical
reasons, and that the responsibility sits with the user of a
free-and-libre Distribution to vet the packages they get from the
Net. From the point of view of distro maintainers, there is no practical
way of protecting a user from himself, when that user refuses to be
responsible for vetting his own software sources. Only appropriate
legislation can protect such users, and only to some extent.

** ** ** ** ** **

Another assumption FSDG makes, a stronger one, even, is that
"steering" or even "referring" a user toward non-free sources is
bad/unacceptable. I believe that forbidding such references amounts to
censorship, and is a worse outcome than just letting the user accept
the responsibility. A free distribution user may have a legitimate and
ethical interest in both using and studying non-free software for a
variety of reasons and in a number of ways. Some non-free software is
open-source, and can be effectively studied in detail. Binary blobs
can be studied with the intent of reverse-engineering them. To take
one particular example, Firefox' implementation of EME can and should
be studied in order to actually conclude that it implements 

Re: [GNU-linux-libre] [gnu.org #1712352] freenix endorsed ?

[Ivan Zaigralin]

Looks like you have many suggestions to improve our wiki. Please use our
forum, just like our wiki is asking you to do, and create a topic for
each issue you would like us to address. Discussing these issues in this
mailing list would be off-topic and a waste of everyone's time.

To answer your first question, we keep the trail of our communication
with FSF here:

https://freenix.net/forum/index.php?t=msg=7=0;

On 4/7/21 1:50 AM, Jean Louis wrote:
> Dear Ivan,
>
> Thank you. I understand "Zaigralin" like one who started playing,
> speaking some Slavic languages too. Am I right?
>
> * Ivan Zaigralin  [2021-04-07 02:54]:
>> Dear Jean Louis,
>>
>> We have been waiting for FSF to do something, anything, for years now.
>> If you want to "rush", please let them know.
> Tell me to which person did you speak to?
>
> By which communication line did you ask?
>
>>> What I don't understand is the mentioning of these packages which are
>>> non-free:
>>> https://freenix.net/dokuwiki/doku.php?id=slackware_14.0
>> These are non-free packages which we've purged from the Slackware
>> upstream in order to create Freenix. We are fully committed to
>> documenting every step of our work.
> Ivan, that what you say here is not described on that page. I would
> like to enter proposal on the page, but I cannot see how to subscribe
> on Wiki if at all possible.
>
> Again, you better communicate on the page with something like: "This
> is the list of proprietary and FSDG non-conformant packages we
> excluded from Slackware". But what you write exactly there is up to
> you. I just say, page is not communicating enough.
>
>>> What is very hard to find on that website is:
>>>
>>> - Packages, package list or search of packages, as that is starting
>>>   point to verify if there are some considered non-free or
>>>   non-compliant to FSF Free Distribution Guidelines
>> No, it's not very hard to find. The entire distribution is linked from
>> the Free Repository article:
>>
>> https://freenix.net/fxp/
> Well you say it is not hard to find. Then you offered me hyperlink
> which I could not find myself. Please understand it from users'
> viewpoint. You know it, and I am not you, I cannot find it. I do know
> how to browse websites. What I am speaking of is that at almost every
> OS distribution there are list of packages, easy to find, search,
> browse.
>
> Please see here:
> https://guix.gnu.org/
>
> You can clearly see menu item "Packages", website visitor can at any
> time locate it and search for packages. I do not speak of FSDF rather
> of habits. OS users do have need to see at list a list of packages
> like a single file, that is referenced from pages which user is
> visiting. Putting it in a menu item is very good for website and for
> distribution.
>
>> https://freenix.net/fxp/freeslack64-14.2/
> Let me say, it is confusing. Is it Freenix or Freeslack? I do not
> know. I do not know what is Freeslack -- learn from this statement, as
> your website is Freenix and not Freeslack. To me it is confusing.
>
> Why would I search for list of packages in Freenix OS inside of a
> Freeslack OS? That is viewpoint and my impression at this time. You
> maybe equal those, me not, name is different, and there is no visible
> proper justification for it, not on the first page. I found it later,
> but you should consider harmonizing the name into one, not having two
> of them. You can introduce HTTP redirects server-side to move to new
> name.  
>
> In this URL I find only 20 packages listed:
> https://freenix.net/fxp/freeslack64-14.2/PACKAGES.TXT
>
> ⇛ So do you see now that I cannot find full list of packages?
>
> Let me say that making a search for a package is very easy, I did it
> years ago with simple grep and awk.
>
> You can serialize information about one package into one single line,
> just replace \n with space and remove redundant words such as "or"
> "and" "the" "a" or similar. This allows for grep-ing the package. Once
> greped, awk can extract the name of the package from specific field or
> maybe URL as other field and construct HTML listing.
>
> Or if packages have their URLs you can just run it through Markdown 
> and make single HTML that is searchable by using browser functions. Or
> Pandoc, and construct Wiki pages.
>
>>> - Issues -- I have seen it, but I missed it, it is very hard to find
>>>   issues. That is one of requirements.
>> In Participation article of the wiki, there are clear instructions for
>> reporting issues.
> That does not make it easy. Do you see that me

Re: [GNU-linux-libre] [gnu.org #1132171] [distro review] Freenix: In search of FSF certification

[Ivan Zaigralin]

On Thursday, August 22, 2019 17:41:10 Donald R Robertson III via RT wrote:
> On Tue Aug 13 17:15:42 2019, melik...@melikamp.com wrote:
> > Internally, we've reached similar conclusions, and going forward, we
> > will
> > simply duplicate relevant pieces of documentation whenever we want to
> > publicize them among our users, rather than linking to third-party
> > Slackware-
> > related resources. At this moment, we don't have any such problematic
> > links
> > from our web wiki, and we will treat them as freedom bugs. Please let
> > us know
> > of any new developments :)
> 
> Great, I'm glad that wasn't too burdensome in the end. I took another pass
> and things are mostly looking good but just a few quick fixes.
> 
> * On  and
>  there seems to be
> recommendations of distros that are not on the FSF endorsed list. Some of
> them, like ConnochaetOS and Uruk are interested in gaining endorsement and
> hopefully will gain it. But until then we shouldn't be recommending distros
> to people that haven't passed the criteria yet, and could potentially
> contain nonfree software or other issues.

We no longer mention ConnochaetOS in the wiki, as they seem to be winding down 
all activity anyway.

The public forum is where random people are saying things. That particular 
thread had a super-misleading subject line, and I just fixed it.

> * It wasn't immediately apparent where users should direct reports of
> freedom issues. It would be good to put that information on the
> participation page
> .

The participation page now starts with Report Issues section. I can't believe 
it wasn't there before, this was a really great suggestion.

Please let us know of any developments on your side :)


signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] [gnu.org #1132171] [distro review] Freenix: In search of FSF certification

[Ivan Zaigralin]

On Thursday, August 22, 2019 17:41:10 Donald R Robertson III via RT wrote:
> Great, I'm glad that wasn't too burdensome in the end. I took another pass
> and things are mostly looking good but just a few quick fixes.
> 
> * On  and

This is just random people saying things in our forum. If you look at my post 
(as connie), we are currently not endorsing any distros, but looking into 
possibly doing so in the future.

>  there seems to be
> recommendations of distros that are not on the FSF endorsed list. Some of
> them, like ConnochaetOS and Uruk are interested in gaining endorsement and
> hopefully will gain it. But until then we shouldn't be recommending distros
> to people that haven't passed the criteria yet, and could potentially
> contain nonfree software or other issues.

ConnOS is EOL as far as I know, so we will remove this link from wiki anyhow.

> * It wasn't immediately apparent where users should direct reports of
> freedom issues. It would be good to put that information on the
> participation page
> .

This will be easy to fix. I will shout out again when we push these changes :)

> I know I said previously that we shouldn't need the mailing list to review
> things again, but that wasn't quite accurate. The final step in the process
> is that we give the mailing list one last "Speak now or forever hold your
> peace" chance right before we announce endorsement. This isn't really meant
> as a review, it's more of a heads up so they know that endorsement is about
> to be announced.
> 
> So once we get the above two items squared away, I'll ask RMS for approval,
> then we'll get the ball rolling on working on the announcement.
> 
> Thank you so much for your patience and care throughout this process, and
> let me know if you have any questions.
> 
> 
> --
> Sincerely,
> 
> Donald R. Robertson, III, J.D.
> Licensing & Compliance Manager
> Free Software Foundation
> 51 Franklin Street, Fifth Floor
> Boston, MA 02110, USA
> Phone +1-617-542-5942
> Fax +1-617-542-2652 ex. 56
> 
> ---

signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] reply FSF

[Ivan Zaigralin]

I really don't think we should discuss any more hypothetical scenarios in this 
thread. I would agree with you that Freenix forum is a more appropriate place 
to discuss how we present documentation and how that affects our users' 
freedom.

The real question here is, the way I see it: why does

https://libreplanet.org/wiki/Incoming_distros#Distros_ready_for_final_review_by_the_FSF

say that Freenix "passed community evaluation for all FSDG criteria and [is] 
awaiting final review by the FSF licensing team" on one hand, and on the other 
hand "Ineiev via RT"  just informed at least one curious 
user that there is an unresolved FSDG-related issue, raised in a community 
forum, and then directed the user to a post which does not raise any such 
issue, according to the post's author?

At the very least, we here at Freenix would like to know which of these 
seemingly contradictory scenarios is actually taking place.

On Friday, June 21, 2019 17:41:59 bill-auger wrote:
> i suppose the question is whether there is indeed an issue that
> is unresolved
> 
> * are there links on the freenix website that lead users to the
>   slackware website?
> 
> * if yes, does the slackware website contain
>   recommendations or instructions for using non-free software?
> 
> * if yes, is that a FSDG problem?
> 
> i dont know the answer to any of those questions myself; but if
> this were still up for community discussion, i would note that
> when parabola was created, it had the similar stated goal to
> stay as close to arch as possible
> 
> the original parabola devs took the time to copy the most
> important documentation from the arch wiki onto the parabola
> wiki, some edited for FSDG-compliance, some not edited -
> presumably that was in order to avoid directing users to the arch
> wiki for any reason, because the arch wiki contains instructions
> and recommendation for using non-free software
> 
> i am not certain if that was strictly required for them to do so
> though - perhaps there is a subtle issue to clarify on this list
> - namely, whether the documentation must avoid external links
> that lead websites that are known to contain recommendations,
> that could be construed as indirect recommendations - perhaps
> there already is a consensus on that concern - i am not sure
> 
> if that is a DSFG problem, the simple solution would be to remove
> any links to slackware documentation - even if that leaves the
> freenix documentation incomplete, complete documentation is not a
> criteria for endorsement

signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] reply FSF

[Ivan Zaigralin]

What you are saying below was also my understanding, Bill, up to very 
recently, because this email from Childebert  , who 
inquired about our status from FSF just a few days ago, seems to offer a 
contradictory assertion:

> Subject: reply FSF
> Date: Thursday, June 20, 2019, 18:36:31
> From: Childebert 
> To: Ivan Zaigralin 
> CC: Matt Samudio 
> 
> Le Thu, 20 Jun 2019 08:21:01 -0700,
> Ivan Zaigralin  a écrit :
> 
> I received the message from the FSF he say this :"With Freenix, a year
> ago an issue was raised on gnu-linux-libre@ that remained unresolved
> there,
> 
> https://lists.nongnu.org/archive/html/gnu-linux-libre/2018-07/msg00023.html

Perhaps this is all a result of miscommunication, but either way, FSF's 
official position in this process is one of the things I am trying to 
understand right now.

On Friday, June 21, 2019 17:03:58 bill-auger wrote:
> On Fri, 21 Jun 2019 13:08:44 -0700 Ivan wrote:
> > Once again, please let us know if there's anything there you
> > see that is in violation of FSDG.
> 
> i think this distro is entirely in the FSF's hands now - shortly
> after the new evaluation procedure was put into place, donald
> immediately moved freenix and libretybsd out of the section:
> "Distros that have requested consideration", and into the
> section: "Distros ready for final review by the FSF", bypassing
> the section: "Distros currently being evaluated by the community"
> 
> https://libreplanet.org/wiki?title=Incoming_distros=revision=48277
> =48254
> 
> as i remember that was because those two distros were considered
> to be already fully evaluated by the community, and would not
> need to go through the new review checklist process; but would
> be immediately eligible for consideration by the FSF
> 
> at this point, if someone from the community found an issue with
> freenix, probably the freenix bug tracker would be the most
> appropriate place to report it - there is probably nothing more
> to discuss on this list, unless it turns out to be some unclear
> edge case that requires discussion, clarification, or consensus
> in order to determine of it is a FSDG problem

signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] reply FSF

[Ivan Zaigralin]

On Friday, June 21, 2019 18:46:17 Ineiev wrote:
> On Thu, Jun 20, 2019 at 06:00:32PM -0400, bill-auger wrote:
> > i dont remember exactly, but it appears to be in response to
> > someones concern that the freenix documentation is incomplete,
> > which is not a problem on its own; but that, more importantly, it
> > directs users to the slackware documentation to provide its
> > missing information
> 
> Quite right,
> https://lists.nongnu.org/archive/html/gnu-linux-libre/2018-07/msg00016.html
> says,
> 
> > It makes zero sense to duplicate the documentation, since our
> > project is dead set on keeping the technical details identical
> > to Slackware as much as possible, allowing us not to fork
> > support.
> 
> I believe this results in a doubt that should be resolved:
> if Freenix doesn't "fork support", does it mean that it
> effectively directs its users to Slackware?

Before I address these concerns, please let me share with you my emotional 
state. I am getting rather frustrated with this conversation, although I am 
definitely not blaming anyone in particular for that, except for possibly 
myself. The thing is, Freenix has committed to compliance with FSDG prior to 
2017. We have received a number of relevant bug reports since then, and we 
took care of each and every one of them. To mention just some, we changed the 
project name and removed offending packages, like some fonts and some Mozilla 
products.

Bill says rather explicitly, he has no bugs to report, he's just musing. FSF 
has not told us the official FSF position concerning these hypothetical 
scenarios either. Our entire documentation at freenix.net can be skimmed in 
minutes; if there's an FSDG-related bug there, having to do with either the 
links or the quantity of documentation, it hasn't been reported in years. Do 
you perhaps see now where we are coming from? We are not aware of anything 
afoul of FSDG within our project as of right now, and one of our primary goals 
is to take freedom bug reports with full seriousness. We are at a loss as to 
what else we need to do at this point of the FSF approval process in order to 
move it along, so some clarification would be very welcome.

Now, to address the issues raised in Bill's original post:
https://lists.nongnu.org/archive/html/gnu-linux-libre/2018-07/msg00023.html

To the best of my understanding, the issues there have to do with 
documentation and/or linking to Slackware documentation. The entirety   of 
Freenix documentation is currently in one place: freenix.net. There's wiki 
there, a forum, and the source code for the deployment script. If 
quality/quantity of documentation is a concern for this certification process, 
it's there for anyone to see and judge.

There are a few Web links, as of now, from our wiki to Slackware-related 
resources. None of them are with the intent to provide documentation to 
Freenix end users. They are all credit and/or reference links, practically 
unavoidable simply because we believe it is our duty to explain to our users 
and the potential contributors just what we do to the upstream Slackware 
distribution to make it into a freedom-respecting product.

Once again, please let us know if there's anything there you see that is in 
violation of FSDG. 


signature.asc
Description: This is a digitally signed message part.

[GNU-linux-libre] Fwd: reply FSF

[Ivan Zaigralin]

Hi Bill,

FSF seems to be under the impression that the linked post of yours raised an 
issue that was never resolved. As I told FSF before, I don't understand what 
they want us to do, because I don't understand what issue was raised. Freenix 
has no outstanding bug reports concerning freedom or FSDG.

Can you please clarify for us in what way, if any, the current state of 
Freenix is in violation of FSDG, so that we can start working on concrete 
mitigation measures.

--  Forwarded Message  --

Subject: reply FSF
Date: Thursday, June 20, 2019, 18:36:31
From: Childebert 
To: Ivan Zaigralin 
CC: Matt Samudio 

Le Thu, 20 Jun 2019 08:21:01 -0700,
Ivan Zaigralin  a écrit :

I received the message from the FSF he say this :"With Freenix, a year
ago an issue was raised on gnu-linux-libre@ that remained unresolved
there,

https://lists.nongnu.org/archive/html/gnu-linux-libre/2018-07/msg00023.html


signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] FreeSlack -> Freenix transition is done, awaiting review

[Ivan Zaigralin]

Bah, links got mangled somehow.

Our wiki, which is the main source of documentation:
https://freenix.net/dokuwiki/doku.php?id=start

And our forum: https://freenix.net/forum/


signature.asc
Description: This is a digitally signed message part.

[GNU-linux-libre] FreeSlack -> Freenix transition is done, awaiting review

[Ivan Zaigralin]

Hi everyone!

We publicized the distribution/project name change from FreeSlack to Freenix, 
and our
websites are all  Freenixy now. Some notes to reviewers:

Things like names of files are left alone for the current stable (14.2) but 
will be thoroughly
rebranded wherever appropriate in the next stable release.

A lilo screen with branding supplied via Wiki is still old style, but it is not 
supplied during the
installation anyway, requiring 100% manual install, and will be updated for the 
next release as
well.

There are a couple of links from our wiki to Slackware documentation, like this 
place for
example:

http://docs.slackware.com/slackware:beginners_guide#switch_to_a_generic_kernel

It makes zero sense to duplicate the documentation, since our project is dead 
set on
keeping the technical details identical to Slackware as much as possible, 
allowing us not to
fork support. We don't see a problem with this,
but if the consensus is that it may be confusing, we can publish a disclaimer 
about no
affiliation, and how users should be wary of the possibility that non-free 
software is mentioned
there (we are not aware of such an instance, but we have no control over that 
wiki).

Our wiki, which is the main source of documentation:
https://freenix.net/dokuwiki/doku.php?id=start[1]

And our forum: https://freenix.net/forum/[2]

Please let us know if you see anything else that requires our attention.

On Friday, March 23, 2018 15:29:11 you wrote:
> On Thu Mar 22 14:47:00 2018, melik...@melikamp.com[3] wrote:
> > Sounds fantastic. Freenix is our first choice. To sweeten the deal, we
> > are
> > fully prepared to move the distro front to freenix.net, already nabbed
> > by
> > Matt. This might potentially take a long time, but is definitely
> > something we
> > would like to do.
>
> Excellent, I got the all clear from RMS for the name Freenix along with the
> moving to freenix.net. While you make the switch, I'll take one last pass
> just to make sure there are no other issues, which I don't expect to find,
> and then we can talk about coordinating the announcement. Thanks again for
> being understanding; I'm trying to make this process better and you working
> together with me on it is very helpful.
>
> --
> Sincerely,
>
> Donald R. Robertson, III, J.D.
> Licensing & Compliance Manager
> Free Software Foundation
> 51 Franklin Street, Fifth Floor
> Boston, MA 02110, USA
> Phone +1-617-542-5942
> Fax +1-617-542-2652 ex. 56



[1] https://freenix.net/dokuwiki/doku.php?id=start
[2] https://freenix.net/forum/
[3] mailto:melik...@melikamp.com


signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] Freeslack website

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

On Friday, March 23, 2018 13:23:21 KRT Listmaster wrote:
> 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...
> 
> On 03/23/2018 11:51 AM, Ivan Zaigralin wrote:
> > 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.
> 
> 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
> 
> --
> This email account is used for list management only.
> https://strangetimes.observer/

signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] Freeslack website

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

On Friday, March 23, 2018 10:51:01 Ivan Zaigralin wrote:
> 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.
> 
> On Friday, March 23, 2018 13:36:59 bill-auger wrote:
> > 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

signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] Freeslack website

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

On Friday, March 23, 2018 13:36:59 bill-auger wrote:
> 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

signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] Freeslack website

[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

down below in Kudos section it says:

> 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 
project and Bob personally), something along the lines of:

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

On Friday, March 23, 2018 09:12:54 Henry Jensen wrote:
> 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
> 
> schrieb Ivan Zaigralin <melik...@melikamp.com>:
> > A pretty good and very current summary of FreeSlack review process
> > can be found here:
> > 
> > https://www.freeslack.net/forum/index.php?t=msg=7=15

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

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

On Thursday, March 22, 2018 16:08:47 bill-auger wrote:
> On 03/22/2018 03:30 PM, Donald Robertson wrote:
> > 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.

signature.asc
Description: This is a digitally signed message part.

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

[Ivan Zaigralin]

On Wednesday, March 21, 2018 19:47:37 Jason Self wrote:
> bill-auger  wrote ..
> 
> > BTW - the actual OP for free-slack is here:
> 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=7=15

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

[Ivan Zaigralin]

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

Re: [GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)

[Ivan Zaigralin]

To clarify, I agree with you and Luke down below that www subdomain is nice 
and useful. It's only the tacit assumption that www.whatever.com = 
whatever.com that I find annoying :)

On Wednesday, January 24, 2018 21:38:29 bill-auger wrote:
> 'www.' is indeed just a convention but it is not a "traditional" thing
> of the past that should go away - it's meaning is still as well defined
> and useful today as it ever was - sub-domains are very plainly a way to
> distinguish one machine or service from the various other services that
> may be offered under the base domain anme (which is often not associated
> with any server), and to allow each machine or service to have a it's
> own IP address (perhaps at different physical locations), while
> remaining semantically associated under the umbrella of the main domain name
> 
> in the case of the 'www.' sub-domain in 'http://www.foo.com', that
> clearly identifies the HTTP "World Wide Web" server of foo.com - as
> distinguished from it's FTP server ftp.foo.com, it's mail server
> smtp.foo.com, it's usenet server news.foo.com, and so on - some domains
> have only a web server and so there is no confusion if there is a 'www.'
> sub-domain or not; but to assume that as the default case is to assume
> that every client that asks for 'foo.com' should always get a World Wide
> Web server, which is to ignore the plethora of other services that can
> be offered under the same domain as well the possibility that foo.com
> may have no web server at all

signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)

[Ivan Zaigralin]

This is my understanding as well. In a way, www subdomain is a total nuisance. 
It is entirely traditional, but now every web user expects a redirect, 
consciously or not, so that they can use example.com in lieu of 
www.example.com, and still end up in the same place. But this doesn't "just 
happen" on the DNS level; this is an explicit entry/redirect, and it always 
has to be set up (although many web hosting providers will typically do it for 
their clients). You can google (yes, this puppy is ready for genericide) for 
"www domain redirect" to see countless reports of neophyte webmasters seeing 
the problem for the first time and asking WTF.

For example, these are different:

http://ntp.org/
http://www.ntp.org/

This is the generic behavior: www.ntp.org is a different domain name, and it 
may well be bound to some other IP address in the DNS, or even be undefined.

So in conclusion I would recommend citing URLs provided by the respective 
distribution maintainers. Appending or removing "www." without their explicit 
approval is simply wrong, and coercing maintainers to register and redirect a 
www subdomain would be even more uncalled for.

On Wednesday, January 24, 2018 17:25:43 Julie Marchant wrote:
> I get the impression that the whole trend of using the "www" subdomain
> came from Usenet hierarchies. Is that accurate?
> 
> In any case, many websites these days don't do that anymore, and even
> when they did it was never necessary. So yeah, it's inaccurate to say
> that websites' URLs *should* have that prefix. Just optional fluff some
> people like to use.
> 
> --
> Julie Marchant
> https://onpon4.github.io
> 
> Protect your emails with GnuPG:
> https://emailselfdefense.fsf.org

signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Ivan Zaigralin]

On Monday, August 07, 2017 00:10:39 Henry Jensen wrote:
> Am Sun, 06 Aug 2017 14:27:01 -0700 (PDT)
> > But if your decision is to continue to push back on this and leave the
> > request_firmware calls in place and unmodified, then I think my review
> > of ConnochaetOS is over.
> 
> That is, of course, for you to decide. However, I didn't found any
> official statement (meaning a statement at fsf.org or gnu.org), that
> writing names of proprietary firmware files in a log file are rendering
> a distro not recommendable or a software as not usable in a fully free
> distro. Some random messages on this list are not official
> statements.

Well said. I think, if ConnOS makes the leap towards official FSDG 
certification, it will be worthwhile to explain the difference between Debian 
kernel packages and the ConnOS kernel package.

Just because the kernel is capable of loading a firmware file which bears the 
symbolic name of an extant nonfree firmware blob, it's hard to see how FSDG is 
violated. The problem with Debian is that their "free" installer will 
literally prompt for a USB with nonfree drivers at installation time if one of 
these turd-chips is detected. From what I learned about ConnOS, its kernel 
package does no such thing. In the absence of the (nonfree) firmware file it 
simply moves on with a terse message in the log, stating that file was not 
found.

I personally think the difference is huge, even though the kernel is deblobbed 
in a similar way. If my understanding is correct, then I don't see how one can 
argue that ConnOS guides users toward nonfree firmware.

I was also amused to find out that Linux-libre decided to ignore RMS' 
suggestion and blacklist the blobs rather than obfuscate the calls :) It 
certainly helps to explain ConnOS' stance on why the Libre-linux approach is 
not that great either. I personally think that either approach is perfectly 
sufficient, and neither is heavy-handed, but I can also totally appreciate 
when a maintainer opts towards the Debian way for technical reasons. 

And here's another thought, besides the point raised above, but still 
pertinent: who in a 1000 years would use ConnOS and its deblobbed kernel in 
conjunction with nonfree firmware? Crazy people? ConnOS is the poor robot's 
Slackware, no offense meant. It is a fact of life that Slackware to this day 
has no close-source components besides the kernel, so anyone dropping a 
nonfree kernel into ConnOS (or FXP/Freenix, same deal) is not thinking 
straight: they are essentially getting the stock Slackware back, after jumping 
through a series of flaming hoops. Sure, there are things like xv and xgames 
and fractint in Slackware, but they and all the other nonfree packages are 
museum pieces at this point in history. When it comes to users' freedom, they 
make virtually no difference in practical terms. OK, so there's also mozilla, 
but again, free-e-fied ice* packages are available from various binary repos, 
so the objections about the way the kernel is deblobbed are missing the point.

signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] Reviewing ConnochaetOS

[Ivan Zaigralin]

On Sunday, August 06, 2017 09:37:16 Jason Self wrote:
> Henry Jensen  wrote ..
> 
> > The link to the freeslack project shouldn't be a problem, since
> > the page at https://www.gnu.org/distros/common-distros.html links
> > to the very same project.
> 
> There is no reference to FreeSlack on that page, only Slackware.

You do not consider a web link a reference? Both the cited FSF page and the 
FSFLA Linux-libre page link to the FreeSlack project.

> But even if we consider Slackware, what is being said also be
> considered: That page is discussing why Slackware is not acceptable
> for adding as an FSF-endorsed distro.
> 
> In comparison, the text I'm referring to is an out-and-out referral to
> go *use* it if someone wants a 64-bit version: "If you are looking for
> a libre Slackware x86_64 variant you are welcome to use the x86_64
> slack-n-free repo and have a look at the FreeSlack project."

Please do not confuse FreeSlack with Slackware, the names are not THAT 
similar, and if you read the statement on the front wiki page, you will see 
FreeSlack is a documentation project which is NOT affiliated with Slackware 
project, and its distribution arm is free software. The distribution name may 
be A BIT confusing, which is why we are in the process of changing it to FXP 
or Freenix or something else, which is up to FSF at this point. We applied for 
FSDG certification in March 2016, and so far we haven't heard any suggestions 
from the FSF review team besides changing the name collision, which we agreed 
to do. Since then several months have passed, and we have not heard any 
comment about either "FXP" or "Freenix", leaving us in a kind of a nameless 
limbo. So at present, we think, we have zero outstanding issues with respect 
to FSDG.

> I imagine that FSF-endorsed distros should probably not steer people
> to others that are not?

That would be a gross misrepresentation of the FSDG guidelines. Free 
distributions should not stir people towards non-free software, period. ConnOS 
is free software, which is why here at FreeSlack we think it's OK to mention 
them as an option for x32 arch. The FreeSlack's distribution, FXP, is also 
free software, Linux-libre-powered and without the Debian kernel controversy, 
so of course there are no issues about ConnOS linking to FreeSlack either. 
None of that has any bearing on FSDG compliance.

I would agree that IF a Debian-style kernel SUGGESTS and STIRS users towards 
firmaware blobs, then the kernel should fail the FSDG. I am not in the 
position to comment on the specific kernel used in ConnOS, since I never 
studied that portion.

I am also personally of the opinion that it's OK for an FSDG-compliant 
distribution to suggest an option which is free, although not necessarily 
FSDG-compliant. There's nothing wrong, IMHO, about informing users about 
Debian-style free kernels as viable options as long as the users are warned 
about the blobs. I know not everyone will agree, since this is kind of a gray 
area, but I think you can all understand my reasoning: at some point the user 
should admit some responsibility.

Like RMS said, of course free software will allow you to install and run 
nonfree software, there's no cure for that, and it's not even a tragedy of any 
sort. But we don't declare web browsers nonfree, even though most of the big 
ones, like konqueror, are designed to drop the user into the javascript trap 
by default. We just admit that users should know better than to enable 
javascript on pages they don't trust to serve 100% free software.

There's only so much hand-holding we can do as distro-maintainers, and 
preventing user from exploring viable 100% free-software options such as the 
libre channel of the Debian repository is simply not our job. There's no 
contradiction here, as far as I can see: FSF should not endorse Debian-style 
shenanigans if it doesn't want to, but FSF has no business telling other 
projects, even the one they endorse, to stop mentioning free software 
compilations which themselves fell short of FSDG.







signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] youtube-dl might be running non-free software from

[Ivan Zaigralin]

Sorry, I meant to say I do NOT speak for FSF in this post :)

On Tuesday, July 18, 2017 16:43:46 you wrote:
> I do speak for FSF here, though I am a member.


signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] youtube-dl might be running non-free software from

[Ivan Zaigralin]

I do speak for FSF here, though I am a member.

On Tuesday, July 18, 2017 11:06:18 Adonay Felipe Nogueira wrote:
> 1. Considering the current GNU FSDG: What free/libre system distributions
>should do when they face the JavaScript trap in case some of the
>packages they have depend on non-free JavaScript?

Of note is the fact that youtube-dl does not *depend* on any non-free 
javascript. Don't point it to any place wich serves nonfree javascript, and it 
won't run it. Just like konqueror or icecat or any other free browser/app 
which supports any kind of subset of javascript.

> 2. 

> 3. As a suggestion for the Free Software Foundation's Licensing and
>Compliance Lab: Could the GNU FSDG have a text clarifying what must
>be done in questions #1 and #2?

No one knows, the best I can tell. It's called javascript "trap" for a reason, 
and the reason is we are in it, and we can't seem to get out. Please allow me 
to elaborate.

There is a wide class of apps, let's call them "drive-by interpreters". These 
are apps built on top of the internet/web stack, which are also capable of 
interpreting some kind of language. What these apps do is they load web pages 
(or net resources in general), extract code from them, and execute that code 
instantly. Some drive-by interpreters *force* users to use network 
resources which are *known* to serve non-free code. Let's agree for now these 
stinkers fail FSDG, even if free themselves. However, some of the most popular 
drive-by interpreters are pointedly agnostic, and will require the user to 
specify the network resource. Nothing in these apps will require the execution 
of nonfree code, unless the user will elect to visit and process a resource 
with nonfree code. These include most free web browsers, and, as much as 
I understand, also youtube-dl. I will talk about these agnostic, user-
controlled apps only.

Javascript trap is just a famous example of a more general trap where we find 
ourselves today. A user who is intent on NOT running nonfree software simply 
cannot afford to use a drive-by interpreter all by itself. By firing up a 
drive-by interpreter the user instantly assumes full responsibility for the 
resources passed on to it. The interpreter app, in particular, has exactly one 
practical way of deciding whether a given resource is free: it can check the 
crypto whitelist: for example, verify that the resource is signed by a party 
such as FSF, trusted to supply only free software. What LibreJS does, for 
example (checking for the presence of an attached license) is naive to the 
extreme. A resource can lie. The served code can be obfuscated. The code could 
be undocumented spaghetti code. The code could be generated on the fly, 
different every time, by a nonfree and secret server-side daemon. None of that 
would be free software even when a correct license is attached, and none of it 
would be detected by a boiler-plate checker such as LibreJS. As an icing on 
the cake, the code could be in fact free, yet *malicious*, because it has not 
been audited. And how can one even hope to audit code which comes as a part of 
a web page, and may change literally every second?

1. And hence the correct and practical way to escape the JS trap is to stop 
using JS, or at least stop using JS the way it is used. A user unwilling to 
run nonfree JS software must use a whitelist of resources she trusts, period. 
It is not the responsibility of a drive-by interpreter to supply that 
whitelist, since different users will want to trust different parties, and may 
even have different opinions on whether a given piece of software is free. The 
only responsibilities a drive-by interpreter has to the user is to work with 
*any* and *all* technically valid resources suggested by the user, and to 
avoid *forcing* the user to run code which is reasonably well known to be 
nonfree.

2. This situation could be mitigated somewhat, maybe, if we get legislation 
which forces all public-facing web content to be explicitly free. But even 
then, I would argue, we will still be sitting in the security portion of the 
trap.

3. The situation could be mitigated more fully if we get legislation which 
forces all public-facing web content to be *free* *markup*, and some of the 
interactivity and flexibility of a dynamic web page can be salvaged by 
creating a "local javascript": a free and secure API package installed 
locally, which will be called on by the markup. So like if you want to present 
a web form that does some syntax checking, you as a web developer fill out an 
even bigger form, which is then passed to the free API, which then generates 
on the fly the free code to display the user-facing form.

As you can see, the practical solutions are 1. non-starter 2. non-starter and 
3. yeah, right... non-starter, hence we call it the javascript trap.

Concerning youtube-dl, thanks to everyone who looked at the code, both 
youtube-dl and the code it pulls from the web. It 

Re: [GNU-linux-libre] youtube-dl might be running non-free software from webpages

[Ivan Zaigralin]

It is not the primary function of youtube-dl to run specific non-free code off 
the web. The primary function of youtube-dl is to download videos onto the 
local host. It may well be that in order to acheve this goal youtube-dl 
downloads and executes mystery javascript, possibly non-free.

Compare this with konqueror. One of konqueror's primary functions is to 
display web pages. In doing so konqueror downloads and executes mystery 
javascript, possibly non-free. And yet no one is suggesting that konqueror 
fails FSDG. If the user is averse to non-free software, then It is clearly the 
responsibility of the user to make sure that whatever page they are looking at 
only supplies free software. In fact, konqueror cannot reliably determine 
which software is free (and neither can LibreJS, by the way, since it simply 
takes the script's self-identification as the final word, nevermid that 
scripts can trivially lie).

I am not saying youtube-dl is perfect or cannot be improved with respect to 
how it deals with potentially non-free javascript. All I am saying is, 
youtube-dl is clearly a general-purpose web downloader, so its users 
automatically assume responsibility for whatever is being downloaded, and how 
it's being downloaded. There's absolutely nothing wrong with youtube-dl being 
able to process a web site which serves non-free javascript.

For what it's worth, I'd like to say a few words about LibreJS as well. I 
don't want to make a comparison between noscript and LibreJS, since they have 
very different functions, but I really think that adopting LibreJS approach to 
youtube-dl would be another massive blunder. Neither free nor non-free 
software is detectable by a simplistic algorithm, so this approach would be 
highly ineffective, just as it is right now within icecat.

On Wednesday, April 19, 2017 11:55:23 Adonay Felipe Nogueira wrote:
> To clarify: I'm a LibreJS proponent, not a NoScript proponent.
> 
> This issue seems to affect at least: Trisquel, Guix (and GuixSD),
> Parabola.
> 
> Backstory paragraph: Earlier on the trisquel-users mailing list, people
> questioned how to watch YouTube videos with free/libre software, and so
> I jumped in suggesting them that, while this is possible, society should
> publish videos in places that use, for example, GNU MediaGoblin and
> GNUnet. Some people asked about Vimeo and Internet Archive. However, I
> told them that these hold the exact same problems against the *average
> site visitor* (i.e.: non-free video formats being provided by default,
> non-free JS being forced by default). By "average" I mean those who
> don't have JS disabled and those which have no non-free JS blocker.
> 
> Sometime later, the discussion changed slightly after reports from some
> people saying that youtube-dl can run arbitrary code through
> [[https://listas.trisquel.info/pipermail/trisquel-users/2017-April/076773.ht
> ml]["jsinterp.py" JavaScript interpreter script]].
> 
> At first,
> [[https://listas.trisquel.info/pipermail/trisquel-users/2017-April/076787.ht
> ml][evaluators thought that the capability of such script to be limited]],
> however,
> [[https://listas.trisquel.info/pipermail/trisquel-users/2017-April/076820.h
> tml][lcerf argues]] that this script has things that make it
> Turing-complete, and argues that, with this, the problem is not the
> interpreter script
> itself, but the code that it interpretes. lcerf also questions if this
> interpreter script is taking arbitrary code from the web.
> 
> [[https://listas.trisquel.info/pipermail/trisquel-users/2017-April/076844.ht
> ml][Other user answered]] lcerf's question saying that it might be, because
> it's set-up to do so --- but he doesn't know if this is the actual case.
> And also says that the module containing the JavaScript interpreter is
> imported by another script at "extractor/youtube.py", and the same user
> points to parts of the code that make use of such JavaScript
> interpreter.
> 
> Later on,
> [[https://listas.trisquel.info/pipermail/trisquel-users/2017-April/076931.ht
> ml][people summarized what is hapenning and where to go from here]],
> [[https://listas.trisquel.info/pipermail/trisquel-users/2017-April/076935.ht
> ml][lcerf took a look at ViewTube GreaseMonkey userscript]], and
> [[https://listas.trisquel.info/pipermail/trisquel-users/2017-April/076940.ht
> ml][I made some suggestions to recommend for average users]].
> 
> 
> Respectfully, Adonay.
> --
> - [[https://libreplanet.org/wiki/User:Adfeno]]
> - Palestrante e consultor sobre /software/ livre (não confundir com
>   gratis).
> - "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
>   GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
>   que está no endereço acima aos teus contatos.
> - Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
>   aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
>   /software/ livre. Favor entrar em contato em caso de dúvida.

signature.asc

Re: [GNU-linux-libre] Fully FOSS Tails OS

[Ivan Zaigralin]

Tails are not receptive to the idea, at least there's no reason to think they 
changed their minds. About a year ago I've made an effort to figure out how 
they estimate the chances of distributing malware within Linux blobs, and they 
stonewalled me completely. By that they've shown their deep ignorance about 
important issues pertaining to privacy and security policy, among other 
things. I also pointed out their main web page is incorrect in implying that 
FSF considers them free software, but to this day they've done nothing to fix 
that.

More info here:

https://labs.riseup.net/code/issues/5393#note-10

From the very start I suggested that Tails should simply transition to Linux-
libre or something similar, and dump the nonfree kernel after a transitional 
period. I have made it a privacy & security argument, but they did not budge. 
I still think it is unfortunate to have one team work on technical aspects, 
while the other, completely independent team is solving issues related to 
security and ethics. But given the level of denial, the best we can do is wash 
our hands and fork it over. The way the winds are blowing these days, it is 
kind of obvious to me at least, Tails will eventually have to follow Heads, or 
else they will be left behind :)

On Sunday, January 08, 2017 12:54:00 Kurtis Hanna wrote:
> Hello,
> 
> Anyone interested in helping port Tails to the linux-libre kernel?
> 
> They sound receptive to the idea: https://labs.riseup.net/code/issues/5393
> 
> Kurtis

signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] Free firmware - A redefinition of the term and a new metric for it's measurement.

[Ivan Zaigralin]

I think FSF has struck gold with its firmware stance, basically treating it as 
all other software, which it is. So the question of what constitutes libre 
firmware is not controversial: can we read & understand  the source? can we 
modify, rebuild, and redeploy at will? can we distribute modifications? The 
only gray area here is of technical nature, like there may be firmware 
literally without source, as in well-documented byte-code.

I like how you draw the distinction between options 1 & 2, but I hope you 
yourself can see, this is not a soft, but a hard distinction: there's a 
certain feeling that option 1 *hardware* won't be so likely to serve you a 
turd. So the topic you are digging is free hardware, which is a very murky and 
difficult topic at the moment. And again, FSF is right where it needs to be 
with a great compromise, which involves well-documented, audited hardware, as 
far as I can tell (please correct me if I misrepresent the hardware 
certification process).

However, there's no deep difference between (1) and (2). The issue at hand is 
that (1) as well as (2) is a blob of silicon, impractical to inspect, modify, 
or share with others, and the "source" for it is impossible to pin down, as 
it's the entire manufacturing process. So I believe we just need to keep our 
hardware as clean as we possibly can using the social and legal means, while 
paving the way for 3d-printing it in the future. If we can get to the point 
where a neighborhood print shop can (legally) bake libre chips, the free 
hardware problem will be solved once and for all.

On Friday, February 03, 2017 15:37:32 David Craven wrote:
> Motivation:
> We want to be able to exercise our freedoms in all parts of our
> computing systems. This leads to the benefits of higher security and
> maintaining hardware devices after their end of life.
> 
> Background:
> All peripheral devices work roughly the same.
> 
> Host Controller Interface <-> Link Layer <-> Physical Layer
> 
> The physical layer is a mixed signal circuit responsible for
> implementing the electrical interface of the device. The boundary
> between LL and PHY is a clock domain crossing. The PHY layer is
> implemented entirely in hardware and is fixed in silicone.
> 
> The link layer is implemented either in digital logic also fixed in
> silicone or in complex peripherals partially in firmware.
> 
> HCI <-> Microcontroller <-> Digital logic <-> PHY
> 
> This leads to two models of loading the firmware that runs on the MCU.
> 
> 1. The peripheral does not contain persistent storage and the firmware
> is loaded by the linux kernel through a standard API.
> 
> 2. The peripheral contains persistent storage containing the firmware
> and uses a separate interface for flashing the firmware.
> 
> Problem:
> Today as an example, a WiFi card using option 2 is considered more
> free than one using option 1.
> 
> Implications on Security:
> While in the first case we can check the hash of the binary blob and
> be certain that the binary blob we are providing is what is running on
> the device, in the second case we do not even have that guarantee. A
> malicious party can reflash the firmware and no one would ever know.
> Security through obscurity is no security at all.
> 
> Just as important a threat to security as a malicious party is human
> error. With the second model there is no simple way to fix
> vulnerabilities even if the vendor is aware and willing to fix it.
> 
> Implications on Freedom:
> This also makes it much harder to write, debug and distribute free
> firmware if such where available.
> 
> Solution:
> We need to encourage and allow option 1 as opposed to option 2.
> Hardware suggestions by the FSF should instead of focusing on a black
> and white - needs binary blobs or does not need binary blobs - focus
> on the following:
> 
> 1. The firmware is freely redistributeable - allowing free software
> distributions to redistribute the firmware as opposed to the user
> having to download the firmware themselves and accept arbitrary terms
> and conditions.
> 
> 2. The firmware can be loaded using the standard kernel api and the
> device does not contain any internal storage.
> 
> 3. There is documentation available that enables the developement of
> free firmware.

signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] Perfectionism

[Ivan Zaigralin]

On Thursday, November 10, 2016 23:01:46 Zlatan Todoric wrote:
> Hi,
> 
> On 11/10/2016 09:46 PM, Ivan Zaigralin wrote:
> > Your summary of this thread could hardly be less correct. We already
> > identified at least one problem with the OS itself: the presence of the
> > stock firefox. No one is upset at Purism for putting PureOS on their
> > hardware, but we suggested a clear separation between the two fronts. As
> > John Sullivan explained, FSF cannot endorse the hardware project on the
> > account of nonfree BIOS, so they cannot endorse PureOS as long as the two
> > projects are fused within the web space the way they are. In particular, 
> > the laptop store can continue doing all the same things, like advertizing
> > PureOS and shipping it preinstalled. The inverse endorsement (PureOS ->
> > Librem) may also be possible, in a way similar to how Trisquel endorses
> > ThinkPenguin hardware.
> 
> John didn't explained that, on contrary he said that you can't judge
> PureOS regarding to hardware where it is preinstalled.

I stand by my interpretation.

> And what
> separation are we talking about - PureOS is Free, putting it on some
> other domain or whatsoever is not going to make it more Free.

No, but it would get your project approved, which is what you want, right? And 
once again, can't you see the difference between software being libre on one 
hand, and a GNU/Linux distribution being FSDG-compliant, and hence endorseable 
by FSF? PureOS may well be 100% free software, but this is but one check-list 
item on the way to FSF certification. The've made it abundantly clear over the 
years, they will not endorse projects that pedal nonfree software. If you want 
FSF to endorse the PureOS project, you must make it separate enough in their 
view (which emulates the view of most users) from the Librem project, which 
distributes nonfree software.

> Being nitpicky about wording and not about how to deliver content in
> this age (I really can't see how this website can help to any new user
> today http://ututo.org/) is obviously failing (if it isn't obvious to
> you that after 3 decades GNU/FSF are still really small and actually
> every year less and less important to average mass "attached" to
> Internet/personal devices and that ecosystem just moved on, well I can't
> ever explain it to you then).

This really is deviating from the topic, but I respectfully disagree. I thank 
"Bob" every day FSF took and kept the hardline stance, as I am convinced if 
they didn't, we would not have free laptops today. You are complaining about 
the smallness of our ecosystem, but I believe it's as large as it could be by 
now, thanks mostly to FSF's clear and firm thrust.

To elaborate, I want to compare non-free software with the addictive drugs 
which are being used to treat minor pain. Please give me a chance to draw an 
analogy. As it stands, we are living in the world where any shmoe can put out 
a drug, without any scientific testing, indeed without audit of any kind, with 
mystery contents, and as addictive as possible, and claim it cures whatever. 
And a lot of people are buying it, and they all get addicted, and they cannot 
take libre drugs anymore because the proprietary drugs are designed to prevent 
coexistence by producing deadly side-effects. And you want FSF to go easy on 
that sleaze? Do you really think being more tolerant of what the peddlers do, 
and more accepting of the poison they sell would improve things?

The public cannot switch to free, safe, and effective product because it's 
addicted to drugs designed to exploit them and trap them in the proprietary 
ecosystem, not because the free option is deficient, or its advocacy is too 
stiff. As we are leaving the analogy, we will not see a big change until 
nonfree software is against the law, just like untested drugs are against the 
law right now! All these statements about how FSF is unfriendly and 
inflexible, how it nitpicks the terminology, and how all of that ruins 
adoption, all that "criticism" sounds just like the moans of an addict. And 
even if you are not in fact an addict to nonfree software, it still sounds 
like whining, and without any merit.

Look at Munich: they passed a law, and presto, transition complete. That's the 
way to do it. Sweet-talking clueless masses ain't it, all it does is it 
dilutes the message and makes nonfree software appear more benign than it is.


signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] Perfectionism

[Ivan Zaigralin]

Your summary of this thread could hardly be less correct. We already 
identified at least one problem with the OS itself: the presence of the stock 
firefox. No one is upset at Purism for putting PureOS on their hardware, but 
we suggested a clear separation between the two fronts. As John Sullivan 
explained, FSF cannot endorse the hardware project on the account of nonfree 
BIOS, so they cannot endorse PureOS as long as the two projects are fused 
within the web space the way they are. In particular,  the laptop store can 
continue doing all the same things, like advertizing PureOS and shipping it 
preinstalled. The inverse endorsement (PureOS -> Librem) may also be possible, 
in a way similar to how Trisquel endorses ThinkPenguin hardware.

On Friday, November 11, 2016 00:14:25 Riley Baird wrote:
> The key thing which I am understanding from following this thread is
> that Purism wants to get PureOS FSDG-certified. Nobody can see any
> problem with the OS, but they're upset that Purism is putting the OS
> onto hardware that has a non-free BIOS.
> 
> From a business perspective, selling only hardware with a free BIOS is
> not practical. At all. So effectively, you're asking Purism to either
> adopt a business model that won't work as a condition of certification.

signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] review PureOS ISO

[Ivan Zaigralin]

This makes sense, but If Trisquel can endorse laptops with nonfree BIOS (and 
not only they endorse it, they apparently get a sales cut), then so should be 
able any other FSDG-compliant distribution. Completely in line with previous 
suggestions, the PureOS would probably still need its own net domain, and the 
link(s) to the supported hardware will have to be accompanied with a clear 
explanation of its deficiencies in the freedom department. I have to say, 
until this topic was brought up, I did not think these kinds of endorsements 
were OK at all, but may be I was interpreting FSDG too harshly.

Zlatan, you should probably try to get this sorted out through the official 
channels, and cite the Trisquel's supported laptop list as an example.

On Thursday, November 10, 2016 08:10:19 Jean Louis wrote:
> On Thu, Nov 10, 2016 at 08:51:14AM +1100, Riley Baird wrote:
> > On Wed, 09 Nov 2016 10:01:51 -0800
> > 
> > Ivan Zaigralin <melik...@melikamp.com> wrote:
> > > non-free hard/software
> > 
> > What, so now the FSDG don't allow you to recommend non-free hardware?
> > 
> > > The FSDG could not be clearer on this point: it will not approve
> > > any project that advertises and/or delivers non-free software
> > 
> > Should Trisquel be able to create a list of computers with compatible
> > hardware?
> 
> When I land on a web page of free system distribution, I don't expect
> it to recommend me any non-free hardware. With some tags on such
> hardware, like Trisquel has made a list, it gives me a freedom of
> choice.
> 
> If I am however attracted to PureOS, arriving to Puri.sm website,
> these are all "meanings" in the names, and then I come to Notebook
> "Librem", these are all targeted words for certain group of users, I
> feel it is targeted for me. Then again I get Librem notebook with
> non-free blobs, whatever. Hypocrisy. I don't expect that from a free
> system distribution.
> 
> So:
> 
> Any hardware, containing and kind of software inside, and recommended
> by free system distributions shall be compatible with Free System
> Distribution Guidelines. This way, blobs, firmware, non-free software
> in such hardware would not be recommended to users of free
> software. Finally, that type of software often has a potential power
> to take over the full computing control.
> 
> The non-free hardware has been recommended to users over few
> decades. The Free System Distributions and Free Software movement is
> to make a turn and change there, it is not there to promote non-free
> software and non-free BIOS, it is there to eradicate it.
> 
> Wordnet:
> 
> 2. (1) hypocrisy -- (insincerity by virtue of pretending to have
> qualities or beliefs that you do not really have)
> 
> 
> Jean Louis

signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] review PureOS ISO

[Ivan Zaigralin]

By non-free hardware I mean specifically the hardware with non-free software 
pre-installed or the hardware that won't work without non-free software. I did 
not mean to make a statement about "free hardware" proper, whatever that might 
be.

On Thursday, November 10, 2016 08:51:14 Riley Baird wrote:
> On Wed, 09 Nov 2016 10:01:51 -0800
> 
> Ivan Zaigralin <melik...@melikamp.com> wrote:
> > non-free hard/software
> 
> What, so now the FSDG don't allow you to recommend non-free hardware?
> 
> > The FSDG could not be clearer on this point: it will not approve
> > any project that advertises and/or delivers non-free software
> 
> Should Trisquel be able to create a list of computers with compatible
> hardware?

signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] review PureOS ISO

[Ivan Zaigralin]

For all the criticism I leveled against Icecat in the last year, I am in fact 
using it as my primary browser, and we include it in FreeSlack as the Firefox 
replacement. It is not perfect, but is certainly is a viable solution, for 
users as well as for distro maintainers.

Nice to hear others are coming along... I really want to start experimenting 
with providing light-weight, and especially javascript-free options.

On Wednesday, November 09, 2016 20:26:02 Jean Louis wrote:
> On Wed, Nov 09, 2016 at 10:01:51AM -0800, Ivan Zaigralin wrote:
> > you distribute a browser which suggests non-free addons, period. I am well
> > known around here for criticizing Icecat, so I am not saying that's
> > what you
> 
> Straying from subject:
> 
> - IceCat is great for some usage, but bloated, I have switched to
>   surf, xombrero, uzbl, they are also way easier to compile:
> 
>   Xombrero shall be on OpenBSD, don't know quite:
>   https://github.com/conformal/xombrero
> 
>   http://uzbl.org - excellent pipe, socket, controllable browser
> 
>   surf from http://suckless.org
> 
> And those could be included in free system distributions.
> 
> 
> JL

signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] review PureOS ISO

[Ivan Zaigralin]

> I will stop responding to mails trying to attach our OS with our
> hardware. This is for FSF Free distro endorsement, and the other is for
> RYF hardware - stop combining the two things.

Though an FSF member, I am not a part of the team that makes the determination 
for FSDG compliance, so my comments are strictly advisory.

Also, I am always in the market for freedom-respecting laptops, and I 
certainly hope I can use your products one day, since they look and sound 
awesome. I wish you luck in your business venture and I hope you will succeed 
in fully liberating your hardware, and getting that approved by FSF as well. I 
certainly think it should be your goal, given your philosophy.

With that being said,

You are the ones who combined OS and hardware by putting both things on the 
same website. In fact, the page where you peddle non-free laptops is literally 
one click away from your OS page, and in the same domain. The FSDG could not 
be clearer on this point: it will not approve any project that advertises 
and/or delivers non-free software, and it doesn't matter whether this non-free 
software is technically a part of the OS, as long as its endorsement comes 
from the same project. For example, Trisquel could never get approved if they 
used their domain to suggest installing adobe flash, nevermind whether they 
distribute it themselves.

So far in this conversation you have been offered an extremely easy and clear 
way to fix this issue, simply by decoupling the OS from your hardware 
business. For reasons I do not quite understand, you ignored that suggestion 
completely. If PureOS wants to be even considered for the FSF endorsement, it 
should at the very least create a separate domain for itself, and remove all 
endorsement of non-free hard/software from that domain. This is FSDG 101. You 
can still endorse and recommend PureOS from the non-free hardware side, but 
not the other way around. Your PureOS front may not willfully lead users to 
non-free software, how hard is that to understand? Once you have a free 
laptop, you will be able to advertize that particular product from the PureOS 
side, but not your whole business, not for as long as you business has any 
non-free options available for sale.

> We are mirroring Debian main archive for that and AFAIK Firefox is
> entirely FLOSS, but it allows non-free extensions. It would be a bit
> radical to remove it because users can access non-free extensions - we
> can use lynx to access websites that promote nonfree things etc etc. I
> think many distros used Iceweasel and now will use Firefox if they are
> based on Debian - and again, Firefox is Free software AFAIK.

Once again, you seem to be ignoring the suggestions designed to get you 
approved. The stock Firefox fails FSDG, as so does every Mozilla product that 
leads users to install non-free addons via the addon interface. No one is 
arguing with you on this, we are simply telling you this issue has been 
discussed to death already, and the conclusion reached by the FSDG compliance 
team is what I just said. You stand no chance getting the endorsement while 
you distribute a browser which suggests non-free addons, period. I am well 
known around here for criticizing Icecat, so I am not saying that's what you 
must use to replace Firefox, but you will have to replace it with something, 
be it Icecat or or your own homebrew, so long as it fixes all the same issues 
Icecat had to fix in order to become compliant.

As an aside, you seem to be conflating free software with FSDG, but they are 
not the same at all. FSDG is much stronger: it certainly implies that the 
entire OS in question must be free software, but there is much more on top of 
that. Some versions of Firefox and Thuderbird, for example, may well be free 
software, but they also clearly fail FSDG, and so does the PureOS website in 
its present state.

I really hope this has been helpful. Once again, I wish more capable 
distributions would join the FSDG ranks, and I hope you will see the reason 
behind our comments and start taking meaningful steps towards making the 
PureOS project more user-friendly.


signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] xorg-fonts (was:FreeSlack: In search of FSF certification)

[Ivan Zaigralin]

Sounds good, we'll purge

> font-bh-ttf-1.0.3-noarch-1.txz
> font-bh-type1-1.0.3-noarch-1.txz

Sneaky...

On Tuesday, August 09, 2016 12:07:33 Henry Jensen wrote:
> On Tue, Aug 09, 2016 at 11:58:01AM +0200, Henry Jensen wrote:
> > Hi,
> > 
> > On Mon, Aug 08, 2016 at 01:15:51PM -0700, Ivan Zaigralin wrote:
> > > I have hard time figuring out the license for these:
> > > 
> > > font-bh-lucidatypewriter-100dpi-1.0.3-noarch-1.txz
> > > font-bh-lucidatypewriter-75dpi-1.0.3-noarch-1.txz
> > > 
> > > No-mod clause is present in these:
> > > 
> > > font-bh-ttf-1.0.3-noarch-1.txz
> > > font-bh-type1-1.0.3-noarch-1.txz
> > 
> > You're right about font-bh-typewrityper and I removed it from the
> > ConnochaetOS' repo.
> 
> I meant font-bh-type1 ...
> 
> > But am am not sure about font-bh-ludicatypewriter. Gentoo claims this
> > fonts
> > are "public domain" [0]
> > 
> > Furthermore Trisquel (and Debian) have this fonts included as part of
> > their xfonts-100dpi and xfonts-75dpi package. So I think it is okay to
> > keep
> > them until someone have seriously doubts.
> > 
> > [0]
> > https://packages.gentoo.org/packages/media-fonts/font-bh-lucidatypewriter
> > -100dpi


signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] FreeSlack: In search of FSF certification

[Ivan Zaigralin]

I have hard time figuring out the license for these:

font-bh-lucidatypewriter-100dpi-1.0.3-noarch-1.txz
font-bh-lucidatypewriter-75dpi-1.0.3-noarch-1.txz

No-mod clause is present in these:

font-bh-ttf-1.0.3-noarch-1.txz
font-bh-type1-1.0.3-noarch-1.txz

On Monday, August 08, 2016 11:54:17 you wrote:
> Hi,
> 
> On Sun, Aug 07, 2016 at 09:59:46AM -0700, Ivan Zaigralin wrote:
> > Thanks! I can confirm the fonts. And actually, other Luxi fonts share the
> > same license, so they are all as good as gone.
> 
> Which other luxi fonts do you mean exactly (name of packages)?
> 
> > ap/ghostscript-9.19-x86_64-2.txz is clean: I am looking at the source, and
> > there is no jpegxr folder. Slackware must be using a clean version.
> 
> Yes, it seems so. However, jpegxr is still mentioned in the LICENSE file.

I am assuming that's OK.

signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] FreeSlack: In search of FSF certification

[Ivan Zaigralin]

Thanks! I can confirm the fonts. And actually, other Luxi fonts share the same 
license, so they are all as good as gone.

ap/ghostscript-9.19-x86_64-2.txz is clean: I am looking at the source, and 
there is no jpegxr folder. Slackware must be using a clean version.

On Sunday, August 07, 2016 12:28:19 Henry Jensen wrote:
> I compared he list of non-free and thus excluded packages of freeslack[0]
> with my list of excluded packages in ConnochaetOS [1]. ConnochaetOS
> excluded following packages which freeslack does not.
> 
> * ap/ghostscript-9.19-x86_64-2.txz
>   ConnochaetOS provides an modified/libre version of Ghostscript
>   without nonfree JPEG XR support, based on Parabola's build [2]
> 
> * x/font-bh-ttf-1.0.3-noarch-1.txz
> * x/font-misc-meltho-1.0.3-noarch-1.txz
>   This are non-free fonts according to Parabola's blacklist.[3] I
>   re-checked and indeed the license of this two fonts is non-free
>   because it allows no modification.

signature.asc
Description: This is a digitally signed message part.

[GNU-linux-libre] seamonkey & thunderbird versus FSDG

[Ivan Zaigralin]

Dear Rubén and all of you folks, I have a hypothetical question.

I've been looking around for a FSDG-compliant versions of seamonkey and 
thunderbird, and I am not finding anything current. Am I missing anything? It 
occured to me that may be not that much has to be done. What do you think, if 
we took, say, seamonkey, compiled it unbranded and changed "get new addons" 
page so that it explains the situation (basically, go find your own free 
addons), would that comply with FSDG? Just musing.


signature.asc
Description: This is a digitally signed message part.

[GNU-linux-libre] FreeSlack: In search of FSF certification

[Ivan Zaigralin]

Hey everyone :)

We are very excited to announce an RC1 of FreeSlack 14.2. Since we spoke last 
time, we purged mozilla firefox, mozilla thunderbird, and seamonkey, leaving, 
as far as we can tell, nothing else that would violate FSDG. The purge 
affected both 14.1 and 14.2 repositories, of course, so we no longer 
distribute these packages in any way.

The wiki installation page still points to 14.1, but once RC1 goes gold in a 
few days, it will change.

Regardless of 14.2 release status, we believe we are ready for a final look-
over by an FSDG compliance agent.

Main wiki:

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

Repositories:

http://freeslack.net/fxp/

DVDs:

http://freeslack.net/fxp-iso/

More recent source with scripts for the entire process,
including deblobbing the DVD:

http://freeslack.net/fxp/freeslack64-14.2/source/fxp/

And finally, extra binary packages, including functional replacements for some 
of the omitted nonfree packages (lhasa, arj, icecat):

http://freeslack.net/fxp/freeslack64-14.2/fxp/

We are very hopeful this release finally meets FSDG. Please take a look and 
let us know.

Thanks a ton for your support :)


signature.asc
Description: This is a digitally signed message part.

Re: [GNU-linux-libre] [gnu.org #1089240] In search of FSF certification

[Ivan Zaigralin]

Thanks, and absolutely. Ideally, we would repackage something a la
icecat, and beyond that we will borrow as much code as possible. No
intention to reinvent the wheel here, just a desire to do the least
amount of work required to provide functional replacements.

On 05/26/2016 12:31 PM, Luke wrote:
> Hello,
> I'd just like to mention that FSF approved Parabola GNU/Linux-libre
> currently maintains patches for IceWease and IceDove.
> 
> If you are interested in seeing them you can do so here:
> https://projects.parabola.nu/abslibre.git/tree/libre/iceweasel
> https://projects.parabola.nu/abslibre.git/tree/libre/icedove
> https://projects.parabola.nu/abslibre.git/tree/nonprism/icedove
> 
> We remove DRM, Branding, and anti-privacy "features" as well. So if your
> looking for ideas, feel free to borrow from it! It'll save you some time.
> 
> On 05/26/2016 02:21 PM, Ivan Zaigralin wrote:
>> Sounds great. What I think we will do is we will purge offending mozilla
>> products and possibly provide replacements. It will be done during June.
>> Then we'll give a shout-out for the final check both to you and the
>> linux-libre group.
>>
>> Now, I have a somewhat technical question. As for firefox, there is an
>> excellent replacement, which is icecat, but after that it gets tricky.
>> We are kicking around the idea to build tbird, seamonkey (and possibly
>> also firefox)
>>
>> (1) with branding disabled
>> (2) with "get addons" page set to a static message like "get them
>> yourself, make sure they are free"
>>
>> Do you think that would be enough to make these packages free?
>>
>> On 05/26/2016 08:52 AM, Joshua Gay via RT wrote:
>>> Sorry for the delay in getting back to you. 
>>>  
>>>>> You should use unbranded versions of these programs. I recommend
>>>>> considering GNUZilla <https://www.gnu.org/software/gnuzilla/> or looking
>>>>> at the versions packaged by Trisquel. 
>>>> To be sure, do you guys require or merely suggest this?
>>> The official branded version of Firefox is nonfree software due to
>>> trademark restrictions on distributing verbatim copies of the Firefox
>>> binaries. You do not have to package GNUZilla or GNU IceCat to comply
>>> with the FSDG. 
>>>
>>>> "The most important way to help us is by checking our work with respect
>>>> to licensing. If you know of a non-free package we (accidentally)
>>>> distributed, please notify us as soon as possible."
>>>>
>>>> http://freeslack.net/dokuwiki/doku.php?id=participation
>>> Great.
>>>
>>>
>>> Can you please follow-up again with Linux-libre mailing list asking them
>>> to do a final check? You should provide them with: 
>>>
>>> * The link you provided above
>>> (<http://freeslack.net/dokuwiki/doku.php?id=participation>) for people
>>> to file nonfree bugs and your commitment to following the FSDG. 
>>>
>>> * A link to your package repositories to show that you are self hosting
>>> and are not just relying upon an upstream distros servers/repositories. 
>>>
>>>
>>> Best,
>>>
>>> Josh
>>>
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] [gnu.org #1089240] In search of FSF certification

[Ivan Zaigralin]

Sounds great. What I think we will do is we will purge offending mozilla
products and possibly provide replacements. It will be done during June.
Then we'll give a shout-out for the final check both to you and the
linux-libre group.

Now, I have a somewhat technical question. As for firefox, there is an
excellent replacement, which is icecat, but after that it gets tricky.
We are kicking around the idea to build tbird, seamonkey (and possibly
also firefox)

(1) with branding disabled
(2) with "get addons" page set to a static message like "get them
yourself, make sure they are free"

Do you think that would be enough to make these packages free?

On 05/26/2016 08:52 AM, Joshua Gay via RT wrote:
> Sorry for the delay in getting back to you. 
>  
>>> You should use unbranded versions of these programs. I recommend
>>> considering GNUZilla  or looking
>>> at the versions packaged by Trisquel. 
>>
>> To be sure, do you guys require or merely suggest this?
> 
> The official branded version of Firefox is nonfree software due to
> trademark restrictions on distributing verbatim copies of the Firefox
> binaries. You do not have to package GNUZilla or GNU IceCat to comply
> with the FSDG. 
> 
>> "The most important way to help us is by checking our work with respect
>> to licensing. If you know of a non-free package we (accidentally)
>> distributed, please notify us as soon as possible."
>>
>> http://freeslack.net/dokuwiki/doku.php?id=participation
> 
> Great.
> 
> 
> Can you please follow-up again with Linux-libre mailing list asking them
> to do a final check? You should provide them with: 
> 
> * The link you provided above
> () for people
> to file nonfree bugs and your commitment to following the FSDG. 
> 
> * A link to your package repositories to show that you are self hosting
> and are not just relying upon an upstream distros servers/repositories. 
> 
> 
> Best,
> 
> Josh
> 



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] MAME emulator is giving incentive to use non-free software

[Ivan Zaigralin]

Of course there are holdouts. You know of one. But they are
disappearing, while the historical use of such emulators becomes more
and more relevant. So while you are probably more right at this moment,
my points are becoming more and more valid every day, and MAME is
turning from overall malicious to useful in the near future.

I mean, even your b.i.l. seems to be motivated by the retro and d.i.y.
aspect of it all, not the ads. And the non-free software in question is
not even utility software, it's pure entertainment, and it's perfectly
safe. It is true we cannot study, improve, or share it, but that does
not make _using_ it either dangerous or unethical. It makes absolutely
no sense to protect anyone from running these games, especially if that
results in people building cabinets and inviting friends over, instead
of paying micro$oft or $ony to install a $500 audio/video bug their your
house.

Consider also that the software component of these things is becoming
ever more trivial by today's standards. For an apt analogy, just think
of these games as interactive books, and MAME as a viewer. These games
are works of art and art historians must be able to view them. There
will never again be a non-free software ecosystem there, but thanks to
MAME a free software ecosystem may yet develop.

On 04/01/2016 01:17 PM, Leo wrote:
> On Fri, Apr 1, 2016 at 8:51 AM, Ivan Zaigralin <melik...@melikamp.com
> <mailto:melik...@melikamp.com>> wrote:
> 
> The point of emulators like this one is to preserve software history.
> Yes, it emulates non-free software. No, it's no longer relevant. I mean,
> it's no longer relevant as software, but only as the historical record
> of what entertainment software was like in the times of yore. New
> nonfree games are being written today in order to seduce people, so I
> can see why something like wine is dangerous, but no one, no one will
> get seduced by a museum piece. MAME does not give any incentive to use
> non-free software, because all of this old software is obsolete and
> useless. But it does give an ability to study it from the historical
> perspective, which is a good thing.
> 
> 
> I disagree with all this. My brother-in-law built an arcade-like cabinet
> and put MAME in it. He plays these games and invites his friends to play
> these games with him. A coworker is working on the same thing. They are
> not exactly obsolete if they still provide entertainment. That's like
> saying that Jane Austen's Pride and Prejudice is obsolete because now we
> have romantic comedies in 3D.
> 
> That being said, I'm still not sure what to think of MAME, but I
> personally see it in the same level as WINE.



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] MAME emulator is giving incentive to use non-free software

[Ivan Zaigralin]

The point of emulators like this one is to preserve software history.
Yes, it emulates non-free software. No, it's no longer relevant. I mean,
it's no longer relevant as software, but only as the historical record
of what entertainment software was like in the times of yore. New
nonfree games are being written today in order to seduce people, so I
can see why something like wine is dangerous, but no one, no one will
get seduced by a museum piece. MAME does not give any incentive to use
non-free software, because all of this old software is obsolete and
useless. But it does give an ability to study it from the historical
perspective, which is a good thing.

On 03/29/2016 09:31 AM, alírio eyng wrote:
> these are the approaches i can think:
> *extremely conservative (eliminating false positive errors)[1]
>  removing all emulators
> *conservative (eliminating false positive errors)[1]
>  make packages/executables like game1-emulator1, game1-emulator2, ...
> and not allowing direct emulator installation/execution
> *liberal (avoiding false positive errors[1] and false negative errors[2])
>  allowing all emulators with free games know
> *extremely liberal (eliminating false negative errors)[2]
>  allowing all emulators
> 
> extremely liberal is naive because it just looks down in the
> dependency dag, there's no reason to not look up
> extremely conservative is naive because it doesn't allow completely free uses
> conservative would solve the issues that originate this thread
> liberal is more convenient in some cases
> 
> i consider conservative better, liberal ok, and any of the extremes 
> unreasonable
> 
> fsdg doesn't allow extremely liberal (according to other people
> interpretation), in ndiswrapper, for example:
> "with one exception, all ndis drivers are nonfree--and the one free
> one is a windows port of a native linux driver. so right now, this
> isn't useful for anything besides using nonfree software"[3]
> 
> parabola follows extremely conservative with your-freedom_emu[4]
> 
> assuming we choose conservative; for wine, we can make guile-wine,
> emacs-wine[5] and gnutls-wine[6], but remove wine
> 
> it seems there's at least one free game needing an emulator[7]
> 
> i think this is a discussion about fsdg[8] and we should discuss it at
> gnu-linux-libre@nongnu.org
> 
> [1]https://en.wikipedia.org/wiki/false_positives_and_false_negatives#False_positive_error
> [2]https://en.wikipedia.org/wiki/false_positives_and_false_negatives#False_negative_error
> [3]https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines
> [4]https://www.parabola.nu/packages/libre/any/your-freedom_emu/
> [5]https://lists.gnu.org/archive/html/guix-devel/2016-03/msg01216.html
> [6]https://lists.gnu.org/archive/html/guix-devel/2014-11/msg00333.html
> [7]http://pineight.com/lu/
> [8]http://www.gnu.org/distros/free-system-distribution-guidelines.html
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: [GNU-linux-libre] In search of FSDG certification

[Ivan Zaigralin]

Thanks, stressware! This is indeed our take on it.

While this is totally irrelevant to  the matter at hand, here's a fun
piece of trivia: Slack actually refers back to the gift of "Bob", not
Slackware :)

At any rate, we have a feeling these names are just different enough:
they make very different aural impressions, and "Slack" is in a
different part of the word. The case against "Slack" (if there's one)
would seem to be weaker than the case against something like
"Blackware", "Slacksoft", or "Bobware", which also share half a word
with "Slackware", but sound, spell, and mean very similar.

On 03/02/2016 03:11 AM, stressw...@cock.li wrote:
> 
>> I think the name "FreeSlack" may be in conflict with the FSDG:
>> "We will not list a distribution whose name makes confusion with
>> nonfree distributions likely. For example, if Foobar Light is a free
>> distribution and Foobar is a nonfree distribution, we will not list
>> Foobar Light. This is because we expect that the distinction between
>> the two would be lost in the process of communicating the message.
>>
>> In particular, the principal name of the free distribution
>> (“Foobar”, in this example) should not be part of the name of any
>> nonfree distribution."
>>
>> Regards,
>>
>> Henry
> 
> That seems to just refer to confusion, not mere reference. It is
> likely that people will think that 'FreeSlack' is derived from
> Slackware, as it is, but I doubt whether many will confuse it for
> Slackware. Only part of the name of the Free distribution (FreeSlack)
> is part of the name of a non-Free distribution.
> 
> 



signature.asc
Description: OpenPGP digital signature

[GNU-linux-libre] In search of FSDG certification

[Ivan Zaigralin]

Dear Linux-libreans :)

I am writing on behalf of the FreeSlack project, where I am one of the
lead maintainers, along with Matt Samudio. I am writing to this list on
the advice of Joshua Gay of the FSF licensing team.

On 03/01/2016 08:20 AM, Joshua Gay via RT wrote:
> Yes, I think it sounds like it's worth taking a step in this direction.
> The first thing I would do is join the GNU Linux-libre mailing lit if
> you have not already done so and let them know about your project and
> that would like their help in looking it over to make sure you meet all
> of the GNU Free Distribution Guidelines (GFDG),
> . 
> 
> I will have an internal discussion with the FSF licensing team and a
> very quick look at the project to make sure nothing obvious stands out.
> The most important thing is a project making a stated commitment to the
> GFDG and promising to remove any nonfree bugs when they get reported in
> a timely manner.

These are indeed (some of) our commitments (we will amend our wiki to
say so explicitly), and our official description follows:

> FreeSlack is a Free eXpansion Pack for Slackware. The project's
> primary goals are to document all non-free software in Slackware
> distribution, and to make it easy for users to maintain a fully free
> OS based on Slackware.
>
> Technically speaking, FreeSlack is a complete distribution and a
> Slackware derivative, but we prefer to think of ourselves as a
> shortcut to a free flavor of Slackware. We are not affiliated with
> the Slackware project, have no developers in common, and share no
> infrastructure. We use the term Slackware only in reference to the
> stock OS distributed by Patrick Volkerding. One of our ambitions is
> to become integrated within the existing Slackware community, and we
> hope to achieve that by making the smallest possible changes needed
> to deblob Slackware, while leaving all technical decisions up to the
> Slackware team.

[[ http://freeslack.net/dokuwiki/doku.php?id=start ]]

We have a free DVD image which installs a deblobbed (free) derivative of
Slackware, with package manager configured to use our free repository,
so that the user is never compelled to obtain anything from the
Slackware servers.

[[ http://freeslack.net/dokuwiki/doku.php?id=installation ]]

The source code for the project is described and linked to as well.

[[ http://freeslack.net/dokuwiki/doku.php?id=installation#source_code ]]

So we would like to go ahead and see if anyone would like to help us out
through the certification process, and towards being officially
FSDG-compliant. Please let us know what you think.




signature.asc
Description: OpenPGP digital signature