Update license field to Python-2.0.1

[fabio-porcedda]

Hi,
while preparing a new package for Fedora that use argparse as dependency I found that the Python-2.0 is not allowed in Fedora.

Fortunately the real license is the SPDX Python-2.0.1 so update the license field to reflect that.

In the past only the Python-2.0 was available in SPDX but later the Python-2.0.1 was added, so use it.

[puzrin]

Maybe worth changing to PSF-2.0 (with license text) then?

There is a long story of issues about the license. I just wish for proper attribution "from upstream" and for this question to be solved once and for all. Without diving into details.

The only difference, PSF-2.0 & Python 2.0.1 have no flag "OSI approved". I don't know how critical that is.

Can you give a qualified answer about attribution for this package? Or maybe you know someone who can help? I'm not a lawyer :)

[fabio-porcedda]

Assuming that the LICENSE file in the latest release is the correct one, the most appropriate SPDX license should be Ptyhon-2.0.1 because it includes:

• PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2
• BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0
• CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1
• CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2

Instead, if you also want to change the LICENSE file, I don't know what the best one is. For sure the PSF-2.0 is the simpler one. I don't know of any downside to not being OSI approved.

From my point of view as Fedora packager both the PSF-2.0 and Python-2.0.1 are fine, they are both allowed in Fedora:
https://docs.fedoraproject.org/en-US/legal/allowed-licenses/

I'm neither a lawyer nor an expert on licenses.

[puzrin]

Don't consider LICENSE a requirement; it's part of attribution and can be modified at your discretion. As far as I understand:

• Python-2.0
  • Not suitable, because not GPL-compatible.
  • Has a very confusing LICENSE.
