State clearly how a license should be declared

[bittner]

The Declaring project metadata section of the Python Packaging User Guide mentions several ways to declare a license for one's application source code. This is a bit confusing.

1. Via the license field's file attribute (and an extra file, obviously). :heavy_check_mark:
2. Via the license field's text attribute. Experienced Open Source developers will assume this is a SPDX license identifier, but others may want to enter a full text (i.e. the content of a license file). :exclamation: :bomb:
3. In the classifiers field via a license classifier. While not explicitly show-cased in the (example of the) guide it's possible to add a trove classifier that declares the license (which is likely used mainly to filter on PyPI). I recall this to have been favored (somewhere) in the past. Neither the page in question nor the Core metadata specifications section encourage or discourage the use of such a classifier, or state whether it's good or bad practice to add this in addition or not at all. :question: :confused:

It would be helpful, for experienced maintainers and novices alike, to clarify which style is preferred and valid.

EDIT: I found PEP 639, which seems to address the problems mentioned above.

[Julian]

Note that the pyproject.toml license page indeed contains clear guidance on this, and says to do option 3 (which is perhaps the spot you were remembering).

But I'm finding this issue before filing a related one, which is that option 3 runs afoul of pypa/pip#6677.

It might be the decision is still "do nothing until PEP 639 is merged", but just noting the cross-reference for anyone finding this -- and it does seem like it'd be slightly nice to either remove the recommendation for now, or else less drastically to add a footnote saying "if you follow this advice note that pip show will not detect the license correctly", given that PEP 639 is not yet accepted / that issue is waiting on it being accepted before work to change pip even starts.

[webknjaz]

FTR there was a talk at EuroPython 2024 on this PEP. There's a bunch of new people leading the effort to get the PEP out of the draft.

cc @befeleme ^

[befeleme]

The PEP has been provisionally accepted, so it's time to move this forward. I'll work on updates next week.