cargo-about: a cargo plugin that renders the licence of every dependency you pulled in

A single job: list every dependency and its terms

cargo-about is a cargo plugin for generating a licence listing for all dependencies of a crate, and the package description in Cargo.toml is more precise still: a listing of all of the crates and the terms under which they are licensed.

That is a narrow scope, and it is the kind of narrow scope that makes a tool useful. Shipping a Rust binary means shipping a dependency tree with dozens of crates under a mix of MIT, Apache, BSD and occasionally more awkward licences, and a project that wants an attribution page or a licence report has to produce that list somehow. Doing it by hand goes stale the moment the lock file changes.

The project comes from Embark Studios, and the README is unusually candid about its own status. It says this is a tool that the authors use and like, that it makes sense to them to release it as open source, and that they cannot take any responsibility for whether it will function correctly or fulfil the reader's needs. It closes with the sentence that matters for a compliance tool: no functionality in, or information provided by, cargo-about constitutes legal advice.

That disclaimer is not a formality. A licence listing answers the question of which terms apply to which dependency, and it does not answer whether those terms are compatible with the way you are using the code, or whether an attribution requirement has been satisfied. The tool is a data collector and a renderer, and it is careful to say that.

The documentation is a book hosted at embarkstudios.github.io/cargo-about, and the badges give the compatibility data: SPDX version 3.25.0, a minimum stable Rust version of 1.81.0, a crates.io version, API docs on docs.rs, a dependency status page from deps.rs and a CI build badge.

The dependency graph is the input, and a template is the output

The mechanism has two halves, and understanding them tells you where the control lies.

The first half is collection. The Cargo.toml lists krates at version 0.21 with the serialize feature under the comment for dependency graphing, and ignore at 0.4 under directory walking, which is how the tool finds licence files in the registry sources of the dependencies it has resolved. The result is a set of crates, each with an SPDX identifier, which is what the SPDX version badge refers to.

The second half is rendering, and this is the part you own. The CLI feature pulls in handlebars, alongside clap for the command line, nu-ansi-term and fern for terminal output, jiff for time handling and mimalloc for allocation. The handlebars dependency is the giveaway: the report is a template, not a fixed format.

The repository makes that concrete. about.toml and about.hbs sit at the root as the default configuration and template, and about_list_by_crate_example.hbs is a second example template that lists things by crate rather than in the default order. The resources/ directory holds the assets the templates need, such as the licence texts themselves.

So the design is: resolve the graph, collect the licence metadata, and hand it to a template you can rewrite. A project that wants a one page attribution notice and a project that wants a full compliance appendix both run the same command and differ only in the template.

Three install routes, and one of them insists on a lock file

Installing from crates.io is the ordinary route, and the flags in it are worth reading:

cargo install --locked --features cli cargo-about

The --locked flag means the published lock file is used rather than resolving fresh versions, and --features cli is required because the binary is behind that feature. The Cargo.toml makes the same structure explicit, with a binary target named cargo-about at src/cargo-about/main.rs whose required-features is cli, and the cli feature itself pulling in the CLI dependencies.

The second route exists for people who manage tool installs with cargo-update. The configuration goes in the install config file in your cargo directory:

# ~/.cargo/.install_config.toml
[cargo-about]
default_features = false
features = ["cli"]
enforce_lock = true

The enforce_lock setting is the important part, and it is the same requirement the first route expresses with --locked: the version of the tool you run has to be the version that was resolved, or the licence data you collect can differ from what a lock file claims.

The third route is the distribution package, and on Arch Linux it is:

pacman -S cargo-about

Note what the CLI feature gating implies for the library use. The Cargo.toml also lists krates, serde, serde_json and semver as ordinary dependencies, so the collection logic is usable as a library by another tool, with the command line and the templating layered on top of it.

Two commands produce a configuration and then a report

The usage section is two commands, and the order matters because the first one creates the inputs for the second.

# Generates `about.toml` and `about.hbs` in your cargo project
cargo about init
# Generate the license information with
cargo about generate about.hbs > license.html

