Open-Source License Compliance: Auditing a Repo's Dependencies

Intellectual Property · Updated August 2026

Knowing which open-source licenses a project uses is the easy part. The hard part — and the part that actually decides whether a company has a problem — is whether the obligations those licenses impose have been met. A license inventory is a list; a compliance audit is a judgment. This is a walk through how to turn the first into the second by reading a repository's own dependency graph, and how OpenDD's Open Source Due Diligence module now does it automatically.

From a license list to a compliance verdict

Most tools stop at the inventory: here are your dependencies, here are their licenses. That leaves the important question unanswered. An MIT dependency and an AGPL dependency both show up as "a license," but one asks only for attribution while the other can require you to publish the source of your entire hosted service. Compliance is about the interaction between a project's own license and the licenses it pulls in — and whether that combination is actually permissible. The audit's job is to flag the conflicts, not just catalogue the licenses.

Read the dependency graph, not just the manifest

A manifest — package.json, requirements.txt, go.mod — lists what a project directly asks for. But real risk often hides in transitive dependencies: the packages your packages depend on. The more complete source is the repository's software bill of materials (SBOM), the dependency graph the hosting platform builds by resolving those manifests and lockfiles. Reading the SBOM gives you the full inventory of what the code actually depends on, direct and indirect, each entry carrying its declared or concluded license. That fuller picture is what a compliance audit needs to be trustworthy.

Classify every license by risk tier

Once you have the inventory, each license sorts into a tier that determines its obligation. Permissive (MIT, BSD, Apache) asks for attribution and notice. Weak copyleft (LGPL, MPL, EPL) requires changes to the component be shared but usually lets your own code stay separate. Strong copyleft (the GPL family) can require a distributed product that includes the code to be released under the GPL. Network copyleft — the AGPL — extends that trigger to software merely offered over a network. To make each tier easy to verify rather than take on faith, the module links every classified license to its reference definition, so a reviewer can read what "LGPL-3.0" or "AGPL-3.0" actually requires in one click rather than guessing from the identifier.

Identify who publishes each dependency

A compliance review is also a supply-chain review, and part of that is knowing who is behind each dependency. The audit derives the owner or publisher of every package from its identity — the scope of a namespaced package, the organization in a source path — so a long dependency list becomes legible: you can see which components come from a major foundation, which from a single maintainer, and which from a source you do not recognize. That context matters both for license trust and for the operational risk of depending on code with an unclear provenance.

The compliance verdict, and what triggers it

With the project's own license and each dependency's license in hand, the audit produces a verdict rather than leaving the reader to connect the dots. A clean permissive project with permissive dependencies reads as compliant, with a reminder to preserve attribution. Permissive dependencies alone raise an attention flag for those attribution obligations. Weak copyleft moves the project to at risk. And the sharp cases — a GPL or AGPL dependency sitting under a permissively-licensed project, or a dependency with no resolvable license at all — are called out as likely non-compliant, because a permissive project generally cannot satisfy strong-copyleft reciprocity, and no-license code carries no grant to use it in the first place.

The AGPL trap for hosted products

The verdict logic weights the AGPL heavily for a reason. Because the AGPL treats offering software over a network as a distribution trigger, a single AGPL dependency inside a SaaS product can create an obligation to release the source of the whole service — even though nothing is ever "shipped" to a customer. Teams routinely discover an AGPL component only when an audit surfaces it. For an acquirer, that is not a stylistic note about licensing hygiene; it is a direct question about whether the target's core code has to be made public.

Audit a repo's license compliance. OpenDD's Open Source Due Diligence module reads a public repository's dependency graph, classifies every license with a link to its definition, identifies each dependency's owner, and returns an AGPL/GPL compliance verdict with the specific conflicts flagged. Run an open-source audit →

An automated first pass, not the final word

An automated audit is fast, complete, and consistent — it will not miss a dependency the way a manual review can. What it produces is a first pass: the inventory, the tiers, the owners, and the likely conflicts. The obligations still have to be confirmed against each license, and edge cases — dual licensing, exceptions, linking questions — need a human read. Reading the dependency graph also depends on the repository exposing one, so a project with its dependency graph disabled will need its manifests reviewed directly. Use the audit to find the problems quickly and prioritize them; treat the verdict as a diligence signal, not legal advice.