• Possible choices are:
  • PSF-2.0
  • Python-2.0.1 (GPL-compatible, but still confusing LICENSE).
  • Both alternatives have no OSI-approved flag in SPDX (that's a fact, not a reason to decline).

Additional context:

• This package is written by @rlidwka and me. We can change the license as we need, without a complicated process.
• Only upstream demands should be satisfied. No extra demands from our side.

I tend to update to PSF-2.0, but need to understand any possible side effects (I hope there are none) - scanner errors and so on.

---

If you know where to ask for audit - let me know.

[fabio-porcedda]

To get a qualified opinion, you could try asking to help@softwarefreedom.org, on https://softwarefreedom.org/ is written:

The Software Freedom Law Center provides pro-bono legal services to developers of Free, Libre, and Open Source Software.

Also you could try to asking to licence-questions@fsfe.org on https://fsfe.org/freesoftware/legal/faq.en.html is written:

If your question is not covered here or in any of our other resources, you can consider asking our Licence Questions team by sending them an email at licence-questions@fsfe.org.

[richardfontana]

Hi, while preparing a new package for Fedora that use argparse as dependency I found that the Python-2.0 is not allowed in Fedora.

Actually, it probably would be, but hasn't been formally reviewed, since it was discovered (when Fedora switched to using SPDX identifiers) that Python-2.0 wasn't actually used in any known release (or at least any known release in the past couple of decades) of CPython.

But apparently the license in this repository is Python-2.0.1, not Python-2.0.

[richardfontana]

To get a qualified opinion, you could try asking to help@softwarefreedom.org, on https://softwarefreedom.org/ is written:

The Software Freedom Law Center provides pro-bono legal services to developers of Free, Libre, and Open Source Software.

I don't think SFLC (a former employer of mine) is actively providing legal services anymore.

[richardfontana]

Maybe worth changing to PSF-2.0 (with license text) then?

There is a long story of issues about the license. I just wish for proper attribution "from upstream" and for this question to be solved once and for all. Without diving into details.

The only difference, PSF-2.0 & Python 2.0.1 have no flag "OSI approved". I don't know how critical that is.

Can you give a qualified answer about attribution for this package? Or maybe you know someone who can help? I'm not a lawyer :)

I think the issue here is that if this is a port of Python argparse, it may be covered in part by the relevant CPython license. On the Fedora legal list @puzrin says:

argparse was added to CPython in 2010 under the PSF Contributor Agreement, so none of
the ported code comes from the CWI, CNRI or BeOpen eras.

Can the port be licensed as PSF-2.0 alone, or does CPython-derived code have to carry
the whole stack?

If indeed none of the ported code comes from the CWI/CNRI/BeOpen areas there wouldn't seem to be any basis for anyone to insist on PSF-2.0 not being an adequate license by itself.

[puzrin]

@richardfontana

But apparently the license in this repository is Python-2.0.1, not Python-2.0.

No, we really attributed it as Python-2.0 from SPDX because it's the only one with the OSI-approved flag in SPDX. Also, Python-2.0.1 may not have existed in the SPDX database at the time.

Probably, this was a mistake - I'm not an expert in this area. I'd like to solve a practical issue:

• Finally, stop the issues in the tracker :) Because of the cryptic Python-2.0 license text.
• Avoid alerts in license scanners about incompatible licenses (don't know if the OSI-approved flag is significant or if existing in SPDX is enough).

From my unqualified point of view, PSF-2.0 is the clearest, in case we should adjust Python-2.0 to something else. But I don't know if it's correct to use it.

[richardfontana]

Seems like PSF-2.0 would be okay based on what I'm reading here. If I remember correctly, the PSF had intended to submit PSF-2.0 (i.e. standalone from the license that was submitted as Python-2.0 though that should have had the text of what later came to be labeled Python-2.0.1) for OSI approval but for some process related reason that never happened. The fact that PSF-2.0 by itself is not OSI-approved might matter to some but I wouldn't expect most people to care - if only because PSF-2.0 clearly contains no OSI-approval problem since it was approved as part of the stack of licenses in the (mistaken) Python-2.0 submission.

[nicorikken]

I came here with a similar license compliance finding. How about we also request license reviews by OSI to remove the distinction of one license being OSI approved and the other not. Personally I think the OSI approval is hardly a condition for choosing the license, as the most important criteria is the legal compatibility with the licenses of source material.

[nicorikken]

Both PSF-2.0 and Python-2.0.1 are considered free software licenses by FSF, so I filed an issue to get it registered as such on SPDX website: spdx/license-list-XML#3073
I also asked OSI for a review to mark the licenses as open source https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2026-August/006157.html Turns out this was already in progress: https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2026-March/006060.html

[nicorikken]

Looking at the lineage of argparse:

• It was introduced as a new module in the standard library in Python 2.7: https://docs.python.org/2.7/library/argparse.html
• Work for introductions started on 2010-03-02 based on the separate Python package Argparse version 1.1: python/cpython@e9330e7
• The previous Apache-2.0 license was removed as part of the merging process: python/cpython@fb224e3
• Argparse 1.1 was licensed Apache-2.0 at the time https://pypi.org/project/argparse/1.1/ but had a single author statement, so the license could be changed easily. The source code distribution reads # Copyright © 2006-2009 Steven J. Bethard <steven.bethard@gmail.com>.
• Earlier versions of Argparse had a BSD-3-Clause license.

I conclude:

• I wasn't able to find an explicit license statement for the inclusion of Argparse.
• Copyright belonged only to Steven J. Bethard before inclusion, so it was easy to choose a different license.
• It seems to have been licensed implicitly, so it has to either be the then used license for the entire Python codebase Python-2.0.1 or the most current used license that was marked for the latest changes PSF-2.0.

Personally I'd suggest to use the most recent license used by Python PSF-2.0 which is also used standalone by other projects. This also avoids carrying over the legacy of Python licenses into this project.

I consider PSF-2.0 approved by FSF as it is implicit in Python-2.0.1, but documentation could be better. Both Python-2.0.1. and PSF-2.0 should be approved by OSI given the acceptance by FSF and projects like Debian and Fedora. This process got started.

You might even considering to ask the Python Software Foundation or Steven J. Bethard @bethard.

Feel free to use any of these links to document the license choice, to have a answer ready in the future in case questions come up.