Hmm... what's better, being flagged as GPL-incompatible, or being flagged as non OSI-approved?

We could make "PSF-2.0 OR Python-2.0"

from argparse.

Python-2.0. That's version of LICENSE, not of python.

See previous issues.

from argparse.

Apologies, I should have been clearer. I opened a new issue because I wanted to explicitly talk about the mismatch between the SPDX identifier in the package.json and the actual LICENCE file.

There's 2 different licenses:

• https://spdx.org/licenses/Python-2.0.html
• https://spdx.org/licenses/PSF-2.0.html

The one you're using for this project in the package.json license file is Python-2.0. That's the license that was used for just 2 versions of python - python 1.6 and python 2.0

The one in your LICENSE file is the PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2 license (PSF-2.0). That's the license that was used for python 1.6.1 and 2.0.1, and every version since (the change was made because Python-2.0 is not GPL compatible).

To be clear, I have no problem with either license - please choose whichever you want, but your package.json and LICENSE files should probably match.

Thanks,
Tom

from argparse.

Ah sorry, I've looked a bit closer, and I've made an incorrect assumption. You are using the Python-2.0 license text - it's just a combination of the PSF-2.0 license, and all the historic ones as well.

Sorry for wasting your time on this.

from argparse.

Ah sorry, I've looked a bit closer, and I've made an incorrect assumption. You are using the Python-2.0 license text - it's just a combination of the PSF-2.0 license, and all the historic ones as well.

Yes, Python's licence is very confusing, and causes repeating issues in tracker. If you have ideas how to improve situation - let me know.

from argparse.

It's even worse because wikipedia gets it wrong! https://en.wikipedia.org/wiki/Python_License

The Python License is a deprecated computer software license created by the Corporation for National Research Initiatives (CNRI). It was used for versions 1.6 and 2.0 of the Python programming language, both released in the year 2000.

SPDX identifier | Python-2.0

The only thing I can think of is releasing this code explicitly under the PSF-2.0 license. As the argparse module came in quite late (from the look of it 2.7 & 3.2), the whole codebase should have been under the PSF-2.0 license at that point, and not one of the older ones, so I can't see why using that rather than the Python-2.0 overall combination license would be a problem. Also reading the LICENSE it does say

B. TERMS AND CONDITIONS FOR ACCESSING OR OTHERWISE USING PYTHON

Python software and documentation are licensed under the
Python Software Foundation License Version 2.

(That would presumably also have the benefit of meaning this module wouldn't be flagged up as GPL incompatible, which seemed to be one of the other issues in the tracker.)

from argparse.

Just in case it's helpful, I also found https://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq#How_do_I_use_the_PSF_License.3F

It seems to explicitly suggest you shouldn't use the PSF-2.0 for projects that aren't python itself:

The PSF license was developed specifically and only for Python and its standard libraries. If you want to license your code for contribution to the PSF, do not use the PSF license; instead see below.

And definitely shouldn't use the full text including the history:

When using the PSF License with your project, you should never include the other parts of the Python license stack, such as the CNRI license or Guido's biography. Python has that history, but your code does not!

from argparse.

The only thing I can think of is releasing this code explicitly under the PSF-2.0 license.

The issue with that is: PSF-2.0 isn't marked as FSF or OSI-approved (see https://spdx.org/licenses/ or https://opensource.org/licenses/alphabetical), while Python-2.0 is (yes, it is probably because PSF just isn't used very much so they didn't bother).

Because of that, various licence checkers may allow Python-2.0, but warn people about PSF-2.0. Giving us more issue tickets.

(That would presumably also have the benefit of meaning this module wouldn't be flagged up as GPL incompatible, which seemed to be one of the other issues in the tracker.)

Hmm... what's better, being flagged as GPL-incompatible, or being flagged as non OSI-approved?

from argparse.

I've been thinking about it some more based on the PSF license FAQ (https://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq#How_do_I_use_the_PSF_License.3F)

The PSF explicitly say you probably shouldn't use either the Python-2.0 or PSF-2.0 license for any code that isn't python or it's standard library, and if you do still decide, you need to change a bunch of bits in the text.

So from that the only thing I can think of is to suggest going for a different license completely. That FAQ recommends Apache-2.0 for stuff that would potentially be included in python itself.

As this project is a "derivative work" AFAICT, I guess you'd have to honour:

3. In the event Licensee prepares a derivative work that is based on or incorporates Python or any part thereof, and wants to make the derivative work available to others as provided herein, then Licensee hereby agrees to include in any such work a brief summary of the changes made to Python.

From a quick search, one suggestion seems to be to use a NOTICE file to include the base work license: https://softwareengineering.stackexchange.com/questions/201843/open-source-licensing-of-derived-works#201848 (this also seem to be what the Apache-2.0 license talks about under 4.d)

(Obviously I'm not a lawyer, etc etc)

from argparse.

https://github.com/nodeca/argparse/blob/master/package.json#L17 we need to fill something simple & clean here for automated processing.

Anyway, if anyone decide to investigate topic and provide final & trusted recommendation (without "i'm not a lawer" note) - i'll be happy to make update.

from argparse.

The more I look into this, the worse it gets.

From PSF-2.0 p2 you have

... provided, however, that PSF's
License Agreement and PSF's notice of copyright, i.e., "Copyright (c)
2001, 2002, 2003, 2004 Python Software Foundation; All Rights Reserved"
are retained in Python alone or in any derivative version prepared
by Licensee.

Which would suggest you need a verbatim copy (as you currently have).

But perfect examples of derivative works of python would be the pypy and ironpython projects, (MIT & Apache respectively), both of which are recognised by the PSF. pypy mentions the PSF license in its license file (https://foss.heptapod.net/pypy/pypy/-/blob/branch/default/LICENSE), ironpython2 doesn't mention it at all (https://github.com/IronLanguages/ironpython2/blob/master/LICENSE), and ironpython3 doesn't mention it in their license, but has a verbatim copy (but only in https://github.com/IronLanguages/ironpython3/blob/master/Src/StdLib/StdLib.License.txt). The horrible bit here is that AFAIK ironpython is microsoft, and you'd think their lawyers would be all over this, and yet they're inconsistent between the ironpython2 & 3 repos!

When I get a chance, I'll ask our legal team at work about this, but no guarantees they'll bother investigating properly.

Sorry everyone for opening such a can of worms!

from argparse.

@TjlHope , @puzrin , could you check #173?

from argparse.