You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The LICENSE file refers to PIL, but makes no mention of Pillow. Since we otherwise refer to them as separate entities, is this something that should be fixed?
Somewhere we've lost the copyright notices for the additions that had been added (at least in the readme) and maybe elsewhere. I remember an assertion somewhere that it was now copyright AC and contributors.
We've now got a situation that's something slightly different than what's specified in the license. We have a collection of code that has copyrights owned individually by the contributors, and a licence that has been in effect while collecting these contributions that is essentially a MIT license. We do not have a single collective copyright, since we've never collected copyright assignments.
I think that we should carefully think about the license that we have and supersede it with one that references that there are many individual contributors, and that the current maintainers aren't offering warranties either.
Whatever we do, we should not be changing the existing license we should be prepending/appending to it in a manner that doesn't change the essential character of the license. If possible, I'd like to use an actual, recognized named license that's compatible with what we have now, rather than one that's almost, but not quite one that we can just reference. (Either Python, MIT or BSD, whichever is closest.)
@radarhere Still working on this? I guess we just need to explicitly state in the top level LICENSE that Pillow is licensed PSL (PIL Software License), if we haven't done so already.
Tidelift has asked us to review our license, particularly with regard to Libraries.io understanding of what our license is. My guess is that since GitHub thinks our license is "other", Libraries.io has no idea what to make of that, and is deciding "unknown".
We may need to ask them to configure Libraries.io to say "other" as well … at least then they'd match. @kszu ?
Yes, what's happening here is that (since our goal is to have high-quality license information everywhere, not just our tools) we're looking at the GH API. Most of the time, when the GH API chokes, it's because of poor formatting or legitimately complex license situations. This is the first time I've seen in a while where it is choking because of a rare license.
It looks like it has also uncovered a bug in libraries.io (which for some reason thinks the license is the Barr license, which I admit I hadn't heard of until today). So that's two for the price of one :)
At any rate, I don't think there is much for y'all to do here - your license situation is just complex/rare, and so we're going to have to change the status in our database for now. Thanks for helping us learn :)
Also, if no one objects, I'm going to submit the license to SPDX (a standards group that tracks licenses) so that SPDX-based tools can recognize and track PIL/Pillow.
Bad news: pypa does not currently allow HPND as a license identifier. (The current list is discussed here.) We'll update it at Tidelift, and hopefully pypa and GitHub will recognize it at some point.
But can you also please explain how the "Standard PIL License" and https://spdx.org/licenses/HPND.html are related? I'm assuming you're classifying the Standard PIL license as an HPND license, but not 100% sure about that. And if you are, I wanted to confirm that classification is accurate.
As such I'll note further, in case it helps, that we've never discussed licensing with Fredrik Lundh (remember this is a fork of his software licensed with the Standard PIL license) and our collective goal, historically, has always been to make as few changes as possible to PIL, including maintaining the same license.
It just so happens that at some point we had to give up on "making as few changes as possible" … and now that this licensing issue is coming up again I'm wondering if should consider any licensing changes. For example …
which, in referencing the Standard PIL license, states
(This is a trivial variation of the old Python license,
as used for Python 1.5.2 and earlier. In OSI terms,
it’s known as the Historical Permission Notice and Disclaimer.)
I think you figured it out! but to be 100% clear, just in case: we are not asking you to make a change to your license! We would only ask for that if it were completely, certainly cosmetic, and would make a significant difference for automated scanners. That's not the case here (at least, no such suggetion that I see right now) so no request to change anything.
Since the license text is almost exactly the text of the HPND, we'll note that in our database - will help some of our customers automate their license compliance. Thanks!
(A quick scan also suggests there's a bunch of other licenses in various places, like LGPL in ImageCms.py - but we aren't going that deep yet.)
For the longer term, do we want to supersede HPND with, say, BSD or MIT? Wikipedia suggests:
It is unique among the OSI's licenses because of the choices it allows in its construction; it lets the licensor pick anywhere from 0-2 warranty disclaimers, whether they want to prohibit the author's name from being used in publicity or advertising surrounding a distribution (like in the BSD License), and other spelling and grammar options. Besides this, the license can be almost functionally identical to the new 3-clause BSD License (if the option for the no-promotion clause is exercised), or the MIT License (if the option for the no-promotion clause is not exercised).
If you were starting a new project, or a rewrite, I'd recommend a newer license, like BSD-2-clause+Patent.
But since you've got all this old code contributed by people who are no longer with the project, you're pretty much stuck with the existing license - you can't simply make it go away. So not much upside in switching for new contributions; then people just have to comply with two licenses.
One possible exception: if you've got plugins or other clearly separable code that is often written from scratch and lives separately, you might require a more modern license for that code?
Do you know of anyone forking/reusing those plugins? If so, might be nice for new ones to be consistently under a more modern license. But realistically if they're only useful with PIL then not much upside to clarifying things.
Activity
hugovk commentedon Oct 26, 2015
I think "Python Imaging Library (PIL)" needs to remain intact, and the wording of the licence itself.
Perhaps Pillow could be added to the top.
What do others think?
wiredfool commentedon Oct 27, 2015
Somewhere we've lost the copyright notices for the additions that had been added (at least in the readme) and maybe elsewhere. I remember an assertion somewhere that it was now copyright AC and contributors.
We've now got a situation that's something slightly different than what's specified in the license. We have a collection of code that has copyrights owned individually by the contributors, and a licence that has been in effect while collecting these contributions that is essentially a MIT license. We do not have a single collective copyright, since we've never collected copyright assignments.
I think that we should carefully think about the license that we have and supersede it with one that references that there are many individual contributors, and that the current maintainers aren't offering warranties either.
Whatever we do, we should not be changing the existing license we should be prepending/appending to it in a manner that doesn't change the essential character of the license. If possible, I'd like to use an actual, recognized named license that's compatible with what we have now, rather than one that's almost, but not quite one that we can just reference. (Either Python, MIT or BSD, whichever is closest.)
radarhere commentedon Dec 2, 2015
Just as a suggestion to try and get this rolling again, here's a suggestion, prepending some text to the license so that Pillow is covered by MIT -
radarhere commentedon Dec 30, 2015
As a relevant note, I just realised that the docs state
Like PIL, Pillow is licensed under the MIT-like open source PIL Software Licenseaclark4life commentedon Apr 1, 2016
@radarhere Still working on this? I guess we just need to explicitly state in the top level LICENSE that Pillow is licensed PSL (PIL Software License), if we haven't done so already.
radarhere commentedon Apr 1, 2016
Okay, I've created a PR for inspection.
[-]License[/-][+]Review license[/+]aclark4life commentedon Mar 22, 2019
Tidelift has asked us to review our license, particularly with regard to Libraries.io understanding of what our license is. My guess is that since GitHub thinks our license is "other", Libraries.io has no idea what to make of that, and is deciding "unknown".
We may need to ask them to configure Libraries.io to say "other" as well … at least then they'd match. @kszu ?
kszu commentedon Mar 22, 2019
That sounds right to me @aclark4life ! I'm going to cc Tidelift's cofounder / actual licensing lawyer @tieguy to confirm 👍
tieguy commentedon Mar 22, 2019
Yes, what's happening here is that (since our goal is to have high-quality license information everywhere, not just our tools) we're looking at the GH API. Most of the time, when the GH API chokes, it's because of poor formatting or legitimately complex license situations. This is the first time I've seen in a while where it is choking because of a rare license.
It looks like it has also uncovered a bug in libraries.io (which for some reason thinks the license is the Barr license, which I admit I hadn't heard of until today). So that's two for the price of one :)
At any rate, I don't think there is much for y'all to do here - your license situation is just complex/rare, and so we're going to have to change the status in our database for now. Thanks for helping us learn :)
Also, if no one objects, I'm going to submit the license to SPDX (a standards group that tracks licenses) so that SPDX-based tools can recognize and track PIL/Pillow.
tieguy commentedon Mar 25, 2019
Good news: Turns out that this is an obscure, but already documented, license: https://spdx.org/licenses/HPND.html
Bad news: pypa does not currently allow HPND as a license identifier. (The current list is discussed here.) We'll update it at Tidelift, and hopefully pypa and GitHub will recognize it at some point.
aclark4life commentedon Mar 25, 2019
@tieguy Thanks!
But can you also please explain how the "Standard PIL License" and https://spdx.org/licenses/HPND.html are related? I'm assuming you're classifying the Standard PIL license as an HPND license, but not 100% sure about that. And if you are, I wanted to confirm that classification is accurate.As such I'll note further, in case it helps, that we've never discussed licensing with Fredrik Lundh (remember this is a fork of his software licensed with the Standard PIL license) and our collective goal, historically, has always been to make as few changes as possible to PIL, including maintaining the same license.It just so happens that at some point we had to give up on "making as few changes as possible" … and now that this licensing issue is coming up again I'm wondering if should consider any licensing changes. For example …Hah! Never mind.
After I wrote all that I came across:
which, in referencing the Standard PIL license, states
so now I just answered my own question. 🎉
tieguy commentedon Mar 26, 2019
I think you figured it out! but to be 100% clear, just in case: we are not asking you to make a change to your license! We would only ask for that if it were completely, certainly cosmetic, and would make a significant difference for automated scanners. That's not the case here (at least, no such suggetion that I see right now) so no request to change anything.
Since the license text is almost exactly the text of the HPND, we'll note that in our database - will help some of our customers automate their license compliance. Thanks!
(A quick scan also suggests there's a bunch of other licenses in various places, like LGPL in ImageCms.py - but we aren't going that deep yet.)
hugovk commentedon Mar 26, 2019
I've requested HPND is added as a Trove classifier: pypi/warehouse#5627.
For the longer term, do we want to supersede HPND with, say, BSD or MIT? Wikipedia suggests:
How to proceed?
tieguy commentedon Mar 26, 2019
If you were starting a new project, or a rewrite, I'd recommend a newer license, like BSD-2-clause+Patent.
But since you've got all this old code contributed by people who are no longer with the project, you're pretty much stuck with the existing license - you can't simply make it go away. So not much upside in switching for new contributions; then people just have to comply with two licenses.
One possible exception: if you've got plugins or other clearly separable code that is often written from scratch and lives separately, you might require a more modern license for that code?
hugovk commentedon Mar 26, 2019
Not really. The different image formats are supported as plugins, but it all lives together with the main code at https://github.com/python-pillow/Pillow/tree/master/src/PIL.
See #3752 to update the Trove classifier in
setup.pyto use the new HPND on PyPI.tieguy commentedon Mar 27, 2019
Do you know of anyone forking/reusing those plugins? If so, might be nice for new ones to be consistently under a more modern license. But realistically if they're only useful with PIL then not much upside to clarifying things.
aclark4life commentedon Mar 28, 2019
@tieguy We'd have no way of knowing because they're in this repository … https://github.com/python-pillow/Pillow/tree/master/src/PIL. Also, looks like HPND got merged so I'm closing this again. pypi/warehouse#5627 Thanks all!