The GNU General Public License (GPL) is the most widely used strong-copyleft open-source license: it grants broad freedom to run, study, modify, and distribute software, but requires that anyone who distributes the software or a derivative work do so under the same GPL terms and make the complete corresponding source code available. Written by Richard Stallman and the Free Software Foundation, the GPL exists in two prominent versions — GPLv2 (1991) and GPLv3 (2007) — and licenses foundational software including the Linux kernel (GPLv2), Git, GCC, and much of the GNU toolchain. Its defining trait is "copyleft": the freedoms it grants must be preserved for every downstream recipient.
This article explains how the GPL works in practical terms. It is general information, not legal advice — consult a qualified attorney for decisions about your specific situation.
What the GPL Permits and Requires
The GPL trades broad freedoms for firm reciprocal obligations. The table below summarizes them.
| Category | Details |
|---|---|
| Permissions | Run for any purpose, study and modify the source, distribute copies, distribute modified versions, and use commercially |
| Conditions | Disclose the complete corresponding source; license the whole derivative work under the GPL (copyleft); preserve copyright and license notices; state significant changes; (GPLv3) include installation information for "User Products" |
| Limitations | No warranty; no liability; the license terminates on violation, though GPLv3 adds a cure period |
The pivotal condition is source disclosure on distribution. If you convey GPL-licensed software — or a work that incorporates it — to others, you must provide the complete source code under the GPL so recipients can exercise the same freedoms. Using GPL software privately inside your own organization does not trigger this obligation; the trigger is distribution.
Is the GPL Copyleft or Permissive?
The GPL is the archetypal strong copyleft license. Unlike permissive licenses such as MIT or BSD, which let you relicense derivatives under any terms, the GPL requires that a derivative work as a whole be distributed under the GPL. This is what people mean when they call the GPL "viral": statically linking, incorporating, or otherwise creating a derivative of GPL code generally means the combined work must also be GPL when distributed.
This reciprocity is a feature, not a defect — it guarantees that improvements stay free. But it has significant consequences for anyone wanting to keep proprietary code closed. If you cannot or do not want to release your source, you must avoid creating a distributed derivative of GPL code. Our concepts library unpacks the copyleft-versus-permissive spectrum in more detail, and our comparison pages show how the GPL sits against the weaker copyleft of the LGPL and MPL.
GPLv2 vs GPLv3
The two live versions differ in important ways:
- Patents. GPLv3 adds an explicit patent grant and patent-retaliation provisions; GPLv2 has no explicit patent language.
- Anti-"tivoization." GPLv3 requires that, for consumer "User Products," you provide the information needed to install modified versions — closing a loophole where hardware locks prevented users from running their own modified GPL software. GPLv2 has no such requirement.
- Compatibility. GPLv3 is compatible with Apache 2.0; GPLv2 generally is not. Code under "GPLv2 only" cannot be combined with GPLv3 code, whereas "GPLv2 or later" can move up to v3.
These differences mean you must track not just "GPL" but the specific version and whether the "or later" clause applies.
What the GPL Means for Your Project and Compliance
For engineering teams, the GPL demands more diligence than any permissive license, and the stakes of a mistake are higher.
The central compliance question is do you distribute? Shipping a binary, a device, a container image, or a downloadable application that includes GPL code triggers the source-disclosure obligation. Running GPL software purely as an internal tool or backend service that you never distribute generally does not — although the AGPL variant specifically closes that "network use" gap, so verify you are not actually dealing with AGPL.
The second question is derivative-work boundaries. Combining GPL code with your own can make your code part of a GPL-covered derivative. Where exactly that line falls (dynamic linking, plugins, separate processes) is legally nuanced and fact-specific, which is precisely why teams need an accurate inventory before they can even ask the right questions.
Practically, the safest posture is to know every GPL component you depend on, understand how it is integrated, and confirm that either you comply fully (release source under GPL) or you have architected around it. Many commercial organizations maintain an approved-license policy that flags or blocks GPL in products they intend to ship closed-source. The academy covers how to define and enforce such a policy.
How Safeguard Tracks GPL License Compliance
The single most dangerous GPL scenario is not knowing you have a GPL dependency until after you have shipped. Copyleft obligations do not care that the component was three levels deep in your transitive tree.
Safeguard's Software Composition Analysis scans your entire dependency graph, resolves each component's license, and flags every GPL component — including the specific version and any "or later" qualifier — so copyleft never enters your product unnoticed. Findings are surfaced early, in development and CI, where changing course is cheap.
Those results feed SBOM Studio, which produces a CycloneDX or SPDX software bill of materials recording the exact license of every component. That gives auditors and legal teams a single source of truth about copyleft exposure. Policy gates let you encode your stance — for example, block GPL in distributed products, or require legal review — and evaluate every build against it automatically, turning a potential license violation into a caught pull-request check. Create a free account to see whether any GPL code is hiding in your dependencies, or read the documentation to configure a copyleft policy.
Frequently Asked Questions
Does using GPL software force me to open-source my entire application? Only if you distribute a derivative work that incorporates the GPL code. The copyleft obligation is triggered by distribution, not by use. If you run GPL software internally and never convey it to others, you generally have no source-disclosure obligation. But if you ship a product that includes or is derived from GPL code, the combined work must be offered under the GPL with complete source.
What is the difference between GPLv2 and GPLv3? GPLv3 adds an explicit patent grant, patent-retaliation terms, and anti-"tivoization" provisions requiring installation information for consumer devices, and it is compatible with the Apache 2.0 license. GPLv2 has none of these. Compatibility also differs: "GPLv2 only" code cannot be combined with GPLv3 code, so tracking the exact version matters.
Can I sell software that includes GPL code? Yes. The GPL permits commercial use and sale. What it does not permit is distributing the software under more restrictive terms — recipients must receive the same GPL freedoms and access to source. So you can charge money, but you cannot prevent buyers from redistributing the source, and you must provide it.
Is internal or SaaS use of GPL code a problem? Running GPL software internally, or as the backend of a web service you host, generally does not count as distribution under the standard GPL, so it does not trigger source disclosure. Be careful, though: the AGPL variant explicitly extends copyleft to network interaction, so confirm whether a component is GPL or AGPL before relying on the internal-use exception.