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.