The GNU General Public License is the best-known copyleft license, but in practice there is no single "GPL": there are mainly two versions in use, version 2 from 1991 and version 3 from 2007. They share the same spirit, ensuring that whoever receives the program also receives the freedom to study, modify and share it, but they differ on points that carry real practical weight today. Many projects say "GPL" without specifying the version, and that ambiguity creates doubt exactly when clarity is needed.
The common core
Both versions share the same basic rules:
- anyone who distributes the program, original or modified, must offer the corresponding source code;
- distributed derivative works must remain under the same license;
- no further restrictions can be added to the recipients' rights;
- private and internal use carries no publication obligations.
The differences come from problems that emerged in the sixteen years between the two versions.
The main new features of GPLv3
1. Protection against "tivoization"
The term comes from a well-known case: a device that used GPL software and made its source available, but used cryptographic signatures to prevent modified versions from running on the hardware. GPLv2 was formally respected, but the freedom to modify the software existed only on paper.
GPLv3 introduces Installation Information: for "User Products", meaning devices intended for private consumer use, whoever distributes the software must also provide the keys or instructions needed to install modified versions. The obligation does not apply to equipment intended exclusively for business or industrial use, and it does not require continued support for those who modify the device.
2. Patents explicitly addressed
GPLv2 dealt with patents indirectly. GPLv3 contains an explicit patent license: every contributor grants recipients the rights to their own patents needed to use their contribution. It also tackles arrangements in which a distributor obtains patent protection only for some of its customers, extending that protection to all recipients.
3. Technological measures and anti-circumvention laws
GPLv3 states that software under this license does not constitute an "effective technological measure" for the purposes of laws prohibiting the circumvention of protection systems. In practice, whoever distributes GPLv3 code waives the right to use those laws against people who modify the software.
4. Gentler handling of violations
Under GPLv2, a violation automatically terminated your rights. GPLv3 provides a reinstatement mechanism: if the violator fixes the problem, rights are restored, provisionally and then permanently if the copyright holder does not object within a certain period; and anyone who cures a first violation within thirty days of receiving notice gets their rights back. It is an approach designed to encourage compliance rather than punishment.
5. Compatibility with other licenses
GPLv3 is compatible with the Apache 2.0 license, which is incompatible with GPLv2. It also allows certain "additional permissions" and a limited number of extra conditions listed in the text, which makes combining it with other licenses easier.
6. Less US-centric language
GPLv3 uses terms such as "propagate" and "convey" instead of "distribute", to reduce dependence on concepts specific to a single legal system.
The "or later" clause
Many projects state "GPL version 2 or, at your option, any later version". This wording lets recipients use the code under the terms of GPLv3. Other projects choose "GPLv2 only": the best-known case is the Linux kernel, which remained under GPLv2 without the later-versions clause.
| Statement | Can be combined with GPLv3 code? |
|---|---|
| GPLv2 or later | yes, the whole becomes GPLv3 |
| GPLv2 only | no |
| GPLv3 only | yes |
| GPLv3 or later | yes |
The consequence matters: "GPLv2 only" code and GPLv3 code cannot be joined in a single derivative work. Before integrating two components, read the file headers, not just the license name in the README.
Which one to choose for a new project
There is no answer that fits everyone, but some criteria help:
- Software for devices (firmware, consumer embedded systems): GPLv3 genuinely protects the ability to modify.
- Projects that want to combine with Apache 2.0 code: GPLv3 avoids incompatibilities.
- Projects with corporate contributors worried about patents: GPLv3's explicit license clarifies the rules, although some companies see it as a constraint.
- Projects that must integrate with a "GPLv2 only" ecosystem: staying on v2 may be unavoidable.
In my work, when a client asks for a technical opinion, the first question is always: which other components will this code have to live with? Compatibility often decides the matter, even before preferences.
How to declare it correctly
A clear statement removes most doubts:
SPDX-License-Identifier: GPL-2.0-only
SPDX-License-Identifier: GPL-2.0-or-later
SPDX-License-Identifier: GPL-3.0-or-later
These standard identifiers, placed at the top of every source file, state unambiguously which variant applies.
In short
- GPLv2 and GPLv3 share strong copyleft, but v3 tackles tivoization, patents and anti-circumvention measures.
- GPLv3 is compatible with Apache 2.0; GPLv2 is not.
- The "or later" clause decides whether GPLv2 code can flow into a GPLv3 project.
- The Linux kernel is "GPLv2 only": an example of why the exact version matters.
- Precise SPDX identifiers avoid ambiguity about the version.
