GPLv2 vs GPLv3 comes down to three substantive changes: GPLv3 added an explicit patent grant, an anti-tivoization clause requiring installation information for consumer devices, and revised license-compatibility rules, while keeping the same core copyleft bargain that source must travel with the binary. For most server-side software the day-to-day obligations feel similar, but the differences decide whether two components can legally be combined and whether you can ship locked-down hardware.
Both are strong-copyleft licenses from the Free Software Foundation. GPLv2 shipped in 1991 and still governs the Linux kernel; GPLv3 shipped in 2007 to close gaps that had emerged in the intervening sixteen years. Understanding which one a dependency uses is not legal trivia, it changes what you can build.
The shared foundation
Before the differences, the common ground. Both versions grant the four freedoms: run the program, study and modify its source, redistribute copies, and distribute your modified versions. Both are triggered by distribution, not private use. Both require that when you convey the software you make the complete corresponding source available and license derivative works under the same GPL version. If you never ship a copy outside your organization, most obligations stay dormant under either version.
Where they diverge is in the details that a decade and a half of real-world friction exposed.
Difference 1: patents
GPLv2 is nearly silent on patents. It was written in an era when software patents were a smaller concern, and its patent protection is implicit at best. That left a gap: a company could contribute GPLv2 code and later assert patents against users of that same code.
GPLv3 closes this with an explicit patent grant. Anyone who conveys GPLv3-covered software grants recipients a license to any patents they hold that are necessarily infringed by using the code. It also added protection against patent-license deals that discriminate (the clause prompted by the 2006 Microsoft-Novell agreement). For a company shipping GPLv3 software, this means distributing the code carries a real patent commitment, which is precisely why some corporate legal teams are wary of it.
Difference 2: tivoization
This is the change that split the community. GPLv2 requires you to provide source code, but says nothing about whether the user can actually run a modified version on the device. TiVo shipped GPLv2 Linux, dutifully published the source, but signed the firmware so that a modified build would not boot. Users had the source and could change it, but the hardware refused to run the result.
The FSF considered this a violation of the spirit of the license, so GPLv3 added an anti-tivoization clause. For "User Products" (consumer devices), you must provide the "Installation Information", the keys, signatures, or instructions needed to install and run modified versions on the device. This is why GPLv3 is a hard sell for locked-down consumer hardware and part of why the Linux kernel deliberately stayed on GPLv2.
Difference 3: compatibility and termination
GPLv3 relaxed a few things GPLv2 was rigid about. It made the GPL compatible with more licenses, notably the Apache License 2.0, which is not compatible with GPLv2 because of Apache's patent-termination and notice terms. If your project needs to combine Apache-2.0 and GPL code, that combination is only legal under GPLv3.
GPLv3 also softened termination. Under GPLv2, any violation terminated your license immediately and permanently; you needed the copyright holder to reinstate you. GPLv3 added a cure period: a first-time violator who fixes the problem within 30 days of notice has their rights automatically restored. That is a meaningful de-risking for companies worried about accidental non-compliance.
The "or later" clause matters
Many projects license their code as "GPLv2 or later" (often written GPL-2.0-or-later) rather than "GPLv2 only" (GPL-2.0-only). The distinction is load-bearing:
GPL-2.0-only bound to v2, cannot be combined with GPLv3-only code
GPL-2.0-or-later recipient may use v2 OR v3, so combines with GPLv3 code
GPL-3.0-only bound to v3
GPL-3.0-or-later v3 or any future version
The Linux kernel is GPL-2.0-only, which is why kernel code cannot be relicensed to v3 without every contributor's agreement. A project marked "or later" gives you the flexibility to treat it as v3 when you need Apache-2.0 compatibility. The SPDX identifier in your SBOM records exactly which variant you have, and that string is what your compliance tooling should key on.
Why the version matters for security teams
License version rarely feels like a security concern until it blocks a fix. Two scenarios come up in practice.
First, combination legality. If a security patch requires pulling in an Apache-2.0 library alongside a GPL component, whether that is legal depends on the GPL version. A GPLv2-only component cannot be combined with Apache-2.0 code; a GPLv3 (or v2-or-later) one can. Discovering this after you have written the patch is a bad time.
Second, patch provenance. Both versions guarantee source availability, which is a genuine security asset: when upstream stalls on a CVE, you can backport the fix yourself. The GPLv3 cure period also reduces the risk that a good-faith compliance slip cascades into losing your right to distribute the fixed build.
An SCA tool that classifies license variants, not just "GPL" but the exact SPDX identifier, lets you catch an incompatible combination before it reaches a release branch. For teams formalizing this, the difference between blanket-blocking "GPL" and understanding v2-only versus v3 is the difference between a policy engineers respect and one they route around. Our academy covers building a license policy that distinguishes these cases.
FAQ
Can I combine GPLv2 and GPLv3 code in one project?
Only if the GPLv2 code is licensed as "GPLv2 or later." GPLv2-only code cannot legally be combined with GPLv3-only code because their terms conflict. The "or later" clause is what makes the combination possible.
Why is the Linux kernel still on GPLv2?
The kernel is licensed GPL-2.0-only, and relicensing would require agreement from thousands of contributors. Many maintainers also specifically object to GPLv3's anti-tivoization and patent terms, so the kernel deliberately stays on v2.
Is GPLv3 compatible with Apache 2.0?
Yes. GPLv3 was written to be compatible with the Apache License 2.0. GPLv2 is not, because of Apache's patent and notice provisions, so an Apache-2.0 plus GPL combination is only legal under GPLv3.
Does the GPL version affect how secure the software is?
Not directly; both guarantee source availability, which aids auditing and self-service patching. The version matters for security work indirectly: it determines whether you can legally combine components when a fix requires it, and GPLv3's cure period lowers compliance risk.