Pre-delivery licence audit

Before you hand a build to a customer, find the dependencies that put an obligation on the whole thing you deliver — not just the ones with a scary licence name.

Why this is a separate problem

On 26 August 2026 I ran 11 real projects — 2,651 dependencies across six ecosystems — through every delivery model. 12 dependencies change verdict between running software yourself and shipping it. That is 0.45%, and it is the entire problem: too few to notice by reading, too consequential to miss.

One of those projects is a production Rails tree with 344 dependencies. Run it yourself and nothing obliges you to license your own code under someone else's terms. Ship the identical tree to a customer and three dependencies do:

bundler-audit 0.9.3 — GPL-3.0-or-later
diff-lcs 1.6.2 — MIT AND Artistic-1.0-Perl AND GPL-2.0-or-later — arrives through RSpec
rdoc 8.0.0 — Ruby AND GPL-2.0-only — ships inside Ruby itself

Nobody chose any of them. They are three lines out of 344, they are in a great many Ruby projects, and a person reading a dependency list does not find them.

What you get

Every manifest in the repository, not one pasted file — monorepos, multiple languages, build and runtime scopes separated.
The obligation matrix under your actual delivery model, with the same analysis run against the alternatives so you can see what changes if the delivery method changes.
Per finding: the SPDX expression, where that expression came from (which registry or upstream said so), and what it obliges you to do.
The same-licence list — separated out, because those are the ones that reach past the dependency and attach to your own work.
Everything that could not be resolved, listed explicitly — git dependencies, vendored code, internal packages. Silently dropping these is how a clean report gets produced for a codebase that was never fully read.
A written report you can attach to delivery documentation or hand to a customer's review.

Price

Repository audit

$1,500

one repository, up to 5,000 dependencies

Written report, delivered within 5 business days
All manifests and ecosystems in that repository
One round of follow-up questions

Re-audit

$500

same repository, within 6 months

What changed since the last audit
New and removed obligations
Useful before a release, not on a schedule

Larger than 5,000 dependencies, or several repositories at once: say so below and you will get a fixed quote before any work starts. Nothing is charged until scope is agreed in writing.

What this is not

It is not legal advice, and it is not a substitute for counsel on a decision that carries real money. It is an engineering analysis of what your dependency tree declares and what those declarations oblige.

It does not detect licensed code copied into your own source files. That is a different class of tool (ScanCode and its relatives) and if that is your concern, this is the wrong purchase — say so and I will tell you that rather than sell you this.

It reads declared metadata and public registries. A package whose own metadata is wrong will be reported as it declares itself. Where a declaration looks unreliable, that is called out rather than smoothed over.

Request an audit

This goes to a person, not a list. You will get a reply with a scope and a fixed price, or a straight answer that this is not what you need.

Email Company (optional) How does this software reach its users? Roughly what is in it?

An estimate is fine. Do not paste a manifest here — nothing you paste on this site is stored, and the request form is no exception.

Anything else (optional)

License data last reviewed 2026-08-24.

LicenseGuard reports information derived from published license texts and dependency manifests. It is not legal advice and using it does not create an attorney-client relationship. Results reflect license metadata as declared; they do not identify every obligation or violation. Consult qualified counsel for decisions that matter.

Listed in the official MCP registry, on Glama and on Smithery. Source on GitHub (Apache-2.0).