Copyleft Distribution Obligations Explained

Most open source compliance failures are not failures to read a license. They are failures to understand when its obligations switch on. Copyleft licenses do not demand that you publish your source the moment you use the code. They attach the demand to a specific event, usually distribution, and the entire assessment of risk turns on whether your software model crosses that line. A team that treats copyleft as either harmless or radioactive, without asking which event triggers it, will either carry hidden exposure or avoid useful components for no reason. The accurate position sits between those two errors, and reaching it means understanding the trigger precisely.

What copyleft distribution obligations actually require

A copyleft license grants broad rights to use, modify, and share the software on one condition: that you pass those same rights downstream. Under a license such as the GPL, when you distribute a covered work, you must make the corresponding source available to the recipient under the same license. The obligation is reciprocal by design. You receive the freedom to build on the code, and in return you preserve that freedom for whoever receives what you build. The practical effect is that you cannot take copyleft code, modify it, ship the binary, and keep your changes private. The source that corresponds to what you shipped travels with it.

The scope of corresponding source is the part that surprises teams. It is not only the copyleft file you edited. Depending on the license and how the code is combined, the obligation can reach the larger work that the copyleft component is part of. This is why the boundary between a copyleft component and the rest of a product matters so much in an acquisition, and why diligence has to look at how the code is linked and combined, not only at the license name on a single file.

When does distribution trigger the obligation

Distribution, in the copyleft sense, generally means conveying the software to someone outside your organization. Shipping a product that contains the code, handing over a binary, embedding the component in a device you sell, or delivering software to a customer to run themselves all tend to count. Once that conveyance happens, the source obligation attaches and the recipient is entitled to the corresponding source under the same terms. The act of delivery is the switch.

What classically does not count is running the software for yourself. If you modify a copyleft component and use it internally, without conveying it to a third party, ordinary copyleft licenses do not require you to publish anything, because there has been no distribution. This is the distinction that makes internal tooling far lower risk than shipped product, and it is the first thing a sound assessment establishes: where in the estate copyleft code is merely used, and where it is actually distributed. The two carry very different exposure.

How the GNU AGPL extends the reach to network use

The internal use carve out created an obvious gap. A company could modify copyleft software, never distribute it, and offer it to the world as a hosted service, all without triggering any source obligation, because running a service for remote users was not distribution. The GNU AGPL was written to close that gap. It adds a network use clause: if you modify AGPL covered software and let users interact with it remotely over a network, you can be required to offer those users the corresponding source. The trigger moves from conveying a copy to providing access to the running service.

For any business built on software as a service, this is the obligation that matters most, because the usual comfort of we never distribute anything does not hold under the GNU AGPL. A modified AGPL component three layers down, feeding a customer facing endpoint, can carry a source offer obligation that the product team never accounted for. The precise definition of the license is worth reading carefully, and the glossary entry on the GNU AGPL sets it out, alongside the entry on the source available license category that copyleft is sometimes confused with.

Why this matters in a deal

In an acquisition, copyleft distribution obligations are where the largest compliance gaps tend to hide, because the obligation is invisible while the software simply runs. A target may have shipped product containing copyleft code for years without ever satisfying the source obligation, or may run an AGPL component inside a hosted service without recognizing the network use trigger. Neither shows up in normal operation. Both pass to the buyer on close, along with the cost of curing them. This is exactly the kind of finding that has to be sized and priced, and the method for doing so is set out in quantifying open source risk for a deal. A worked example of how it surfaces appears in relicensing exposure in an acquisition target, and the wider diligence discipline sits on the open source in M and A and compliance pillar.

Assessing a copyleft obligation correctly depends on facts that only the target's own systems reveal: how the code is combined, whether it is distributed or merely used, and whether any service offers a modified AGPL component to remote users. Getting those facts is the work. Because we are independent and buyer side, take no vendor fees, and resell no software, the assessment reflects the buyer's exposure and nothing else, including when the honest answer is that a copyleft component is used internally and carries no real obligation at all. This is commercial and licensing risk advisory, not legal advice. Whether a specific obligation is triggered by your distribution or service model is a question for counsel, and we recommend you engage your own.

IN THIS CLUSTER

Read next on open source in M and A and compliance.