Yes. A compiled wheel can carry shared libraries that are not listed as Python dependencies. The auditwheel documentation says its repair step copies external shared libraries into the wheel and warns that bundling, like static linking, may implicate copyright concerns. Check the licenses of what is inside the wheel.
What is in a compiled wheel
A pure Python package lists its dependencies, and your lockfile shows them. A wheel with a compiled extension is different. To run on many Linux systems, build tools can fold the native libraries the extension needs into the wheel itself.
The auditwheel README describes two commands. The show command lists external shared libraries the wheel depends on. The repair command copies those libraries into the wheel and updates the RPATH entries so they load at runtime, which it describes as similar to static linking without changes to the build system. It then advises packagers that bundling, like static linking, may implicate copyright concerns.
For a consumer, the consequence is simple. The package metadata says one license. The files inside may be covered by several more, and your SBOM built from the lockfile shows only the first.
Why it matters for a product
If your product ships a Python environment, a container image, or an installer that includes such a wheel, you are redistributing the bundled libraries. Any notice or source duties attached to them come along. If one of those libraries is under a copyleft license, the review is more serious. This is general guidance, not legal advice.
Steps to check a wheel
- Pick the wheels that contain compiled code. Names with a platform tag, rather than "any", are the ones to look at.
- Unzip a wheel. Wheels are zip archives. Look for a libs folder or files with extensions like .so beside the package.
- Read the dist-info folder. Many projects place license files there, and some bundle additional license texts for the libraries they vendored.
- If the dist-info folder has no texts for the bundled libraries, identify them from the filenames and look up their licenses at the source.
- Add the findings to your inventory as components in their own right, with name, version and license.
- If the wheel is a build you made yourself, run auditwheel show before you repair, so you know what you are about to bundle, and record the result.
Setting a team rule
Decide ahead of time what the default is for compiled wheels from outside sources. A workable rule is that any wheel with bundled native libraries is flagged for one time review per major version, since the bundled set rarely changes between patch releases. Treat a change in the library list as a new review.
For your own wheels, the build record should list bundled libraries and their licenses, produced at build time. A one page note stored beside the artifact is enough, as long as it is created for each release and not reconstructed later.
Our posts on license metadata by ecosystem and PEP 639 explain what the declared metadata can and cannot tell you.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a scan reads what is inside an image rather than only what a manifest claims, which is the same gap compiled wheels create.
Safeguard's SBOM and dependency scanning builds a component inventory with license data, and it covers container images too. You can try a free scan at gold.safeguard.sh.
Quick check
Does a pure Python wheel have this issue?
Much less. With no compiled code, there are typically no bundled native libraries, though vendored Python code inside a package is still worth a look.
Is the license in the wheel metadata enough?
It describes the package, not necessarily every library inside it. Check the files in the archive.
Sources
Last reviewed: 19 October 2026.
