Open Source Due Diligence: License Risk in the Code
Nearly every software company is built on open source, and nearly every one carries some license risk it has not fully mapped. Open-source due diligence looks at that risk from two directions: the code a company publishes, and the code it consumes. Both can create obligations that outlast the deal — and in a hosted product, one license class can put the company's own source code on the line.
Two directions, two questions
Outbound diligence asks what the company has released to the world. Inbound diligence asks what it has pulled in to build its product. The first is about accidental exposure and copyleft on published code; the second is about the obligations that ride along with dependencies. A complete review does both, because a clean dependency tree means little if the company has been publishing proprietary logic under a permissive license by mistake — or vice versa.
License tiers: the risk ladder
Open-source licenses sort into a few risk tiers, and the tier is what drives the obligation. Permissive licenses (MIT, BSD, Apache) ask little beyond preserving attribution and notices. Weak copyleft (LGPL, MPL, EPL) requires that changes to the component itself be shared, but generally lets you keep your own code separate. Strong copyleft (the GPL family) can require that a distributed product incorporating the code be released under the GPL as well. And network copyleft — the AGPL — extends that reach to software offered over a network, which is the sharpest risk for any SaaS product.
The AGPL problem for hosted products
The AGPL is worth calling out on its own. Because it treats offering software over a network as a trigger, a single AGPL dependency buried in a hosted product can create an obligation to release the source of the whole service. Many teams do not realize a dependency is AGPL until a diligence scan surfaces it. For an acquirer buying a SaaS business, an unnoticed AGPL component is not a footnote — it is a question about whether the company's core code has to be made public.
No-license code is not free code
A repository or dependency with no license file is not "public domain" — under default copyright it is all-rights-reserved, meaning there is no grant to use or redistribute it at all. On the outbound side, a company's own repo published without a license may be exposing proprietary work with no terms attached. On the inbound side, a dependency with no resolvable license is a gap: the company is relying on code it has no documented right to use. Both deserve a flag.
From manifests to an SBOM
Inbound review starts with the dependency manifests — package.json, requirements.txt, go.mod, Cargo.toml, pom.xml — which list what a project pulls in and let each package's license be resolved and classified. A deeper pass reads the repository's full dependency graph, or software bill of materials (SBOM), to catch transitive dependencies the manifest does not name directly. The goal is a complete inventory of what the code actually depends on, each item tagged with its license tier and its obligation.
Compliance is more than a license list
Knowing the licenses is step one; the real question is whether the obligations have been met. Permissive licenses still require that attribution and notice text be preserved in the distribution. Copyleft licenses require reciprocity that a permissively-licensed product may not satisfy. An automated first pass can flag the conflicts — an AGPL or GPL dependency under a permissive project, missing attribution, a no-license package — and turn a raw license list into an actual compliance assessment.
Bound the risk before it is inherited
Open-source obligations do not disappear at closing — they transfer with the code. Mapping the license posture on both sides, flagging AGPL and GPL exposure, and confirming attribution is the difference between inheriting a known, managed obligation and inheriting a surprise. Treat the scan as a first pass to be verified against each license, not legal advice; license interpretation is fact-specific.