Use SPDX license tags in pyproject.toml

[bdice]

We want to use SPDX license identifiers in pyproject.toml files, following the Python Packaging Docs on the license field.

Today we define our licenses in a way that was meant to pass wheeltamer, an internal check for wheels which is no longer used.

Therefore we should replace this:

[project]
license = { text = "Apache 2.0" }

with this (note the dash, which makes this a valid SPDX identifier):

[project]
license = "Apache-2.0"

Specifically, this change conforms to: https://peps.python.org/pep-0639/#deprecate-license-key-table-subkeys

[eriknw]

More context: this field has changed since PEP 621. See also PEP 639, but the link in the original comment to the Python Packaging user guide is the canonical, up to date source of truth.

[eriknw]

What about using license-expression and license-file? license has been deprecated according to:

• https://packaging.python.org/en/latest/specifications/core-metadata/#license
• https://packaging.python.org/en/latest/specifications/core-metadata/#license-expression
• https://packaging.python.org/en/latest/specifications/core-metadata/#license-file-multiple-use

[gforsyth]

pip 25.0.1 seems to have its own ideas about what is valid in the license field

[bdice]

Wow. I'm just catching up here -- I had no idea that I was touching something that was recently changed.

Apparently setuptools does not yet support license expressions in project.license, which is what PEP 639 standardized not too long ago. I just looked at https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license and assumed that tooling was up to date with the packaging guidelines.

This PR to setuptools will add PEP 639 license expression support. pypa/setuptools#4706

I am going to cancel this endeavor until a future time.

[bdice]

What about using license-expression and license-file? license has been deprecated according to:

• https://packaging.python.org/en/latest/specifications/core-metadata/#license
• https://packaging.python.org/en/latest/specifications/core-metadata/#license-expression
• https://packaging.python.org/en/latest/specifications/core-metadata/#license-file-multiple-use

@eriknw Once tooling (setuptools) catches up to PEP 639, I think we want to continue specifying license in the [project] table, as it will map to License-Expression in the future. See the last sentence here:

Add string value to license key

license key in the [project] table is defined to contain a top-level string value. It is a valid SPDX license expression as defined in this PEP. Its value maps to the License-Expression field in the core metadata.

[jakirkham]

Wonder if as a first step we could do this?

 [project]
-license = { text = "Apache 2.0" }
+license = { text = "Apache-2.0" }

Namely ensure the text field itself is SPDX compatible

Looks like that is true in several projects (though not all)

[bdice]

@jakirkham I think your proposal is a good next step. This work is motivated by the rattler-build transition. If rattler-build complains about Apache 2.0, we can change to SPDX compliant Apache-2.0 in each affected repository.

I proposed that in the original thread that prompted this issue: rapidsai/rmm#1796 (comment)