Skip to content

Drop the versionless License :: classifier now that license is a valid SPDX expression #434

Open

Description

@btschwertfeger

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: MPL-2.0 in the built METADATA), but the deprecated classifier License :: OSI Approved :: Mozilla Public License 2.0 (MPL 2.0) is still present. 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 :: 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 certifi
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

  1. sigmavirus24 commented on Aug 26, 2026

    @sigmavirus24
    Member

    Personally I wouldn't do this yet given how widely certifi is used.

    See also psf/requests#7610 for discussion of why requests isn't pursuing a fix

  2. alex commented on Aug 28, 2026

    @alex
    Member

    I'm pretty apathetic, but would merge a PR removing the classifier in favor of hte proper license metadata.

  3. sigmavirus24 commented on Aug 28, 2026

    @sigmavirus24
    Member

    It's a bit early to drop the prior best practice for one only standardized relatively recently in the grand arc of packaging just because some tool doesn't do the right thing by preferring the more accurate value if it is present.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions