> It's a nice idea but as you've said it's hard to do in an automated way. > Some human intervention will always be needed.
Yeah, you're probably right. There's so much ambiguity in the license statements that any automated approach aggressive enough to remove all proprietary software would also remove so much free software that pip would no longer be very useful, especially since a package can't be considered free unless its entire dependency tree can. > This is probably why Trisquel > is doing what it's doing; It's easier to remove it than it is to filter and > maintain it. Yes, there's the work-to-return ratio to consider. I think it was right to just remove Snap completely, for example, since it was already not very useful to people who don't want to install proprietary software. A patch that could be implemented as a package helper seemed like it might be worth it to salvage pip, but especially after reading onpon4's comment I'm beginning to doubt whether additional efforts are worth it. > Personally, I don't know that your method of warning people sufficient > because this filter only acts if they use the client program to access it. > It doesn't prevent other methods, like if someone accesses it directly. (A > similiar thing could be pointed out by filtering out non-free .debs but I > could just open my browser to look at the repo and still see them.) People > still get sent to/referred to/whatever-you-call it to that place regardless. My thinking was that if the non-free package is excluded from pip's search results then anyone who tries to install it already knows it exists, and that explaining that the package is non-free is better then letting them assume that pip is just not working and installing the package by another means. However, I see your point. Maybe it is better to just ignore the package. That's more similar to how apt behaves when you try to install an Ubuntu package rejected by Trisquel, such as $ sudo apt install chromium ... Package chromium is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: chromium-bsu:i386 chromium-bsu E: Package 'chromium' has no installation candidate > Rather, there shouldn't *be* a repo with non-free things in it. That's a good point. A non-free repo shouldn't exist, so it would be strange to rely on one. > So: Copy the > free things into a new repo, and then all FSF-endorsed distro can change the > address in their copy of pypi to access the new location. > > Effectively, this is the option #2 mentioned by RMS in: > https://lists.libreplanet.org/archive/html/libreplanet-discuss/2016-04/msg00078.html I read that thread and agreed that a new repo would be a good solution, especially since as you point out this problem is not specific to Trisquel and a free PyPI replacement could be used by all FSDG distros. I get frustrated, though, that I spend so much time agreeing that things should be done and not much time doing them. I wouldn't know where to begin creating a replacement for the PyPI repo, so I approached the problem in a way that was within my skill set. It seems not to have been a great approach, although the automatic filtering could at least reduce the amount of additional manual work needed to create a new repo.
signature.asc
Description: PGP signature
