| Crates.io | dd-rust-license-tool |
| lib.rs | dd-rust-license-tool |
| version | 1.0.4 |
| created_at | 2023-07-18 23:21:15.089607+00 |
| updated_at | 2025-07-30 14:32:00.768757+00 |
| description | A tool for creating the `LICENSE-3rdparty.csv` file for DataDog open-source Rust projects. |
| homepage | https://github.com/DataDog/rust-license-tool |
| repository | https://github.com/DataDog/rust-license-tool |
| max_upload_size | |
| id | 919836 |
| size | 56,191 |
This project houses a tool for creating the LICENSE-3rdparty.csv file from Rust projects. This
file is required by the Datadog standards for releasing open source code.
Install the tool using cargo: cargo install dd-rust-license-tool
In your project directory, create the licenses list file with:
dd-rust-license-tool write.
In your CI workflow, check that the licenses list file is up to date with:
dd-rust-license-tool check.
The license tool loads a configuration file at startup that may contain overrides or supplementary
data for packages. This can be useful where a crate does not supply either a homepage or repository
URL, or is missing an explicit license. The filename of this configuration file defaults to
license-tool.toml but can be overridden with the --config command-line option.
Example:
[overrides]
# These crates do not specify a homepage in their metadata.
"openssl-macros" = { origin = "https://github.com/sfackler/rust-openssl" }
"serde_nanos" = { origin = "https://github.com/caspervonb/serde_nanos" }
# `zerocopy` et al don't specify their licenses in the metadata, but the file contains the 2-clause
# BSD terms. These should use versioned identifiers, as they could change from version to version
# and so need to be reviewed after each version bump.
"zerocopy-0.6.1" = { license = "BSD-2-Clause" }
"zerocopy-derive-0.3.2" = { license = "BSD-2-Clause" }
There are other existing projects that come close to providing the data required for the above
file. However, none of them scan the actual license or source files within the projects, which is
required to produce the "copyright" field in the file, so all of them would require this as a
follow-on step. Most also do not report the repository from which the crate came from, so we would
need to parse the cargo metadata output anyways. None have options to output into CSV, and so
additionally require a post-processing step.
cargo-aboutHas integrated license validity checking.
cargo-bundle-licensesSimilar kind of tool to this one, with all the limitations above.
cargo-denyGroups all results on the licenses rather than listing all the licenses per dependency, making it impossible to generate an accurate CSV listing.
cargo-licenseLimitations as above.
extrude-licensesIs just a wrapper for cargo-license, so has all its limitations.