AGPL and copyleft exposure in diligence.

AGPL and copyleft exposure in diligence is the part of a software deal that buyers most often miss and most often regret. The product looks clean. The revenue is real. Then a dependency review surfaces a GNU AGPL component sitting inside the hosted service that drives that revenue, modified at some point by an engineer who has since left, and suddenly the question is not whether the deal is good but what it actually costs to keep the product running the way it runs today. Copyleft obligations do not announce themselves. They live in the dependency tree, and they attach to software regardless of whether anyone read the license at adoption.

This is diligence work, and it sits inside the wider discipline of finding and pricing open source risk in a transaction. The full treatment of that discipline lives in the pillar on open source M and A and compliance. Here the focus is narrower: the copyleft family, the AGPL network clause in particular, and how both show up when you look at a target closely.

What copyleft actually obligates a buyer to do

Copyleft is the family of open source licenses that requires derivative works to carry the same license and to make source available under defined conditions. The GPL is the canonical example. It is OSI approved open source, which means it is freely usable, but the freedom comes with a condition: if you distribute software that incorporates GPL code, you must offer the corresponding source under the same terms. For a buyer, the risk is not the license itself but the surprise. A target that built proprietary value on top of strong copyleft code may have an obligation to release that value as source if the product is distributed in the wrong way.

The strength of the obligation varies across the family. Permissive licenses such as MIT carry almost none. Weak copyleft such as the LGPL confines the obligation to the modified component. Strong copyleft such as the GPL and the GNU AGPL reaches further. Knowing which category each component falls into is the first move, and the glossary entry on copyleft sets out the distinctions plainly.

Why the AGPL network clause is the one that bites

Most copyleft obligations trigger on distribution, the act of handing software to someone else. Many software targets never distribute anything. They run their product as a hosted service and let customers reach it over a network. Under the GPL, that pattern can sidestep the source sharing obligation entirely, a gap often called the application service provider loophole. The GNU AGPL closes it. Its network clause treats offering modified software to users over a network as the kind of conveyance that triggers the obligation to provide the corresponding source. For a target whose entire business is a hosted service, that is not an edge case. It is the core operating model.

So the AGPL deserves separate attention in any deal involving a software as a service company. A single modified AGPL library inside the production stack can, depending on how it is used and exposed, carry an obligation to make source available to every user of the service. The glossary entry on the GNU AGPL covers the mechanics, but the diligence point is simple: find every AGPL component, establish whether it was modified, and document how it is exposed, then put those findings in front of counsel.

Where the exposure hides in a target codebase

Copyleft exposure is rarely in the dependency the target chose deliberately. It hides three layers down. The first place is the transitive tree, the dependencies of dependencies that the engineering team never selected and may not know it carries. A clean list of direct dependencies tells you almost nothing about copyleft risk, because the AGPL component is usually buried beneath something benign. The second place is modified open source, where the team forked a library years ago, changed it, and never tracked the license that came with it. The third place is the relicensed component, where the project shipped under a permissive license at adoption and changed terms later, a pattern the recent relicensing wave made common.

Finding all three requires a full tree review rather than a glance at the manifest. The systematic version of that review is set out in the open source due diligence checklist, which walks the tree, captures the license state of every node, and flags the components that need a closer read. The checklist is where copyleft findings come from. This article is about what to do with them once they surface.

Turning a copyleft finding into a deal term

A finding only matters if it changes the deal. The path from one to the other runs through a cost estimate. For each copyleft obligation that the buyer is not willing to live with, the remediation has a price and a timeline: rebuild the affected component, replace it with a permissively licensed alternative, buy a commercial license from the project where one exists, or change the way the product is delivered so the obligation does not trigger. Each option carries an engineering cost and a schedule, and the sum is the number that belongs in the deal. The mechanics of attaching that number are covered in quantifying open source risk for a deal.

Once the cost is known, the buyer has options that vanish after close. The remediation cost can come off the purchase price. The seller can be asked for a representation that the codebase carries no undisclosed copyleft obligations, backed by an indemnity. The closing can be conditioned on the target curing the highest risk items first. None of these is available to a buyer who finds the AGPL component after the wire has cleared. The relicensing angle, where a component changed terms inside the target after adoption, is treated in relicensing exposure in an acquisition target.

Doing the work on a deal timeline

Diligence runs on a clock, and copyleft review has to fit inside it. The pragmatic sequence is to pull a complete bill of materials early, scan the full tree for copyleft and AGPL components rather than only direct dependencies, isolate the ones that touch the product the buyer is paying for, and reserve deep manual review for that short list. Most components on the list will be unmodified and used in ways that carry no real obligation. A few will not be, and those few are where the value of the review sits. The aim is not to flag every copyleft license in the tree. It is to find the handful that change the deal and put a defensible cost against them.

AGPL and copyleft exposure in diligence rewards the buyer who looks before the deal closes and penalizes the one who looks after. Find the network clause where it hides, size the remediation, and convert the finding into a price adjustment, a representation, or a closing condition while there is still leverage to do so. This article is commercial and licensing risk advisory, not legal advice. For interpretation of the AGPL or any copyleft license and for your compliance obligations, your own counsel is the right place to turn.