-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pip should make the license on packages more transparent #3441
Comments
I don't think we want to get into the area of license management, even in the form of a warning. It's up to the developer to check the license conditions on any code he/she uses. It should be possible to write a 3rd party tool (using the PyPI APIs) to do this sort of check, if it matters to you. |
Neither should we be an arbiter of which licences should be deemed as "scary" and needing a warning. |
Yea, even though I'm personally not a fan of the GPL, I don't think it's a good idea for pip to start to try and force a particular opinion on other people like that. |
Its great we bring the issue up. If I could do it a second time, I wouldn't single out any particular license. License preference may be a matter of personal opinion, the compatibility between them and the downstream ramifications are not.
I understand why its a hairy situation. Let's look a bit beyond any one license. I think caveat emptor has its place when downloading packages. pip may not be in the business getting too involved in the particulars of licenses since its not realistic. No other CLI package systems I know of goes out of their way to audit license compatibility or prompt for licenses. Consider the following: A user downloads and installs package via pip and imports it in their software, no where do they ever see the license of the package they're downloading, installing and incorporating into their work. A user not seeing the licenses of a package they incorporate wouldn't make the ramifications go away. |
The more I think about it, I highly disagree with how this is hand waved as if licenses were picking a sport team. I'm bummed, I feel you guys don't care for the people who end up being led astray and unwittingly end up with a derived work 😦 |
It's a question of due diligence on the developer to begin with If you feel strongly about helping them to solve these, then please start with creating a tool that can warn them Pip is a volunteer project, as such it has limited resources, using coercion tactics advocate things you think it should do is one of the more toxic approaches and certainly won't work Create something that helps people be less sloppy about licences instead This could be something like the readme checker or a simple website listing perpetrator packages and their victim's/actual licences |
The concern is about license compatibility, correctness and that the information is clear and accessible. |
License compatibility is still a legal issue. I don't know how us having a say on it, we are supposed to get it right in any shape or form. |
Edit: see #3441 (comment). The intention of this isn't to point out any particularly license.
As an example, a seemingly innocuous package such as rfc3987 or django-wiki app are both GPLv3.
Another thing that poses incompatibility is BSD/MIT licensed projects that incorporate GPL code as a dependency. Examples:
It may be possible to draw a graph of dependencies to see if a library may be pulling incompatibly licensed code.
Is this in pip's or pypa's territory?
Related: #857
The text was updated successfully, but these errors were encountered: