Python wheels do not include license text

[musicinmybrain]

The chosen MIT license says,

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

The license text is included in the sdists, semi-accidentally, as part of the bundled jiter crate sources, but there is no top-level LICENSE file.

$ curl -L https://files.pythonhosted.org/packages/source/j/jiter/jiter-0.8.2.tar.gz 2>/dev/null | tar -tz | grep LICENSE
jiter-0.8.2/crates/jiter/LICENSE

The license text is not included in the bdist/wheel at all:

$ python3 -m venv _e
(_e) $ . _e/bin/activate
(_e) $ pip install jiter
$ ls _e/lib/python3.13/site-packages/jiter-*.dist-info/
INSTALLER  METADATA  RECORD  REQUESTED  WHEEL

I would normally offer a PR, but I’m not quite sure of the ideal way to make this work with maturin involved.

[samuelcolvin]

Presumably we do the right thing with pydantic-core. What do we do there?

[musicinmybrain]

Hmm, let’s see. For pydantic-core, we have:

• LICENSE in the top-level directory, together with Cargo.toml and pyproject.toml
• license = "MIT" in the [package] section of Cargo.toml
• 'License :: OSI Approved :: MIT License' in the classifiers list in the [project] section in pyproject.toml
• dynamic = […, 'license', …] in the [project] section in pyproject.toml

The result of python3 -m build is:

• LICENSE in the root of the sdist, e.g. pydantic_core-2.29.0.tar.gz
• LICENSE in the dist-info in the wheel, e.g. pydantic_core-2.29.0.dist-info/licenses/LICENSE in pydantic_core-2.29.0-cp313-cp313-linux_x86_64.whl
• Classifier: License :: OSI Approved :: MIT License, License-File: LICENSE, and License: MIT in the wheel metadata, e.g. pydantic_core-2.29.0.dist-info/METADATA in pydantic_core-2.29.0-cp313-cp313-linux_x86_64.whl

---

For jiter, we have:

• LICENSE in the top-level directory, but it’s a workspace directory; no LICENSE in crates/jiter-python.
• license = "MIT" in the [workspace.package] section of Cargo.toml, and license = {workspace = true} in the [package] section of crates/jiter-python/Cargo.toml
• "License :: OSI Approved :: MIT License" in the classifiers list in the [project] section in crates/jiter-python/pyproject.toml
• No 'license' in the dynamic list in the [project] section in crates/jiter-python/pyproject.toml

The result of python3 -m build (in crates/jiter-python) is:

• crates/jiter/LICENSE in the sdist, but no LICENSE in the root of the sdist, e.g. jiter-0.8.2.tar.gz
• no LICENSE in the dist-info in the wheel, e.g. jiter-0.8.2-cp313-cp313-linux_x86_64.whl
• Classifier: License :: OSI Approved :: MIT License, and License: MIT but not License-File: LICENSE in the wheel metadata, e.g. jiter-0.8.2.dist-info/METADATA in jiter-0.8.2-cp313-cp313-linux_x86_64.whl

If I add a symbolic link to the top-level license file (working in crates/jiter-python, ln -s ../../LICENSE):

• crates/jiter-python/LICENSE is added to the sdist (as a regular file), but there is still no top-level LICENSE file next to pyproject.toml
• still no LICENSE file in the wheel
• no change to METADATA

If I also add "license" to the dynamic list in the [project] section in crates/jiter-python/pyproject.toml, nothing changes.

So adding the crates/jiter-python/LICENSE symlink is probably a good start, but if I’m reading the tea leaves correctly, it looks like the challenge here is that the Python bindings are not at the top level, and when the structure is reorganized to produce an sdist with pyproject.toml at the top level, the LICENSE file isn’t where the tooling expects to find it.

[davidhewitt]

cc @messense, possible maturin issue?

[threexc]

We've run into this issue while building jiter wheels for the RISE Python Packaging project. For now, what I've done is had our CI scripts patch the project by adding a symlink of the LICENSE file into crates/jiter-python/ and then add the following to pyproject.toml:

license = {file = "LICENSE"}

There may be a better way to do this directly with maturin or another configuration step that I'm not aware of.

EDIT: for clarification, we're invoking the build step with:

maturin build --release --compatibility manylinux_2_35 --out dist --interpreter 3.10 3.11 3.12 3.13

@musicinmybrain maybe this workaround will help you?

[musicinmybrain]

@threexc: Thank you for describing your workaround. We’re currently using a similar workaround in Fedora, although the details are a little different:

• We mv crates/jiter/LICENSE ./ instead of using ln -s. (On the other hand, ln -s would make just as much sense.)
• We don’t bother with patching pyproject.toml, because our end product is an RPM rather than a wheel/bdist, and we already have to handle listing license files manually in order to include the the LICENSE.dependencies file we generate at build time to document licenses of statically-linked Rust crates. (On the other hand, the patch you suggested should still give us slightly better metadata in the dist-info directory.)

This all works adequately downstream, but I had hoped to be able to suggest a general fix, and this has proved surprisingly difficult.

By the way, since you’re working on the RISC-V software ecosystem, you might be interested to know that progress toward fully supporting RISC-V in Fedora has been coming along nicely.