Having though about it of the course of the weekend, after rereading the history of PEP and reading the new posts here, I’ve come to realize my previous statement was incorrect, I’ve got to retract and apologize for the confusion. PEP intended to clarify the distribution license. The difference between the project and the distribution isn’t as sharp as presented in some of the posts (Project being “A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a Distribution.”)
PEP cleanly covers the cases when project’s “core” code matches the sdist matches the wheels.
It attempts to cover the cases when project contains vendored dependencies (describing them in User scenarios and Advanced example - in my PEP editing times I wasn’t thinking there’s a case for storing the project “core” code license separately. As it now appears, that’s a material for a clarifying PEP (that could only tackle this specific group of projects). Another, admittedly hacky idea, would be to leverage parentheses to group all of the vendored libraries licenses – MIT AND (Python-2.0.1 AND Apache-2.0 AND BSD-2-Clause) retains semantics of MIT AND Python-2.0.1 AND Apache-2.0 AND BSD-2-Clause but looks differently for the human eye.
It doesn’t cover more complicated cases when the sdist and wheel licenses differ. That is left for a future PEP.
Projects may abstain from migrating to PEP 639.
Debating over what is the right (= factually correct) license of an artifact is out of scope of a Python technical standard. It’s a topic one step higher, over the whole software creation, and the idea of declaring bundled/linked libraries is a thing generally agreed upon (from the top of my head: SPDX standard, downstream repackagers like Fedora Linux).
As it’s clear to everyone in this debate, declaring the correct licenses of the particular artifacts when they differ, is a nontrivial task - and it’s out of scope of PEP 639. It also touches the issue of the UX of PyPI (and other indexes) which must be taken into account when designing more robust solution in the future.
I acknowledge for projects like pip it can be challenging to track the vendored dependencies, especially if they are often added/removed and I understand why it feels like a burden to have to revise them with each release (and reluctance to even start doing that). I know, because we do this. We definitely need improved detection tooling, but that’s out of the scope of this PEP.
Achieving machine readability was mentioned in the thread - as a Fedora package maintainer, I’m obliged to review the licensing information and inspect packages to make sure the resulting artifact correctly declares its licenses. I believe the spirit of “human in the loop” will remain in place even when there are more reliable machine-readable metadata available, solely because the licensing information is extremely important for actors like Linux distributions.