Copyleft in products: the viral question
This is educational material, not legal advice. For decisions that carry real risk, consult a qualified attorney.
Key takeaways Distribution is the trigger — copyleft obligations fire when you ship a derivative to users, not from internal use. SaaS is mostly safe — except AGPL — the GPL doesn’t trigger on network use; the AGPL does. The linking boundary is contested — static vs dynamic matters, but a clean separate-process boundary is the stronger defense. Usable with discipline — copyleft is fine in products if you architect deliberately, and dangerous only if you ignore it.
This is the lesson everyone is secretly worried about. “Copyleft” — the family of licenses led by the GPL — has a reputation for being viral: the fear that touching one GPL file forces you to give away your entire commercial product. That reputation is half-true and half-myth, and the difference is worth real money. By the end of this lesson you’ll know exactly what triggers copyleft obligations, why internal use and most SaaS don’t, where the genuinely contested “derivative work” line sits, and the architectural patterns that let you use copyleft code in a product safely — plus when to just keep it at arm’s length.
What actually triggers an obligation: distribution
The single most important word in copyleft is distribution (the GPLv3 calls it conveying). Copyleft’s source-sharing obligation attaches when you convey the software to someone else — ship a binary, hand over an installer, sell a device with the code on it. Until you distribute, you can do anything you like in private: modify GPL code, link it into your closed product, run it across your whole company. The GPL grants you those rights with no obligation as long as the result stays inside your walls.
This is why the “viral” framing misleads. The GPL doesn’t spread by contact; it attaches a condition to one specific act — distribution. No distribution, no obligation. Three consequences fall out of this:
- Internal use is free. A company can use, modify, and deploy GPL software internally with zero source-sharing duty. Nothing is conveyed.
- Most SaaS is free of GPL obligations. Letting users interact with software over a network is not conveying a copy to them. So a hosted product built on GPL code does not, under the plain GPL, owe users source. (This famous gap is the “ASP loophole.”)
- The AGPL closes the SaaS gap. The AGPL adds a clause that treats network interaction as if it were distribution: if users interact with AGPL software over a network, you must offer them the corresponding source. We return to this below.
“Derivative work” and the linking boundary
When you do distribute, the next question is scope: how much must you release? Copyleft obligations cover the derivative work — the GPL code plus whatever is so tightly combined with it that it counts as one work. Code that is genuinely separate and independent is not covered, even if you ship it in the same package (more on that under “mere aggregation”).
The hard part is that “derivative work” is a copyright concept, not a precise technical one, and the linking boundary is genuinely contested. Here’s the honest state of it:
- The Free Software Foundation’s position is that linking GPL code into your program — static or dynamic — generally creates a derivative work, so the combined program falls under the GPL.
- Many practitioners and some courts focus less on the linking mechanism and more on how intertwined the code is: shared data structures, intimate function calls, and tight coupling point toward a derivative; communication across a clean, stable, arm’s-length interface points toward independence.
- There is no single binding US precedent that resolves dynamic linking cleanly. So treat dynamic linking as safer but not as a magic exemption.
| Combination pattern | Typical risk of being a derivative |
|---|---|
| Static linking (GPL compiled into your binary) | High — widely treated as derivative |
| Dynamic linking (GPL shared library) | Contested — FSF says derivative; weaker boundary than separation |
| LGPL dynamic linking with relink ability | Allowed — the LGPL explicitly permits this for your closed code |
| Separate process, talking over IPC/CLI/socket | Low — strong evidence of independence |
| Two independent programs shipped together | Mere aggregation — not derivative |
LGPL’s relink allowance
The LGPL — “Lesser GPL,” a weak copyleft license — was designed for exactly the linking case. It lets your proprietary program link against an LGPL library while keeping your own code closed, on the condition that the user can replace the library with a modified version. In practice that means dynamic linking (so the user can swap the .so/.dll), or shipping object files for relinking. The library itself stays copyleft — changes to it must be shared — but your application doesn’t.
Safe architectural patterns
Architecture is the lever. The same copyleft component can be a compliance non-event or a problem depending on how you build around it. The guiding principle: the cleaner the boundary, the weaker the case that your code is a derivative.
- Run it as a separate process. Invoke the copyleft tool as its own program — a CLI you shell out to, or a service you talk to over a socket or pipe. Two programs communicating at arm’s length are strong evidence of independence (this is mere aggregation territory).
- Define a clear, stable interface. Talk through a documented protocol, file format, or standard system call, not by reaching into the copyleft code’s internals. Intimacy is what creates derivation; a narrow interface limits it.
- For LGPL, dynamic-link and preserve relink. Use the library as a swappable shared object and document how a user can replace it.
- Keep GPL tools at arm’s length from your product. Using a GPL compiler, build tool, or test harness to produce your software does not make your software GPL — the GPL covers the tool, not its output (unless the output embeds GPL code). Build-time use is generally fine.
- Isolate, don’t intertwine. If you need a GPL component’s functionality, wrap it behind a boundary rather than weaving it through your codebase.
Mere aggregation vs derivative work
The GPL itself draws this line. Mere aggregation — putting independent programs together on the same disk, image, or installer — does not make the aggregate a single work, so your independent program keeps its own license. A Linux distribution is the canonical example: it ships thousands of separately-licensed programs together, and that bundling alone doesn’t relicense any of them. The test is whether the parts are genuinely independent works that merely sit together, versus components fused into one program.
AGPL in a hosted product
The AGPL deserves its own caution because it defeats the usual “SaaS is safe” reasoning. If your hosted product includes AGPL code that users interact with over the network — even unmodified — you must make the corresponding source (including your modifications) available to those users. Many companies respond by banning AGPL outright in their dependency policy, precisely because it’s easy to pull in accidentally and its trigger reaches the hosted model that the plain GPL doesn’t. If you do use it, isolate it behind a clear network boundary and be ready to publish your changes to it.
The bottom line
Copyleft is usable with discipline and fatal if ignored. None of these licenses forbid commercial use, and large products ship copyleft components every day. What they punish is carelessness — statically linking GPL into a closed binary you then sell, or pulling in AGPL without realizing the SaaS trigger. The defense is the same defense as for all compliance: know what you’re shipping (the next lesson), decide deliberately how each copyleft component sits in your architecture, and keep clean boundaries. Do that, and “will it infect my product?” stops being a fear and becomes a design choice.
Quick check: which act triggers the plain GPL's obligation to offer source?
Recap
- Distribution is the trigger — copyleft obligations attach when you convey a derivative to users; private internal use carries no source-sharing duty.
- SaaS is mostly safe — except AGPL — the plain GPL doesn’t trigger on network access, but the AGPL was written to close that exact gap.
- The linking boundary is contested — static linking is high-risk, dynamic linking is safer but not settled, and a separate-process boundary is the strongest defense.
- Architecture controls scope — separate processes, clean interfaces, LGPL relinking, and keeping GPL tools at build-time arm’s length all limit derivation.
- Mere aggregation isn’t derivation — independent programs bundled together keep their own licenses.
- Discipline, not fear — copyleft is fully usable in commercial products when you choose deliberately and keep boundaries clean.
Next up: you can only comply with licenses you know you’re shipping. See Auditing dependencies & SBOMs.
Frequently asked questions
Will using a GPL library force me to open-source my entire product?
Only if you distribute a product that is a derivative work of that GPL code. Using GPL code privately inside your company, or offering it as a hosted service, does not trigger the GPL’s source-sharing obligation (the AGPL is the exception — it triggers on network use). And whether your code is a derivative work depends on how tightly it’s bound to the GPL code, which is exactly what good architecture controls.
Is dynamic linking a safe way around the GPL?
It’s safer than static linking, but it is not a settled legal guarantee. The Free Software Foundation considers most linking — static or dynamic — to create a derivative work. Many lawyers treat a clean, arm’s-length boundary (separate process, stable interface) as far stronger evidence of independence than dynamic linking alone. For the LGPL specifically, dynamic linking plus a relink mechanism is explicitly permitted.
Does running GPL software on my servers (SaaS) trigger anything?
Under the plain GPL, no — making software available over a network is not ‘distribution’ in the GPL’s sense, so there’s no obligation to share source with users. The AGPL was written precisely to close that gap: if users interact with AGPL software over a network, you must offer them the corresponding source. So the answer is license-specific.