Draft: Add uv license command

[ryanleary]

Summary

Add a new command, uv license, to uv to assist with dependency license audit needs in response to #8156. Design of command arguments loosely informed by https://crates.io/crates/cargo-license.

Example invocation:

$ cat pyproject.toml
[project]
name = "project"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = [
    "scikit-learn==1.4.1.post1"
]
classifiers = [
    "License :: OSI Approved :: MIT License"
]
$
$ uv license --universal
project: 0.1.0, MIT License
scikit-learn: 1.4.1.post1, BSD License
joblib: 1.3.2, BSD License
numpy: 1.26.4, BSD License
scipy: 1.12.0, BSD License
threadpoolctl: 3.4.0, BSD License

As of right now, the implementation is very rough, with this PR intended to gather feedback on the approach, with the initial focus on pulling license information from Trove classifiers. A refined implementation would pivot to following PEP-639 guidelines, return license information as SPDX expressions, and gracefully fall back to Trove, and finally the (legacy?) license field.

I'd like feedback on whether or not the current approach:

• is a relatively expensive license() method on Package objects to trigger calls to DistributionDatabase.get_or_build_wheel_metadata sensible? is a better way that I am missing that would be minimally disruptive to the overall uv codebase?
• There are many Metadata-related structs within the codebase which explicitly comment that they contain only the subset of fields required for dependency resolution. Adding additional optional fields here breaks this constraint and I'm not sure if is desirable or would be acceptable to the maintainers.

Note: the display code is entirely copied from uv tree and cut down. I would rewrite to enable display organized by package or license/serialization to machine-readable summary, etc.

Any feedback appreciated. I am new to both the uv codebase and Rust, but will continue on this if we can agree on an approach.

[ranjithrajv]

Maybe we could consider using uv tree --show-licences, similar to uv python list --show-urls.
Just a suggestion, feel free to let me know what you think

[ryanleary]

I had actually started with that, but abandoned it because you may not want to show a tree. You may want to get a list of all dependencies and their licenses, or you may want to group by licenses, etc. I am not opposed if that's a consensus, the bigger issue is getting the data.

With all that said, until PEP-639 is ratified and becomes commonplace, this will necessarily be a bit of a minefield, and we would have to be very careful about what guarantees are made about the data returned (none), and deal with the fact that licenses may be displayed in inconsistent ways depending on the source project.

[ryanleary]

@charliermarsh would you mind weighing in on the approach and if you would be supportive to the inclusion of this if cleaned up?

[zanieb]

I can own taking a look at the broad place of this in our interface.

[ryanleary]

Thanks @zanieb!

Two questions:
(1) is this directionally correct? Do you see the addition of something akin to uv license as sensible?
(2) any opinions on the scope of the reporting to go after initially? The license information is Python is a mess right now. I'm not sure what "good enough" for a v0 would realistically look like.

[zanieb]

I'm all for some sort of command to query license information, but there are other, similar use-cases like auditing dependencies for vulnerabilities. I don't want to have a new top-level command for each thing, so this is loosely blocked on the design of a top-level uv <something> command which performs queries or audits of your dependencies.

Related

• [Feature Request] Add uv audit Command for Security Vulnerability Scanning #9189
• Print dependencies in uv pip list. #10886

[ryanleary]

Fair enough. I'll push forward with the machinery of the license data collection then. We could potentially separate this into two efforts:
(1) internal ability to gather license information
(2) exposing that ability via a CLI/public API that is expected to be relatively stable.