Feature: Support for SPDX license expression metadata after PEP 639

[psrmx]

Feature Details

After the introduction of PEP639, which improves clarity in licenses via better package metadata, various projects are adopting SPDX license expressions in their metadata as a way to specify the package's licenses (vs. the previous License field). Here are some recent examples:

• https://pypi.org/project/attrs/25.1.0/ (vs. 24.2.0)
• https://pypi.org/project/prettytable/3.15.1/ (vs. 3.12.0)
• https://pypi.org/project/referencing/0.36.2/ (vs. 0.35.1)

However, LicenseCheck version 2024.3 does not recognise license expressions, and the check for these packages fails.

Is your feature request related to a problem? Please describe

Given that those packages actually have licenses defined in the package's metadata, it'd be great that LicenseCheck identifies the licenses from license expressions. We currently use LicenseCheck in our pipeline, and since more and more packages are using license expressions, the pipelines keep failing.

Describe the solution you'd like

While debugging, I realised that the metadata library does extract the information from the package, it is just embedded into a json, and the keys point to license_expression. So expanding the function getPackageInfoLocal to also extract license_expression would suffice. Something along the lines:

    if lice == UNKNOWN:
        lice = _pkgMetadataGet(pkgMetadata, "License") or _pkgMetadataGet(pkgMetadata.json, "license_expression")

[FredHappyface]

Added support for this in https://github.com/FHPythonUtils/LicenseCheck/releases/tag/2025, thanks for your patience on this one :)

[jmehnle]

Thanks for fixing this! Alas, the referencing package is still failing, whereas :

$ licensecheck --groups dev --show-only-failing
                                                 
                      Info                       
┏━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Item            ┃ Value                       ┃
┡━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ program         │ licensecheck                │
│ version         │ 2025.0.1                    │
│ license         │ MIT LICENSE                 │
│ project_license │ NO LICENSE/ UNKNOWN LICENSE │
└─────────────────┴─────────────────────────────┘
                                                                    
                          List Of Packages                          
┏━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Compatible ┃ Package      ┃ License(s)                           ┃
┡━━━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ ✖          │ certifi      │ MOZILLA PUBLIC LICENSE 2.0 _MPL 2.0_ │
│ ✖          │ fqdn         │ MOZILLA PUBLIC LICENSE 2.0 _MPL 2.0_ │
│ ✖          │ licensecheck │ UNKNOWN                              │
│ ✖          │ referencing  │ UNKNOWN                              │
└────────────┴──────────────┴──────────────────────────────────────┘

Ignore the MPL failures, these are related to #86.

Do the UNKNOWN failures seem related to the original incompatibility with PEP-639 (this issue), or should I file a new issue?

[FredHappyface]

I'll check the referencing case as this might just be that we couldn't identify the licence it was using which was a change from the No-License behaviour previously :)