
FSF adds PureOS to list of endorsed GNU/Linux distributions - TheAsprngHacker
http://www.fsf.org/news/fsf-adds-pureos-to-list-of-endorsed-gnu-linux-distributions-1
======
quadrangle
The whole Purism project is so promising. They've continued to go in the right
direction, addressing all concerns and being transparent. I really hope they
succeed long-term!!

~~~
rurban
I don't. Looks like a sham to me, speaking from personal experience.

I do sympathize with their goals, to protect their users from potentially
costly mistakes, such as installing a software, which has the wrong license.
Such as code like randlib, which was once published in the ACM magazine, and
therefore has the interesting license restriction that it should not be used
"for financial gain". Which would be a problem if you want develop commercial
software. An even bigger problem would be to use GNU licensed software, go
figure. But anyway, there should be a way to check licenses when you install
potential "nonfree" packages. Apparently some people care about this stuff.

But the actual case was made against cpanm, which is the second perl package
manager, in
[https://tracker.pureos.net/T277](https://tracker.pureos.net/T277), because
"cpanminus is a helper tool to download perl modules distributed as part of
CPAN. As such it is a domain-specific package manager, which potentially
involves nonfree code - and is outside the control of PureOS. The package
should be blocked from getting included from Debian into PureOS."

This is of course a ridiculous stance on native package managers. And then you
need to block besides all package managers (pip, cpan, npm, go, ...), also
wget, curl and firefox/chromium. But I also feel a bit of sympathy over these
concerns. Technically it's trivial to solve, because the CAPN database, as
well as most other such package databases, pypi, php, npm, emacs, ... all have
a mandatory LICENSE field, and the pureos-enabled package manager would just
check this field, and then either warn or error. So you'd need two additions:
a list of licenses to warn about, and a policy: warn or error.

But discussing this with cpanm, the client in question makes no sense at all.
The questions would be, who decides what's non-free or not? PureOS, Debian,
fedora or the FSF? Or some other entity which could decide on such issues. In
this case it would be most likely PureOS. So they would need to help upstream
development to decide how to implement such a new feature. It would cost about
1hr of work, but first you need to plan it. give it a list of free licenses,
or a list of nonfree licenses, which list is bigger? list or regex. SPDX?
Upstream has no idea. The bigger native packagers are much more important in
such wide-reaching new policy decisions, such as npm or pypi, or emacs and
cpan.

As it turns it this pureos fellow has no interest at all in solving these
issues, and on the other side pypi also has zero interest into helping pureos
with their goal. Interestingly the pureos guy said on the pypi ticket the
complete opposite than on the pureos ticket. He is not interested to block pip
from being distributed with pureos, even if pypi has many packages with
nonfree licenses or unclear licenses. Same for npm. Same for all other package
databases and package clients.

So it looks like they just selectively picked the smallest packager from a
random observance. They are certainly not interested at all in helping with
the open questions to solve it for the users. But users can decide by
themselves. Look at the license. That's called freedom.

