Repository navigation
Drop the versionless License :: classifier now that license is a valid SPDX expression #7610
Description
This issue is part of a larger batch of similar-scoped issues we distribute in the context of our internal vulnerability and dependency tracking activities. The batch covers multiple projects, this is only one of them. The goal is to rise awareness and trigger/initiate the change towards clean project metadata in projects we depend on.
Summary
This project already declares a valid SPDX license id/expression in its packaging metadata (License: Apache-2.0 in the built METADATA), but the deprecated classifier License :: OSI Approved :: Apache Software License is still present. That classifier has no version and PEP 639-aware SBOM tooling like cyclonedx-bom can't map it to an SPDX id, so it falls back to emitting the raw classifier text as a free-text license name. This free-text field is just noise and causes downstream tooling to flag this project as non-SPDX-compliant.
Suggested fix
Remove the redundant License :: OSI Approved :: Apache Software License from classifiers in the packaging config. No change to the license field is needed.
How to reproduce
uv tool install cyclonedx-bom
uv venv .venv-repro
uv pip install --python .venv-repro/bin/python requests
cyclonedx-py environment .venv-repro -o sbom.cdx.json... and then check the .licenses property of the component. There should only something like:
// This is how it should look like
...
"license": {
"acknowledgement": "declared",
"id": "<VALID SPDX IDENTIFIER>"
}
...and not:
// This is how it should not look like
...
"license": {
"acknowledgement": "declared",
"name": "<CLASSIFIER TAKEN FROM METADATA"
}
...I'm happy to provide a PR to resolve this timely after approval!
Activity
sigmavirus24 commentedon Aug 26, 2026
Why open spammy issues against 10s (if not more) repositories when the tooling could detect "License is a valid SPDX" license, the other information is less accurate and should be ignored. CycloneDX seems to be actively maintained. Why make individual projects do work that doesn't help on older versions instead of fixing the broken tool?
btschwertfeger commentedon Aug 26, 2026
We evaluated our third part dependencies and decided to make the packages/repositories/maintainers aware of this circumstance. Since lots of the projects used by us share the same problem, using a template-like issue which is specific enough and actionable seemed to be justified.
The license classifier used by requests is deprecated (see https://peps.python.org/pep-0639/#deprecate-license-classifiers), so the fix needs to be done here anyways.
The cyclonedx-bom tool does what it should, since the CycloneDX 1.7 specification allows free-text fields (https://cyclonedx.org/docs/1.7/json/#metadata_tools_oneOf_i0_components_items_licenses_items_oneOf_i0_license_name). The problem is that the requests package has a single license defined here
requests/pyproject.toml
Line 9 in 5460f46
So having the license classifier is not only deprecated but also redundant. Maybe the SBOM example wasn't the best case to justify a need for adjustment, sorry for that. But treating this issue as if it was spam is not adequate.
nateprewitt commentedon Aug 26, 2026
@btschwertfeger, we have discussed this here previously. The current setup is intended as there are still millions of daily downloads of setuptools that do not support what you're proposing.
We will get to a point where we are able to remove this in the future but forcing projects to follow a deprecation that's happened in the last 6 months is fairly aggressive for the Python ecosystem. We'll revisit in the future, but it's still not clear why Cyclonedx is not able to disambiguate two fairly concrete specifiers. The SPDX identifier we include is synonymous with the classifier. Breaking users ability to build the package for the sake of simplifying metadata tooling is not something we intend to do immediately.
btschwertfeger commentedon Aug 26, 2026
That is fine, at least we now have an issue to track and refer to. 👍
sigmavirus24 commentedon Aug 29, 2026
I would have closed it if I said it was spam. I said it's spammy because instead of fixing this in one place, you're requiring 10s if not 100s of maintainers to fix this individually and only on the latest version of the package which there's 0 guarantee you'll upgrade to. So your SBOM tool will still misreport things. Instead of fixing CycloneDX you're making work for others with no guarantee of the payoff for you
btschwertfeger commentedon Aug 29, 2026
As I already noted in #7610 (comment) that the cyclonedx-bom example wasn't the best one to make this point. I should have used this:
... proving two declarations of the same license where one of them is deprecated and versionless. So the problem exists in the package metadata itself, independent of any tooling.
I'd argue that "no guarantee of the payoff for you" doesn't apply here. We already have suppressions in place, so nothing here is blocking us or waiting on this fix. This was never about our own pipeline. As for all issues, the maintainers decide if and how to schedule changes. The intent was to create awareness and not to apply pressure or force any kind of urgency.
"Spammy" doesn't fit either, IMO. Most of the maintainers we contacted across these issues merged a PR or fixed it themselves without much discussion. This one has taken more back and forth than most, but that doesn't make the underlying issue less valid.
This gets cleaned up eventually, just not now, and that's fine for us.
ShamikOfficial commentedon Sep 6, 2026
ShamikOfficial commentedon Sep 6, 2026
feat: issue → 计划 → 代码改动 → 补丁审批的完整链路 (#7)