[Docs] PyPI Meta tags no longer include license

[WilliamRoyNelson]

Summary

PyPI normally shows a package's license in the Meta tags. This is important for automated tools used in enterprise environments that ensure that only licensed packages are used, and for users to be able to easily determine if a package has a open-source license. The current PyPI page has no indication that setuptools has an open source license.

Before change to license classifiers:

Now it doesn't:

OS / Environment

No response

Additional Information

78.1.0 shows license: https://pypi.org/project/setuptools/78.1.0/
78.1.1 does not: https://pypi.org/project/setuptools/78.1.1/

Code of Conduct

• I agree to follow the PSF Code of Conduct

[nykh]

Can confirm, liccheck reads it as

setuptools (79.0.0): UNKNOWN

[WilliamRoyNelson]

It looks like it's related to this:
jaraco/skeleton#170

But it seems like the change occurred with this commit:
4e1e893

There was a PR to fully review this: #4901
But I don't think the correct SPDX license expression was figured out before it got merged.

Maybe this should be reverted until the license gets figured out?
#4901 (comment)

[WilliamRoyNelson]

I created a PR to temporarily resolve this problem until a perfect PEP 639 license declaration can be formulated.
#4957

[wagenrace]

This seems related to license_scanner issues 26
I looked into the Metadata of the setup package there is only License-File: LICENSE but no License-Expression, License, or Classifier: License :: to be found

I think @WilliamRoyNelson PR will fix it

[WilliamRoyNelson]

This issue is present in the latest release 79.0.1

[WilliamRoyNelson]

This issue is present in the latest release 80.0.0

[abravalheri]

There is an open discussion regarding the difficulties of deriving an accurate composite license expression in the discourse thread starting on https://discuss.python.org/t/pep-639-round-3-improving-license-clarity-with-better-package-metadata/53020/196.

It is a non trivial problem that other projects are also facing.

For the time being, while a comprehensive solution is not formulated, please read the canonical source of license information, i.e. license files distributed within the archive, for accurate, complete, and up-to-date information on the licensing model.

[WilliamRoyNelson]

There is an open discussion regarding the difficulties of deriving an accurate composite license expression in the discourse thread starting on https://discuss.python.org/t/pep-639-round-3-improving-license-clarity-with-better-package-metadata/53020/196.

I really appreciate that link, I think I have a much better understanding of the underlying problem.
I completely understand what you mean about it being a non-trivial problem. One of my first thoughts was "Maybe it'd be easier to go through each vendored component and see if we can get their maintainers to relicense under MIT." If that seems like the "easy" option, then maybe creating a correct SPDX license classifier is too hard.

[WilliamRoyNelson]

This issue is present in the latest release 80.1.0