Open source licenses: the quiet risk in the codebase
Every commercial codebase is mostly other people’s code. Pull the dependency tree of a typical SaaS product and the team’s own work sits on top of thousands of open source packages, each with a license attached. Open source license due diligence is the exercise of checking that the target actually has the right to sell what is built on all of that.
The honest summary up front: in most deals this check comes back clean, or clean enough. The typical modern stack is MIT, Apache and BSD all the way down, and those licenses ask almost nothing. But the exceptions are real, they are cheap to find, and when one lands it lands on the lawyers’ table at the worst moment of the deal. So the review is worth an afternoon of scanning and a focused hour of triage, and rarely more.
What open source license due diligence actually flags
The findings that matter form a short list, and it starts with copyleft in the wrong place.
For a SaaS business the license to care about is AGPL. Ordinary GPL obligations trigger on distribution, and a SaaS product does not distribute its backend, which is why GPL components server-side are usually a non-issue. AGPL closes exactly that loophole: its network clause extends the obligations to software users interact with over a network. An AGPL library at the core of a SaaS backend, without a commercial license alongside it, is a genuine finding with two honest exits, replace the component or buy the commercial license, and both belong in the remediation plan with a cost attached.
For software that ships, embedded products, on-prem deployments, mobile apps, classic GPL is back in scope and the analysis is older and better charted. The remaining entries on the list: code copied from sources with no license or a non-commercial one, and dual-licensed components used past what the free tier permits. All findable, all fixable, all better found before signing than after.
Everything else is mostly lawyer theater. A four-hundred-line spreadsheet of permissively licensed packages flagged "for review" is diligence performed at the buyer, not for them. The attribution obligations of MIT and BSD are met with a notices file. Weak-copyleft findings around dynamically linked libraries almost never survive contact with an actual analysis. Part of our job in the review is to shrink the list to the entries that could move money.
Upstream license changes
A newer pattern worth checking explicitly: components that changed license above the target’s head. The infrastructure world has seen a string of these moves, Elastic in 2021, HashiCorp’s switch of Terraform to the Business Source License in 2023, Redis in 2024, each pushing prominent projects from open source licenses to source-available terms that restrict commercial use.
The exposure is rarely "the target is now violating the new license", because old versions remain under their old terms. The exposure is quieter: a team pinned to the last open version of a package is pinned to something that no longer receives security patches, and the eventual migration, to a fork, to the commercial edition, to a replacement, is unbudgeted work sitting in the roadmap’s blind spot. So the diligence question is not "do you use Terraform" but "which license epoch are you on, what is the plan, and what does it cost". A team that has already thought this through tells you something good that goes beyond licensing.
The AI-generated code wrinkle
The new question in 2026: when a meaningful share of the codebase was written by coding agents, who owns it, and what license is it under.
The realistic view, as of this writing: the practical risk for ordinary generated code is low. Models trained on public code can in principle reproduce licensed snippets, the ongoing copyright litigation around training data has not produced clear rules, and acquirers’ counsel have started asking about it in every deal. What separates targets is not exposure, which nobody can size precisely, but posture: does the team know which tools generated what, are provenance or duplication filters enabled where the tools offer them, is there a policy at all. A team that can answer those three questions in a sentence each is fine. A shrug is a small finding that costs nothing to fix and says something about how the team absorbs new categories of risk. The deeper questions raised by heavily generated codebases go well past licensing, and we treat them separately in due diligence on a codebase the founders barely wrote.
How the review actually runs
In a deal window the mechanics are simple, and we run them inside every technical and AI audit. A software composition analysis scan against the dependency manifests takes an afternoon and catches the overwhelming majority of what matters. Snippet-level scanning, which fingerprints the code itself against known sources, we reserve for embedded software and for targets where copy-paste provenance is a live concern, because it is slower and noisier.
Then the human part: triage the scanner’s output down to the handful of findings that could move money, and put them to the team. Their reaction is data in itself. The teams that respond with "yes, we know, here is the ticket" are the same teams whose repos pass every other test; the correlation holds across everything else we read in a codebase.
License review is one strand of a full read, usually a small one, occasionally the strand that saves a closing from an ugly surprise. Size it to the target, not to the fear.