cargo about init writes about.toml and about.hbs into your cargo project. Those are the two files you then own and edit: the configuration says which crates and which fields you care about, and the template says what the report looks like. cargo about generate then takes the template and writes the rendered report to standard output, which is why the example redirects it into license.html rather than passing a path.

That redirection has a practical consequence worth noting. The tool writes to standard output, so the output can be piped, checked into the repository, or captured by a CI job that verifies the report is current, and none of that requires the tool to know anything about your build system. The same applies to the template, which can be swapped per release or per audience.

The repository also carries a deny.toml, which is the configuration file used by the cargo-deny family of tools for licence policy checks. Having both in one place makes sense for a Rust project: one file states the policy and the other produces the report that shows whether the policy is being met.

Release automation is configured too, with a release.toml at the root and a CHANGELOG.md, and the version follows the usual pattern of 0.9.2 on 2026-08-18, 0.9.1 on 2026-07-02 and 0.9.0 on 2026-04-24.

The tool collects data, a lawyer decides what it means

It is worth being explicit about the division of labour, because licence tooling is often sold as if it made the decision for you.

What cargo-about does is mechanical. It resolves your dependency graph, finds the licence of each crate, identifies the licence text, and renders the lot through a template. The SPDX identifier in the output is the crate's declared licence, which is a claim made by the crate's author, and the tool reports it accurately. Whether that claim is correct, whether the licence is compatible with your use, and whether you have met the conditions attached to it are not questions the tool answers, and the README says so directly.

The dual licence position of the project itself is worth noting in the same breath. The repository ships LICENSE-APACHE and LICENSE-MIT, and the Cargo.toml declares license = MIT OR Apache-2.0, so you choose. The contribution terms follow the same pattern: unless a contributor states otherwise, a contribution is dual licensed under the Apache-2.0 terms as described, with no additional conditions.

The practical way to use the tool is therefore to generate the report, read it, and treat it as the input to a decision rather than the decision. The template is where that shows: an organisation that needs a specific attribution format can encode it and get a consistent document every time the dependency tree changes, which is the real saving.

Where cargo-about is the wrong tool

The first wrong fit is a project that is not Cargo based. This is a cargo plugin, it resolves a Cargo lock file, and its whole data source is the Rust registry. A Node, Python or Go project with a comparable dependency tree needs a different collector.

The second is a team that needs licence compatibility analysis rather than a listing. The tool will happily render a report that shows you are using a crate under a licence your distribution cannot accept, and it will not flag it. The SPDX identifiers are the input to that judgement, not the judgement itself, and the README is careful to say the output is not legal advice.

The third is an organisation with a policy as code requirement. cargo-about has deny.toml in the repository, which is the right neighbourhood, but the tool's own job ends at the report. If you want the build to fail when a licence is unacceptable, that is a check you wire into your pipeline, and the report is the input to it.

The fourth is a binary distribution with no source to attach a report to. A licence listing makes sense for a crate you publish, because the recipient needs to know the terms of the code they received. For a closed binary that is never redistributed, the list is something you need for your own records rather than for your users, and a spreadsheet maintained by hand may be enough.

The fifth is a project with no dependencies, which is rare but real, and in that case the tool has nothing to say.

On the state of the project: the last push to the repository was on 2026-09-18 with the repository not archived, the Cargo.toml declares edition 2024 with a rust-version of 1.88.0 even though the README badge advertises a minimum stable Rust version of 1.81.0, and the manifest still carries a maintenance badge marked actively-developed. The crate is published on crates.io, the API documentation is on docs.rs, and the security policy and contributor covenant are in the repository.

Editorial conclusion

cargo-about fits a Rust project that has to publish an attribution page or hand a licence report to legal, and that wants the report rendered from a template it controls rather than copied by hand. It does not fit a workspace that is not Cargo based, and it does not replace a licence review, because the tool itself says its output is not legal advice. Before adopting it, run cargo about init and read the generated about.toml, since the configuration is where the interesting decisions live.

Frequently asked questions

Official sources

1. EmbarkStudios/cargo-about on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases