4 ms·

FSF adds PureOS to list of endorsed GNU/Linux distributions

quadrangle 9y ago
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 9y ago
  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.

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 9y ago
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.