Update license identifier to MIT-CMU

[capfei]

The license states HPND and I saw a PR from last year to get that text to match closer to what is listed on SPDX. However, I see that the Pillow license text actually matches what SPDX calls MIT-CMU (https://spdx.org/licenses/MIT-CMU.html) because of the additional text that is not included in HPND:

By obtaining, using, and/or copying this software and/or its associated documentation, you agree that you have read, understood, and will comply with the following terms and conditions:

For clarity, would it make sense to change Like PIL, Pillow is licensed under the open source HPND License to be MIT-CMU or maybe add the SPDX identifier to the license? SPDX Identifier: MIT-CMU

[aclark4life]

@capfei Thank you for raising this issue! I'm not sure if that adds any clarity… please see: #1507 which references the origin of that discrepancy https://web.archive.org/web/20190323004036/https://effbot.org/zone/copyright.htm. Also let's ask @tieguy to comment. In an already-confusing-environment, it may be "more clear" to retain the historical HPND license.

[hugovk]

The PIL licence is closer to MIT-CMU than HPND.

PIL vs. HPND:

PIL vs. MIT-CMU:

[tieguy]

Yeah, I validated this now with an automated tool (eyeballed it when we did this yearrrrrs ago) and it indeed more correctly labeled as MIT-CMU. Sorry for the extra work, @aclark4life !

[aclark4life]

Yeah, I validated this now with an automated tool (eyeballed it when we did this yearrrrrs ago) and it indeed more correctly labeled as MIT-CMU. Sorry for the extra work, @aclark4life !

No trouble at all, but just so I understand:

• The "Standard PIL License" is actually MIT-CMU
• We thought the "Standard PIL License" was HPND but that was a mistake so now we should fix that mistake by change all of our references to "Standard PIL License" or HPND to MIT-CMU

At least that's my current understanding. Either way, the answer to questions like this one are still the same: comply with the terms of the license! I mean this is pretty clear whatever you call it:

By obtaining, using, and/or copying this software and/or its associated documentation, you agree that you have read, understood, and will comply with the following terms and conditions:

Permission to use, copy, modify, and distribute this software and its associated documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appears in all copies, and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of the copyright holder not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission.

THE COPYRIGHT HOLDER DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM THE LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

[hugovk]

Yes, let's update HPND -> MIT-CMU.

However, there is no Trove classifier for MIT-CMU:

https://pypi.org/classifiers/

We can request a new classifier by opening an issue:

https://pypi.org/help/#new-classifier

However, most of the others, like MIT and HPND, have "OSI Approved" in the classifier and can be found on the OSI website, but I don't see MIT-CMU:

https://opensource.org/license?ls=CMU

Approval is consensus-based via a mailing list and takes 60 days:

https://opensource.org/licenses/review-process

They also have another list to ask advice before proposing. I expect MIT-CMU should be fine as a legacy licence and due to its similarity to HPND?

@aclark4life Would you like to take care of this, check the criteria are met, and draft something up?

It's 77 days until the next release, a bit tight but not impossible!

TODO:

• [x] Request OSI approval for MIT-CMU via license review mailing list
• [x] When OSI list reaches consensus, wait for OSI board vote
• [ ] When OSI board votes in favour, request MIT-CMU Trove classifier
• [ ] When Trove classifier created, update Pillow source

[hugovk]

Any news?

We're three weeks away from 10.4.0, should we retarget for 11.0.0 in October?

[aclark4life]

Sorry, got distracted. Yes let's re-target for November during which time I also hope to have something for #1888.

[aclark4life]

OK joined the list and sent this email, however I don't see it here yet: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2024-June/thread.html. Should be there within 24 hours I imagine or something is probably wrong (I did confirm, and send after confirmation.)

[aclark4life]

First response: 👍 http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2024-June/005486.html

[aclark4life]

Approval is granted by the board, not mailing list consensus. Trying to figure out if I've made a request to the board to review through mailing list.

[hugovk]

Ah right, so re-reading https://opensource.org/licenses/review-process my understanding is the request is submitted for review to License-review mailing list. "Decision Day" is 60 days later.

The License Committee observes the discussion to determine if there's consensus on approving or rejecting.

If there's consensus, the License Committee Chair makes a recommendation to the OSI board, who will then vote on whether to adopt the committee recommendation and update the website.

So we need to wait for both of these before opening the Trove classifier PR.

The request was sent on 14th June, 60 days later is 13th August, so we're not yet halfway through until Decision Day. Let's wait until then. I've updated to the checklist above to add an extra step.

[hugovk]

Good timing:

To be slightly more accurate, it should be voted on at the next Board meeting that is more than 60 days after the date the license was submitted https://opensource.org/licenses/review-process, that is, the next Board meeting after August 13, 2024. Currently there is a Board meeting scheduled for August 16, 2024, so that should be when the Board will vote on it.

Pam

Pamela S. Chestek Chair, License Committee Open Source Initiative

https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2024-July/005503.html

[radarhere]

We have now passed August 16, 2024.

[hugovk]

Any news from the OSI board meeting?

[aclark4life]

Assuming they post the news on the list, none that I have heard. 🤷 I don't keep my old emails around anymore and RIP GMANE … but I could start a new thread asking about the results if need be. Also wondering if there are public board notes somewhere.

[hugovk]

The last board meeting minutes posted at https://opensource.org/minutes is from 2024-07-19.

Since this issue was opened, a third attempt was started on the five-year old PEP 639 – Improving License Clarity with Better Package Metadata, and it has only just been provisionally accepted.

It will deprecate the License field and licence classifiers, and instead add a way to specify a SPDX licence expression and include licence texts.

There's already a SPDX expression for MIT-CMU: https://spdx.org/licenses/MIT-CMU.html

Work is underway to add PEP 639 support to PyPI and related tooling: https://github.com/pypi/warehouse/issues/16620

We could just wait for that work to finish, and use SPDX. Or as we seem close to having MIT-CMU approved to OSI, I think it's also worth sending a new message to the list to check on the status.

So, yes please, it'd be great if you could send a followup :)

[aclark4life]

The last board meeting minutes posted at https://opensource.org/minutes is from 2024-07-19.

So they met, reached a quorum, approved the previous meeting's minutes, then adjourned … ?

Since this issue was opened, a third attempt was started on the five-year old PEP 639 – Improving License Clarity with Better Package Metadata, and it has only just been provisionally accepted.

It will deprecate the License field and licence classifiers, and instead add a way to specify a SPDX licence expression and include licence texts.

There's already a SPDX expression for MIT-CMU: https://spdx.org/licenses/MIT-CMU.html

Work is underway to add PEP 639 support to PyPI and related tooling: pypi/warehouse#16620

Cool!

We could just wait for that work to finish, and use SPDX. Or as we seem close to having MIT-CMU approved to OSI, I think it's also worth sending a new message to the list to check on the status.

So, yes please, it'd be great if you could send a followup :)

OK will do … watch this space or https://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org

[hugovk]

The last board meeting minutes posted at https://opensource.org/minutes is from 2024-07-19.

So they met, reached a quorum, approved the previous meeting's minutes, then adjourned … ?

Yes: "allowing the Board the remainder of time to have a focused discussion on the Open Source AI Definition".

But regarding MIT-CMU, they either didn't hold the August meeting, or held it and haven't posted the minutes yet.

[aclark4life]

http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2024-September/005522.html

[radarhere]

We have now passed September 20. Nothing new at https://opensource.org/minutes yet.

[hugovk]

Although on 14th September, the License Committee's recommendation was posted, with an intention for a board vote on the 20th:

https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2024-September/005553.html