Published wheel declares both BSD and proprietary classifiers, and ships no license file

Start with pyproject.toml and inspect the package metadata and wheel-building configuration. Confirm whether the proprietary classifier is deliberate, then build a wheel and inspect its METADATA and dist-info contents. Done means the published metadata consistently identifies Apache-2.0 and the wheel includes the LICENSE file.

The published scaleway wheel declares two mutually exclusive license classifiers and ships no license file. Automated license review therefore resolves it to a proprietary license and blocks the dependency, even though this repository is Apache-2.0.

Measured, on 2026-09-03

The repository:

$ gh api repos/scaleway/scaleway-sdk-python
  default_branch: main
  license.spdx_id: Apache-2.0
  LICENSE at the root: 10756 bytes

The published package, every version from 2.9.0 to the current 2.12.0:

$ python -c "from importlib.metadata import metadata; ..."
  License          : 'BSD'
  license_expression: None
  classifier       : License :: OSI Approved :: BSD License
  classifier       : License :: Other/Proprietary License

And the installed distribution ships no license text at all:

$ ls .venv/lib/python3.12/site-packages/scaleway-2.11.0.dist-info
  INSTALLER  METADATA  RECORD  REQUESTED  WHEEL

So three sources disagree: the repository says Apache-2.0, the metadata says BSD, and a second classifier says proprietary. A tool has no way to prefer one.

What it costs a consumer

GitHub's dependency-review-action resolves the pair of classifiers to:

BSD-2-Clause AND BSD-3-Clause AND LicenseRef-scancode-proprietary-license

and fails the check:

The following dependencies have incompatible licenses:
  meta/ee-requirements.txt » scaleway@>= 2.9.0
  – License: BSD-2-Clause AND BSD-3-Clause AND LicenseRef-scancode-proprietary-license

AND is the operative word: the resolved expression requires satisfying the proprietary term too, so no allow-list of open licenses can accept it. The only ways out are to exempt the package by name — which accepts an unknown license on trust — or to drop the SDK.

I am building an Ansible collection that uses this SDK as its runtime client, exactly as the official scaleway.scaleway collection does. I would rather not ship an exemption that says "we assume this is fine".

What would fix it

Any one of these, in decreasing order of how much it settles:

1. license = "Apache-2.0" as a PEP 639 SPDX expression in pyproject.toml, plus license-files = ["LICENSE"] so the wheel carries the text. This makes the package self-describing and needs no classifier at all.
2. Remove the License :: Other/Proprietary License classifier and correct License :: OSI Approved :: BSD License to License :: OSI Approved :: Apache Software License.
3. At minimum, include LICENSE in the distribution, so a scanner reading the file wins over ambiguous classifiers.

I am happy to open a pull request for (1) if that is welcome — it is a few lines in pyproject.toml.

One question I could not answer from the outside

Is the Other/Proprietary License classifier deliberate? If some part of the generated code carries different terms from the repository's Apache-2.0, that would be worth stating explicitly rather than leaving to a classifier — consumers who audit licenses will read it as covering the whole package.