Recommend the use of SPDX license descriptions

[qwcode]

SPDX is an approach to describing open source licenses that is designed to support automated auditing processes and generally make it simpler to create large collections of open source software while maintaining compliance with the individual licenses.

See https://spdx.org/spdx-license-list/license-list-overview (and other pages on that site) for more details. (The list is maintained under the auspices of the Linux Foundation)

This proposal consists of two parts:

• Add the SPDX licenses as Trove classifiers on PyPI
• Recommend their use in PEP 459 for the license field in the python.details extension

---

migrated from https://bitbucket.org/pypa/pypi-metadata-formats/issues/28/recommend-the-use-of-spdx-license (originally proposed by @ncoghlan)

[camillem]

Hi,
It might be a good idea to also recommend the use of SPDX expression syntax in addition to SPDX IDs.

[pombredanne]

See also https://github.com/pypa/warehouse/issues/2996 and pypa/packaging.python.org#635

[remram44]

Is the discussion on this and PEP 639 blocking all further changes to trove license classifiers? It might be good to let everyone know whether that is the case rather than letting contributions in limbo for the duration. I would say that additions like pypa/trove-classifiers#69 are probably good to have regardless of the final decision and changes.

[di]

No. Like @pradyunsg mentioned on that issue, the project is maintained by volunteers, who have limited availability. Anyone who needs to specify a license that isn't in the trove classifiers can do so with the freeform License metadata field at any time: https://packaging.python.org/specifications/core-metadata/#license

[remram44]

Not trying to nag, just want clarification on the process. If further changes to license classifiers are blocked, that is fine; if there was no decision to block and it is waiting for review, that is also fine. I'm just trying to find out which is it. What does your "No." signify?

[pradyunsg]

IIUC, what @di is saying is: it is not blocked on that, however the available maintainer time is unlikely to be invested into improving the trove classifiers. Given that there's an alternative and given that there's a significantly "more complete" solution in the form of PEP 639, it's more likely that we'd spend the limited availability on getting that over the line.