º£½ÇºÚÁÏ

This post uses hypothetical scenarios for illustrative purposes only. It does not describe any actual client, transaction, or representation, and is not legal advice.

Imagine a software acquisition where the target’s IP representation is a thing of beauty: the company owns all right, title, and interest in its products, free and clear. Then the buyer runs a composition scan on the codebase and the report comes back showing the product is roughly 80% open source components. Nobody lied. That number is normal — modern commercial software is assembled on open source rails, and a codebase that wasn’t would be the diligence red flag. The question that matters is not how much open source is in the stack. It is whether any of it came with conditions that reach the 20% the buyer is actually paying for.

Copyleft is a condition, not a contamination

Open source licenses sort into two families. Permissive licenses — MIT, BSD, Apache 2.0 — ask little: preserve copyright notices, include the license text, and in Apache’s case respect a patent grant that terminates for entities that sue over the covered code. Compliance failures under permissive licenses are real but curable, mostly a matter of shipping the right notices file. Copyleft licenses are a different instrument. The GNU General Public License — the full text is short enough to read at — conditions the right to distribute a covered work on licensing the entire work, as a whole, under the GPL, source code included. Combine GPL code with proprietary code into one program and convey that program to customers, and the license’s terms apply to the combination. The industry shorthand “viral” overstates the mechanism — GPL obligations do not seep through a codebase by contact; they attach when a company chooses to distribute a combined work — but understates the stakes, because for a company whose product is its source code, an obligation to release that source on request is an existential term, not a compliance detail.

The scope fights are all about boundaries. Distribution is the classic trigger, which is why pure SaaS companies long treated the GPL as a non-issue: code executed on the company’s own servers is not conveyed to anyone. The Affero variant, AGPL, was written to close exactly that gap — it extends the source-sharing obligation to users who interact with the software over a network — which is why AGPL components inside a SaaS stack get flagged in every serious scan, and why some acquirers maintain flat internal prohibitions on them. Linking is the other boundary: LGPL permits proprietary applications to link against covered libraries under conditions, while the question of whether dynamic linking to full-GPL code creates a combined work has been argued for decades without a clean judicial answer. Diligence lives in those gray zones, and the honest work product is a map of which components sit on which side of which boundary, not a declaration of victory.

The license anticipates your deal, and the courts will enforce it

Two legal facts elevate this from engineering hygiene to deal risk. First, open source licenses are enforceable, and not merely as contracts. In Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008), the court held that open source license terms operate as conditions on the copyright license itself — violate the conditions and you are not a breaching licensee but an infringer, exposed to copyright remedies including injunction and statutory damages. Enforcement is no longer theoretical or purely ideological: component copyright holders, commercial open source vendors, and, in a newer wave, monetization-minded plaintiffs have all brought compliance suits, and the settlements tend to include audit rights and compliance undertakings that outlive the case.

Second, the GPL saw the acquisition coming. Version 3 defines an “entity transaction” as one “transferring control of an organization, or substantially all assets of one” — that is Section 10 of the license, and the phrase describes a merger, an equity sale, and an asset deal with equal precision. The section provides that each party to such a transaction receives whatever licenses the predecessor had, alongside the license’s flat prohibition on imposing further restrictions downstream. The practical meaning for a buyer: the target’s open source rights and its open source obligations both travel with the deal, and no purchase agreement provision between buyer and seller can modify what the license requires vis-à-vis the outside world. You can allocate the risk; you cannot draft it away.

What diligence actually looks for, and what the agreement does about it

The diligence sequence has become standardized in tech deals. The buyer requests the target’s open source policy and component inventory, then runs an independent composition scan and compares the two. The gap between what the company thinks it ships and what it ships is the real finding — a target with a maintained software bill of materials, or SBOM, is telling the buyer its engineering organization has controls; a target that has never inventoried its dependencies is telling the buyer the reps are guesses. This is the same maturity signal that runs through the security workstream I described in the post on cybersecurity diligence in tech M&A, and it feeds the same classification exercise covered in why classifying the technology comes first: what does the target actually own, what does it license in, and what is the proprietary core the price is really buying?

Findings sort into three buckets, in ascending order of pain. First, notice and attribution failures — missing license files, stripped headers. These are remediation items, fixed in a sprint, rarely priced. Second, copyleft components in distributed proprietary code — the finding that generates real negotiation. The remediation menu is short: remove and rewrite the component, architect a boundary that separates the works, obtain a commercial license from the copyright holder where one is sold (dual licensing is a business model precisely because of deals like this), or, rarely, comply by opening the source. Which option is feasible determines whether the fix is a covenant, a closing condition, an escrow, or a price adjustment — and where remediation drags past closing, the holdback mechanics resemble the ones in my post on post-closing software disputes and escrows. Third, license-term landmines with no engineering fix — an AGPL dependency at the heart of the product, or a component whose license the target has already violated in ways that accrued copyright exposure. Those are diligence findings in the old-fashioned sense: they change what the asset is.

One newer wrinkle deserves its own line in the scan request. Over the past several years a number of prominent infrastructure projects moved from open source licenses to source-available terms — the SSPL and BUSL families — that permit inspection but restrict commercial use, particularly offering the software as a service. A target that adopted a component while it was permissively licensed and kept upgrading past the relicensing date may be running versions under terms nobody in the building has read. Version pinning is suddenly a legal question: which release did the target actually incorporate, and under which license did that release ship?

On the paper side, the buyer’s package is settled practice: a representation that the disclosure schedule lists all open source materials incorporated into or distributed with the products, identifying the license for each; a representation that no copyleft-licensed code has been incorporated into, combined with, or used in a manner that requires the target’s proprietary source code to be disclosed, licensed to third parties, or made available at no charge; and a compliance rep covering notice obligations. Sellers push back with knowledge qualifiers and materiality; buyers concede knowledge on compliance history but rarely on the disclosure-triggering rep, because that one is checkable — the scan either finds the copyleft component in the shipped artifact or it doesn’t. The rep is less a lie detector than a schedule-forcing device: it makes the target do the inventory it should have maintained all along.

If you are buying or selling a software company and the codebase question is starting to feel like the deal, feel free to reach out to my firm manager, Magda, at Magda@montague.law, or fill out our contact form. Mention you read this post.