pythonx86 3.9.0-a4

[clearlydefinedbot]

Type: Missing

Summary:
pythonx86 3.9.0-a4

Details:
Add PSF-2.0 License

Resolution:
License Url:
https://docs.python.org/license.html

Description:
I am a core Python developer and work on this project.

Pull request generated by Microsoft tooling.

Affected definitions:

• pythonx86 3.9.0-a4

[clearlydefinedbot]

You can review the change introduced to the full definition at ClearlyDefined.

[zooba]

This is definitely the correct Python license, and I don't see why all the other entries in this file aren't the same.

[capfei]

@zooba The reason the other versions are OTHER is because the Python license that includes the multiples licenses in it has differences that make it not a match to what SPDX and OSI have listed for the Python-2.0 license.
https://spdx.org/licenses/Python-2.0.html

PSF-2.0 is only the Python 2.0 portion: https://spdx.org/licenses/PSF-2.0.html.

There is an open issue with SPDX to get the current license text used by Python an identifier. It is still weird for me to use OTHER for Python, but since we adhere to the SPDX matching guidelines, it is OTHER. The same for #17618; that will be updated to OTHER.

Discussion: spdx/license-list-XML#1200

[ariel11]

Agree that this license - https://www.nuget.org/packages/pythonx86/3.9.0-a4/License - does not have a matching SPDX identifier. There are ones that are close, like the SPDX "Python-2.0," however the differences between that SPDX license template and the above package license does not meet the SPDX matching guidelines. Therefore, like other licenses that do not have a matching SPDX identifier, the declared license is entered as "OTHER." ClearlyDefined uses SPDX identifiers or "OTHER" when there's not one available.

[zooba]

Eh, OTHER is fine enough by me. I just want the misdetection on my build to stop complaining - I'm not actually using the component.