New license request: Python-3.something and maybe others

[ockham]

Some Python-related projects (such as https://github.com/nodeca/argparse) use a license that they refer to as Python-2.0 in their package.json's (SPDX compliant) license field.

However, that license isn't identical to what SPDX lists as Python-2.0 license. Specifically, SPDX has the following:

7. This License Agreement shall be governed by and interpreted in all respects by the law of the State of Virginia, [...]

That part is found in the "CNRI OPEN SOURCE LICENSE AGREEMENT (for Python 1.6b1)" section. (I'm not even sure if that part is legally binding or just there for historic purposes.) Anyway, I think that that part is what is mentioned by the GNU project's license list as the reason for that license being GPL-incompatible:

This is a free software license but is incompatible with the GNU GPL. The primary incompatibility is that this Python license is governed by the laws of the State of Virginia, in the USA, and the GPL does not permit this.

Anyway, argparse's LICENSE has the following instead:

7. This License Agreement shall be governed by the federal
   intellectual property law of the United States, including without
   limitation the federal copyright law, and, to the extent such
   U.S. federal law does not apply, by the law of the Commonwealth of
   Virginia, excluding Virginia's conflict of law provisions. [...]

Note that this is identical to what the GNU Project calls the Python-2.0.1 license (which unfortunately currently isn't an SPDX-listed license), and lists as GPL-compatible.

The latter license is also found on the Python website (which should probably be considered the canonical source): https://www.python.org/download/releases/2.0.1/license/

Would you consider adding the Python-2.0.1 license? The apparent difference in GPL compatibility seems relevant enough for (FL)OSS projects -- this is basically what prompted me to file this issue 🙂

---

Based on my findings at WordPress/gutenberg#28890 (comment)).
Also discussed at nodeca/argparse#160.

[capfei]

I have been looking into the differences in what SPDX and OSI have listed for the Python 2.0 license and wondering if wouldn't make more sense to update Python-2.0 to what is listed on the Python site? The license in the nodeca/argparse repo is the same as the one in the Python repo, excluding the 0BSD license for docs.

https://github.com/python/cpython/blob/master/LICENSE

[capfei]

I tried to find out if anyone on the OSI license discussion list knew where the version that OSI and SPDX comes from, because I have never seen it used, and no one who responded knew. When I looked back in the Python repo history, I couldn't find it. All of the python projects I come across, use the Python license, as it was written out, at least, until 3.8.5.
https://github.com/python/cpython/blob/v3.8.5/LICENSE

[ariel11]

@jlovejoy - would you recommend we open a new issue suggesting the SPDX "Python-2.0" be updated to this version of the license - e.g. https://github.com/python/cpython/blob/v3.8.5/LICENSE or https://www.nuget.org/packages/python/3.7.5/License? The only difference between those two license examples is one has "2020" included in the list of copyright dates.

@capfei - FYI

[ockham]

Thanks @capfei and @ariel11!

I've found a potentially somewhat related past discussion where it was suggested to drop the license's history from it. IIUC, people were opposed to changing an established SPDX license, and opted to create the PSF-2.0 license instead (#952). (Personally, I haven't seen any projects that actually use this -- much shorter -- version, so it doesn't seem that practical to me, but please consider this very anecdotal evidence.)

Just mentioning this here in case it's relevant.

[swinslow]

Discussed in detail on 2021-06-10 legal team call, regarding some significant differences in the different versions that have been used over the years, including:

Current version from website: https://docs.python.org/3/license.html

Current version from cpython repo: https://github.com/python/cpython/blob/main/LICENSE

2001 version from cpython repo: https://github.com/python/cpython/blob/71500c8293a6862894cd657b8e41bbb43db6680d/LICENSE

@ariel11 and @capfei to add some more details here, for discussion on next legal team call re: whether / what new entries to add.

[capfei]

I tried finding the source of the license via the OSI license discussion group, but those that responded weren't sure either: https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2021-February/021916.html.

[ariel11]

Per @swinslow's comment above, adding some examples of components in the wild that use a license very close to the "Python-2.0" SPDX, but is not a match.

Example 1

1. Component - https://www.nuget.org/packages/IronPython.StdLib/2.7.8.1
2. License - https://docs.python.org/3/license.html
3. Analysis – Ran a Word "Compare" between above license and the SPDX license text for "Python-2.0."

The CNRI portion of the above license.html does not match that section of the “Python-2.0” SPDX. Interestingly, it does match the “CNRI-Python-GPL-Compatible” SPDX text, however it does not have the click-accept language shown on the “CNRI-Python-GPL-Compatible” SPDX.

Besides the CNRI section noted above, the other differences between this license.html example and the “Python-2.0” license are as follows:
(1) Title of first section is different (this is in colored font, but should perhaps be red instead of blue, meaning it is replaceable (with a different title) and not just omittable).
(2) Also, in that first section, instead of “Python,” throughout it uses “Python 3.9.5.”
(3) Also, in that first section, the copyright dates are different in clause 2.
(4) The CNRI title is different (this is in colored font, but should perhaps be red instead of blue, meaning it is replaceable and not just omittable).
(5) The CNRI click-accept language is not included, which is OK per the blue colored font.
(6) There’s an additional “ZERO-CLAUSE BSD LICENSE FOR CODE IN THE PYTHON 3.9.5 DOCUMENTATION” license section at the end.

[ariel11]

Example 2

1. Component - https://pypi.org/project/distlib/0.3.2/
2. License - https://bitbucket.org/pypa/distlib/src/master/LICENSE.txt
3. Analysis – Ran a Word "Compare" between above license and the SPDX license text for "Python-2.0."

(1) The dates in PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2, Section 2 are different. The bitbucket version has "2007, 2008, 2009, 2010" added.
(2) The CNRI section is titled “CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1” (which is different from "Python-2.0" text) and it again matches the “CNRI-Python-GPL-Compatible” SPDX text, however it does not have the click-accept language. Unclear where the CNRI portion of “Python-2.0” is coming from or where it is used.

[ariel11]

Example 3

1. Component - https://www.nuget.org/packages/python
2. License - https://www.nuget.org/packages/python/3.9.5/License
3. Analysis – Ran a Word "Compare" between above license and the SPDX license text for "Python-2.0."

(1) The dates in PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2, Section 2 are different. The bitbucket version has “2007, 2008, 2009, 2010,….2021” added.
(2) The CNRI section is titled “CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1” and again matches the “CNRI-Python-GPL-Compatible” SPDX text, however it does not have the click-accept language. Unclear where the CNRI portion of “Python-2.0” is coming from or where it is used.
(3) There’s an additional “ZERO-CLAUSE BSD LICENSE FOR CODE IN THE PYTHON DOCUMENTATION” license section at the end.

[ariel11]

To summarize the three examples above - the consistent differences between the SPDX "Python-2.0" and the licenses used in the wild are as follows:

1. The dates in PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2, Section 2 are different.
2. The CNRI section is different - uses the text from the "CNRI-Python-GPL-Compatible” SPDX without the click-accept language.
3. The name "Python" is "Python 3.9.5" in Example 1.
4. There is sometimes an additional ZERO-CLAUSE section, as specified above.

Cc: @capfei for visibility

[jlovejoy]

discussed research @ariel11 did on June 24 call: decision to add as stack similar to what we did for Python-2.0 as it appears on https://docs.python.org/3/license.html

However, question around this language on that page:
"Starting with Python 3.8.6, examples, recipes, and other code in the documentation are dual licensed under the PSF License Agreement and the Zero-Clause BSD license."

In examples above (and seemingly consistent) with this language, sometimes 0BSD is included and sometimes not.

@VanL - are you still involved with Python Foundation? Does "dual licensed under the PSF License Agreement and the Zero-Clause BSD license." mean the examples, recipes, and other code in documentation are licensed under both(and) licenses or a choice (or)?

If the latter, then we would add as two different licenses (one with 0BSD and one without 0BSD).

[jlovejoy]

@VanL - can you answer the above question or maybe let us know who might be able to?

[brettcannon]

I reached out to @VanL and he said:

Generally that sort of dual license is considered disjunctive. A person can decide to "take" under one of the licenses or the other. It also doesn't have to be consistent. You can take under BSD for one project and under PSF for another.
For licenses that are as similar as the PSF and BSD (in terms of requirements, not text) you can just include the text of both licenses and defer the decision and effectively take under both.

[swinslow]

A bit more research on this, and possibly duplicating what folks have already found. Using Google cache URLs in a few places below as the original URLs are throwing 503 errors at the moment.

Regarding the Python "license stack's" use of CNRI-Python (shorter section 7) vs. CNRI-Python-GPL-Compatible (longer section 7):

• It looks like Python release 1.6 first added CNRI-Python to the mix: see FAQ and release page, with original license text from the "view license" link on the release page.
• For Python release 1.6.1, it looks like they replaced CNRI-Python with CNRI-Python-GPL-Compatible: see release page and original license text for 1.6.1.

So if that's correct, the text on the license list for Python-2.0 -- I'm guessing originating from the OSI page for Python-2.0 -- was actually never used for Python release 2.0. Sigh.

I don't think we can replace the text of Python-2.0, or add this changed version of the CNRI portion as "optional" text for Python-2.0, since it certainly appears to have a different substantive legal effect if it's present vs. absent.

I think all that points in the direction of:

• adding one (or more) new Python-* and/or PSF-* license IDs
• adding clarifying text to the Notes sections of those new IDs and also Python-2.0
• (perhaps?) deprecating Python-2.0 as an identifier -- leaving it on the list as a valid identifier, but moving it down to the "deprecated" section so that it's less prominent?

"More discussion is warranted" I fear...

[brettcannon]

• It looks like Python release 1.6 first added CNRI-Python to the mix

Correct. The Python 1.6.0 release was actually specifically for the license update.

• For Python release 1.6.1, it looks like they replaced CNRI-Python with CNRI-Python-GPL-Compatible

Quite possible. There was disagreement with GNU about GPL compatibility at one point.

• adding one (or more) new Python-* and/or PSF-* license IDs

If you need to choose a prefix, I would suggest "PSF" since that's what the license is known by in the Python community and as official of a name as it has: https://github.com/python/cpython/blob/4dc746310bd37ad6b381f9176acd167d445f4385/LICENSE#L62-L63 .

[jlovejoy]

Hi all - thanks to everyone above for all the research and sorry this got procrastinated, I've cleared the "waiting for steward" label which wasn't helping!

I've created a PR to add the Python-2.0.1 license with some markup that should then match to the various examples cited above. See #1549 for more info

Also added an updated note for Python-2.0

[swinslow]

With #1549 merged to add Python-2.0.1 as of the 3.18 release (upcoming shortly), I believe we can close this. If there are additional edits or changes needed for Python-2.0.1 or additional licenses to handle other cases, please open a separate issue. Thanks all!