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). ✔️
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). ❗ 💣
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. ❓ 😕

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.

[webknjaz]

@befeleme I'll assign this to you, then, if you don't mind.

[zahlman]

I hope the PR for this can be merged soon. I'm implementing a simple build backend (https://github.com/zahlman/bbbb) and I intend to implement PEP 639 support (in part because my policy is to always produce core metadata to the newest available standard, and also to help make sure the PEP can move from provisional to full acceptance). When I issue deprecation warnings for the old style of license info, I'd like to be able to point at something better than the PEP itself. Thank you for your contributions @befeleme .

[webknjaz]

Those subscribed to this issue may want to lurk into #1662 and leave a review.