[abravalheri]

Despite the fact that the setuptools own code is distributed under the MIT license, the project includes third-party code under different licenses.

For some downstream users, adding license = "MIT" to pyproject.toml is problematic under the lenses of PEP 639 because it may imply that all the files distributed by setuptools are licensed under MIT, which is not the case. See discussion in #5049.

By removing that metadata, setuptools should be "in the clear".

I understand that consumers of the package would prefer a complete SPDX license expression. However, as explained in #5049, this is currently not viable. In the future, setuptools may adopt SPDX expressions once tools exist in the Python ecosystem that can automatically compute them from a given set of files and directories.

For the time being, consumers interested in knowing license information should refer to the text in the license files being distributed.

Summary of changes

Closes #5049

Pull Request Checklist

• Changes have tests
• News fragment added in newsfragments/.
  (See documentation for details)

[jaraco]

In my opinion, the SPDX is for Setuptools. Maybe there should be a note in the _vendor folder that notes that these packages not covered by the Setuptools-indicated license, but are covered by their own licenses. These vendored packages are kept as a necessity and we wish them gone and their presence should not be influencing the core of the project.

[abravalheri]

Thank you very much for the review @jaraco.

While I agree with you (I also think tha the license expression should reflect only the license of setuptools), there has been some push in the community from people that want the license expression to reflect all files present in the whole sdist/wheel archive.

After a clarification provided by the PEP 639 author and discussion in the PyPA forum, the part of the community pushing for that specific interpretation managed to pass a change in the text of the standard (see pypa/packaging.python.org#1908), and now it explicitly says:

This key should only be specified if the license expression for any and all distribution files created by a build backend using the pyproject.toml is the same as the one specified. If the license expression will differ then it should either be specified as dynamic or not set at all.

(the emphasis is mine, i.e. it recommends removing this SPDX specifier if it does not apply to all the files or dynamically calculating it)

Since dynamically calculating the license expression is not a trivial task, this PR proposes the other solution mentioned in the standard (i.e. omitting the license expression).

[rgommers]

managed to pass a change in the text of the standard (see pypa/packaging.python.org#1908), and now it explicitly says:

This is the correct interpretation and the spec is very clear about that. I'll also note that it wasn't a change from one interpretation to the other; the original PEP 639 just left it unclear, and hence it was clarified through the discussion and PR you link.

Since dynamically calculating the license expression is not a trivial task,

Does it need to be dynamic? I would not expect the included licenses when building an sdist and none-any wheel to change at all. If that's indeed constant, you can just determine it once and make that the static SPDX string.

[abravalheri]

@rgommers I think that at least we would need something automatic/dynamic that indicates license have changed so that a human can go and have a deeper look on the specifics of the changes (related to the bundling/vendoring problem due to bootstrapping). And preferably the same automatic system to calculate the full SPDX expression including the licenses from bundled dependencies.

But this PR should cover all the advice of the PEP. The remaining is "nice to have", but not essential.

[rgommers]

I think that at least we need something automatic/dynamic that indicates license have changed so that a human can go and have a deeper look on the specifics of the changes

I think you put this in the release notes? And if you mean "guard against future license changes", then I'd suggest a CI job that scans for new license files and snippets.

But this PR should cover all the advice of the PEP. The remaining is "nice to have", but not essential.

I agree. I think you should go ahead and merge this to resolve this - licensing issues are critical, not nice-to-haves that can be left unresolved for a year.

You could go back to a static SPDX expression in a follow-up. I believe the correct one is:

MIT AND PSF-2.0 AND LGPL-3.0-or-later AND (Apache-2.0 OR BSD-2-Clause) AND MPL-2.0 AND BSD-3-Clause

but you'll want to carefully double-check that of course.