Legal summaries of the GNU General Public License tend to either oversimplify it into "you must open-source everything" or bury the actual rule in clauses nobody reads twice. Here's the GPL license explained without either problem: the GPL is a copyleft license, meaning that if you distribute a modified version of GPL-licensed code, or a work that incorporates it in specific ways, you're required to distribute your own source under the same license. The trigger condition — what counts as "incorporating" it — is where most of the real confusion lives.
What does the GPL actually require?
The GPL requires that if you distribute software built on GPL-licensed code, you must make the corresponding source code available under the same GPL terms. This is the "copyleft" mechanic: unlike a permissive license, the GPL doesn't just require attribution — it requires that derivative and combined works carry the same freedoms forward. Concretely, this means:
- If you modify a GPL-licensed program and distribute the modified version, you must distribute your modifications under the GPL too.
- If you statically link your own code against a GPL library and distribute the resulting binary, the GPL's terms generally extend to the combined work.
- The obligation is triggered by distribution, not by internal use — running modified GPL code privately, without distributing it, doesn't trigger the source-release requirement under GPLv2 or GPLv3.
When does the GPL not apply to your own code?
The GPL doesn't apply to your own code when you're not distributing a combined or derivative work — using a GPL-licensed tool as a separate process (calling a CLI tool, for instance) is generally treated differently than linking a GPL library directly into your binary. This distinction is exactly why the LGPL (Lesser GPL) exists as a separate, more permissive variant: it was written specifically to allow linking without extending copyleft to the linking application. Practically:
- Invoking a GPL-licensed binary as a subprocess (not linking its code) is commonly treated as separate from the GPL's reach, though this has been debated and isn't universally settled case law.
- The LGPL exists specifically to relax the linking restriction for libraries, letting proprietary applications link against LGPL code without inheriting copyleft.
- SaaS-only use historically sat outside GPL's distribution trigger entirely — which is the specific gap the GNU Affero General Public License was written to close by extending the obligation to network use.
How is GPLv3 different from GPLv2?
GPLv3 adds explicit patent grant language and an anti-tivoization clause that GPLv2 didn't have, closing loopholes that emerged after GPLv2 was written in 1991. GPLv2 predates modern patent litigation concerns and hardware lock-down practices, so GPLv3 was drafted to address both: it includes an express patent license from contributors, and it requires that if GPLv3 code ships on consumer hardware, users must be able to install modified versions of that code on the device. Teams choosing between the two should know:
- GPLv3's patent clause offers more explicit protection against contributors later asserting patent claims against users of the same code.
- The anti-tivoization clause is why some hardware vendors specifically avoid GPLv3 dependencies in embedded firmware.
- GPLv2-only projects (the Linux kernel is the best-known example) deliberately haven't relicensed to GPLv3, in part over disagreement with these additions.
Why does this matter for a dependency tree, not just a single file?
It matters because GPL obligations propagate through transitive dependencies, and most teams don't manually audit every package three levels deep in their node_modules or vendor directory. A permissively-licensed application can unknowingly pull in a GPL-licensed transitive dependency through an unrelated package update, and the obligation doesn't announce itself — it just sits there until a license audit or an acquisition due-diligence review finds it. This is the specific gap software composition analysis tools are built to close: flagging copyleft licenses anywhere in the dependency graph, not just in top-level, directly-added packages.
FAQ
Is the GPL "viral," as critics sometimes claim?
The term is contested. Copyleft does propagate to derivative and combined works under specific conditions, which critics call viral and supporters call "ensuring downstream freedom" — the practical effect (obligations flowing to combined works) is the same regardless of the label.
Can a company sell GPL-licensed software?
Yes. The GPL doesn't prohibit commercial sale — it requires that if you distribute the software, recipients get the source and the same rights to modify and redistribute it, not that it must be free of charge.
What's the difference between GPL and the GNU Affero General Public License?
The GNU Affero General Public License adds a network-use clause: it extends the source-disclosure obligation to software offered over a network (like a SaaS product) even without traditional distribution, closing a gap standard GPL doesn't cover.
Does using a GPL tool in your build pipeline affect your own code's license?
Generally no, if the tool runs as a separate process during build and isn't linked into or distributed with your application — but this depends on how the tool is used, and merits a specific look rather than a blanket assumption.