GPL License
GPL License
Definition: A “copyleft” open-source license requiring that any derivative work built on GPL-licensed code must also be released under the GPL, with source code made available.
How It Works
- Copyleft: if you distribute software that incorporates GPL code, you must also release your combined work’s source code under the GPL
- The obligation triggers on distribution, not on private or internal use, running GPL code inside your own company creates no obligation to anyone
- “Distribute” includes shipping binaries to customers, not just publishing source, a compiled proprietary-looking app can still carry GPL obligations if it embeds GPL code
- Linking matters: statically or dynamically linking your code against a GPL library generally makes your program a derivative work, subject to the same GPL terms
- Merely invoking a GPL program as a separate process (shelling out to a CLI tool, calling it over a pipe) is generally treated differently from linking against it, though the line isn’t always sharp and depends on how tightly coupled the programs are
- LGPL (Lesser GPL) relaxes this specifically for linking against libraries, letting proprietary code link an LGPL library without the whole application becoming GPL
- Selling GPL software is explicitly allowed, the license restricts what you can do to recipients’ freedoms, not whether you can charge money for a copy
- Plain GPL has a well-known gap: running modified GPL code as a network service (SaaS) without distributing binaries doesn’t trigger the source-release requirement, since no copy is “distributed” to users, they just talk to it over a network
- AGPL (Affero GPL) was created specifically to close that SaaS gap, adding a network-use trigger that plain GPL doesn’t have
- Different from permissive licenses like MIT and Apache 2.0, which impose no requirement on derivative works at all
- “Mere aggregation,” placing a GPL program alongside unrelated, separate programs on the same disk, distro, or app bundle without combining their code, does not turn the other programs into derivative works
- The “source code” requirement means the preferred form for making modifications, not just any human-readable text, minified or obfuscated output doesn’t satisfy it
- Recipients of GPL-licensed binaries must also receive (or be able to easily obtain) the exact corresponding source, not just “some version” of it
- The obligation runs to the people who received the software, not to the public at large, GPL doesn’t require posting source publicly online, just making it available to actual recipients
- Anti-tivoization provisions in GPLv3 additionally require that, for consumer hardware, users be able to install their own modified version of the software on the device they bought
GPLv2 vs GPLv3, Briefly
| GPLv2 | GPLv3 | |
|---|---|---|
| Patent grant | Not explicit | Yes, explicit patent grant and retaliation clause |
| Anti-tivoization | No | Yes, blocks hardware that refuses to run modified versions of the software |
| Compatible with Apache 2.0 | No | Yes, one-way, Apache 2.0 code can be combined into a GPLv3 work |
| License-version flexibility | Some projects are strictly “GPLv2 only” | Adds an “or later” option many projects adopt |
Under the Hood
Given: You modify the Linux kernel for a router your company manufactures, then ship the router with the modified kernel binary to retail customers. Step: Check whether distribution occurred. Answer: Yes, shipping the device to customers is distribution. You must make the corresponding modified kernel source available to those recipients under GPL, this is exactly why router and embedded-device vendors maintain “GPL source code” download pages.
Given: Your company uses GCC (GPL-licensed) internally to compile your fully proprietary application, and separately runs some GPL-licensed scripts in your internal CI pipeline, neither is ever handed to anyone outside the company. Step: Check the distribution trigger again. Answer: No obligation. Compiling with a GPL compiler doesn’t make your output GPL (GCC’s own license says so explicitly), and internal-only use of GPL tooling never reaches a recipient outside the company, so copyleft never activates.
Given: You bundle a GPL-licensed text editor alongside your unrelated proprietary application on the same installer disk or app store bundle, with no shared code or linking between them. Step: Check whether this counts as combining works or “mere aggregation.” Answer: Mere aggregation. Two independent programs distributed together, without one incorporating or linking against the other, stay under their own separate licenses. Your proprietary app has no new GPL obligation just from sharing a disk image with GPL software.
Given: You build a plugin for a GPL-licensed content management system that hooks deeply into its internals, calling its functions directly, and you distribute the plugin to customers. Step: Check whether the plugin counts as a derivative work of the platform. Answer: Tightly coupled plugins that call into GPL code as if extending it are generally treated as derivative works by the FSF’s own guidance, which is why many plugin ecosystems built on GPL platforms end up GPL-licensed themselves, even when developers intended otherwise.
Why It Matters
- Using GPL-licensed code inside a proprietary, closed-source commercial product you plan to distribute can create real legal obligations to release your own source, a decision many companies deliberately avoid
- It keeps derivative works of GPL software free and open permanently, someone can’t take a GPL project, add proprietary improvements, and ship a closed fork
- Companies building on Linux (which is GPLv2) have to structure their stack carefully, kernel modules and drivers often stay separate from proprietary userspace code specifically to manage this boundary
- The SaaS-use gap in plain GPL (versus AGPL) is a real strategic consideration for companies that want to build on copyleft code but avoid open-sourcing a web service
- It protects contributors’ work from being absorbed into a closed-source competitor’s product without giving anything back to the community
- Large companies maintain formal open-source compliance programs largely because of GPL, scanning every dependency tree for copyleft licenses before a product ships
- Some companies dual-license their own software (GPL for the free/community tier, a commercial license for paying customers who don’t want copyleft obligations), turning the license itself into a business model
- Understanding the linking-versus-separate-process distinction matters for architecture decisions, teams sometimes design a system as separate processes specifically to keep a GPL dependency at arm’s length
- Enterprises evaluating open-source infrastructure often budget extra legal review time specifically for GPL and AGPL dependencies, compared to the near-automatic approval permissive licenses get
- The Free Software Foundation designed GPL specifically to guarantee end users the freedom to run, study, modify, and share software, treating that as a right worth legally enforcing, not just a preference
Common Pitfalls
- Accidentally including a GPL-licensed dependency inside a closed-source commercial product without realizing the obligation it creates
- Confusing GPL with LGPL, they have meaningfully different implications for linking against a library versus incorporating its code directly
- Assuming that because a SaaS product never ships a binary, GPL never applies, true for plain GPL, false for AGPL-licensed dependencies
- Believing internal, never-distributed use of GPL code is risky, it isn’t, the trigger is distribution to someone outside your organization, not use itself
- Treating “linking” and “merely running as a separate process” as interchangeable, courts and the FSF’s own guidance treat them differently, and the distinction affects whether your code counts as a derivative work
- Mixing GPL and Apache 2.0 code and assuming compatibility, GPLv2 in particular is generally considered incompatible with Apache 2.0 due to extra conditions Apache imposes
- Assuming a “GPL-licensed platform plugin” (like a WordPress plugin) can be sold under a proprietary license, the platform’s own GPL terms often extend the obligation to plugins that hook into its code
- Forgetting that GPLv2-only projects can’t simply upgrade to GPLv3 code without explicit permission, version compatibility isn’t automatic
- Assuming a company can silently drop the “or later” clause from GPLv2-or-later code they modify, once you redistribute, the original licensing options generally still apply to recipients
- Shipping only obfuscated or minified code as the “source,” the GPL requires the preferred form for making modifications, not just technically-readable output
- Assuming GPL forbids charging money for the software, it doesn’t, you can sell GPL software, you just can’t restrict what the buyer does with the source afterward
- Underestimating the anti-tivoization clause in GPLv3, hardware vendors that lock down devices to reject modified firmware can run into real compliance problems if the firmware includes GPLv3 code
- This is informational content, not legal advice, consult a lawyer for real license compliance decisions
Comparison
| GPL | MIT | Apache 2.0 | |
|---|---|---|---|
| Copyleft | Yes, derivative works must also be GPL | No | No |
| Patent grant | Yes (GPLv3), weaker/implicit in GPLv2 | No | Yes, explicit, with retaliation clause |
| Attribution requirement | Yes, plus source code availability | Yes, copyright notice and license text | Yes, notices plus NOTICE file |
| Compatible with proprietary/closed-source use | No, without also open-sourcing the derivative | Yes | Yes |
| Triggers on internal-only use | No, only on distribution | No conditions either way | No, only on distribution |
| Covers SaaS/network use | No (plain GPL), yes under AGPL | N/A | No |
| Typical use case | Software wanting to stay free/open forever | Small libraries, quick adoption | Corporate-backed infrastructure projects |
| Trademark rights granted | No | No | No |
| License length | Long, formal legal text | Very short, a few paragraphs | Long, formal legal text |
| “Mere aggregation” exemption | Yes, unrelated bundled programs stay separate | N/A, no conditions to trigger | N/A, no conditions to trigger |
| Has a “weaker” sibling variant | Yes, LGPL for library linking | No | No |
| Warranty disclaimer | Yes, “as is” | Yes, “as is” | Yes, “as is” |
| Requires stating changes to modified files | Not explicitly (source availability covers it) | No | Yes |
| Can be sold for money | Yes | Yes | Yes |
| Anti-tivoization / device lockdown restriction | Yes (GPLv3 only) | No | No |
Example
Linux itself is GPLv2-licensed, meaning any modifications to the Linux kernel source code that get distributed must also be released under the GPL, which is why kernel patches from companies like Intel and Red Hat flow back into the public source tree. Git, the version control tool, is also GPLv2-licensed.
WordPress core is GPLv2-licensed, and the GNU Compiler Collection (GCC) and Bash are both GPLv3-licensed, three very different, widely deployed tools that all share the same copyleft foundation.
Related Terms
Referenced by