Skip to main content
FOSSA Logo

Open Source Software Licenses 101: GPL v2

February 24, 2021 · 11 min read·FOSSA Editorial Team
Open Source Software Licenses 101: GPL v2

Open source software (OSS) licenses dictate the various terms and conditions that come with using a given piece of OSS, and they come in numerous varieties. However, the average open source developer or user is likely to come across the same handful of licenses again and again.

Among today's more popular OSS licenses is the GNU (of the GNU Project) General Public License Version 2.0, commonly referred to as simply GPL v2. Initially released in 1991, the GPL v2 is a copyleft license, meaning users must abide by some strict conditions. Copyleft licenses like GPL v2 are in contrast to popular permissive open source licenses, such as the MIT license and the Apache License 2.0, which impose relatively few conditions on use of the licensed code.

GPL v2 License: The Basics

Copyleft open source software licenses come in two forms: strong and weak. The GPL v2 falls into the first category. A copyleft license requires all code modifications to the licensed software to be released under the same license. The distinction between weak and strong depends on how much code must be released. Strong copyleft licenses like GPL v2 cover whole programs. Weak copyleft licenses, on the other hand, allow you to add libraries or plug-ins to the original program and keep your additions proprietary (closed-source).

In other words, any modifications you make to code licensed under GPL v2 also fall under GPL v2. The “open source-ness” of the original work persists to your new/updated work.

What Are GPL v2 Requirements?

The GPL v2 has several requirements in common with popular permissive licenses. For example, like the MIT and Apache 2.0 licenses, any copy or modification of the GPL 2-licensed code must include:

  1. The full text of the license
  2. The original copyright notice

But as a copyleft license, the GPL v2 also requires users to:

  1. State any significant changes made to the original software (this requirement also applies to some permissive licenses)
  2. Release any copies or modifications of the code under the same license (reciprocity)
  3. Make available the original source code when you distribute any binaries based on the licensed work

Using the Licensed Code

Despite these requirements, there’s still plenty you’re allowed to do with code licensed under GPL v2, like:

  • Use the code commercially: Organizations may incorporate the licensed code into their software, then sell that software to customers. However, companies should note that other users could pay that fee, then release the code themselves without a fee, as all GPL v2-licensed code is freely redistributable under GPL.
  • Modify the code: Users can make changes to or rework the code, but if they distribute these changes/modifications in binary form, they must also release these updates in source code form under the GPL v2 license.
  • Distribute copies or modifications of the code: As long as these modifications are also released under the GPL v2 license, they can be distributed publicly.
  • Place warranty: Distributors of the original code can offer their own warranty on the licensed software.
  • Use and modify the code privately: If you don’t plan on making modified software available to others, you can rework the code without sharing your modifications and use it on your own.

As a copyleft license, the GPL v2 has one key caveat: Users cannot sublicense the code under any other terms. All publicly distributed modifications must be licensed under GPL v2.

Variations of GPL v2

The GPL v2 is not the only or even the most recent version of the GPL license. The latest version is the GPL v3, which we’ll be exploring in detail in an upcoming post. There’s also the:

  • GNU LGPL v3.0 (GNU Lesser General Public License version 3.0): A weak copyleft version of the GNU GPL v3.0.
  • GNU AGPL v3.0 (GNU Affero General Public License version 3.0): A very strong copyleft license created specifically for network software. This license has additional requirements to share modifications to source code if you make the software available to others as a service.

GPL v2 vs. Other Copyleft Licenses

What's the Difference Between GPL v2 and the MPL?

The GPL v2 falls into the “strong copyleft” category, while the Mozilla Public License 2.0 is what’s known as “weak copyleft” or “file based copyleft.” Users can add on to the originally licensed code to create an aggregate work, then sublicense those additions. Basically, a larger work that includes the licensed code can be distributed without disclosing the source code of the additions. Modifications of any existing files, however, must be released under GPL 2.

What's the Difference Between GPL v2 and the Eclipse Public License (EPL)?

Like the Mozilla Public License 2.0, the EPL is a weak copyleft license. But it also comes with a few requirements that go beyond those of the GPL v2. For example, the EPL states that if you use the code in commercial software and that software becomes the subject of a lawsuit or damages, you’re required to defend and/or compensate the EPL contributor(s).

GPL v2 Use Cases

Why might OSS developers and companies choose to contribute to or work with code licensed under GPL v2? Let’s go through a few of the reasons.

For Developers

According to the Linux Foundation’s recent FOSS Contributor Survey report, OSS contributors tend to be motivated to take part in open source projects by intrinsic factors, like the desire to take part in creative work, rather than financial ones. In the open source world, cooperation, sharing, and the “democratization” of software are especially valued. If you believe in this community-focused ethos and want “free software to spread,” GPL v2 is an appealing option.

By using this license, you encourage other developers to improve upon your work, add to it, and create the best version possible. You also avoid the possibility of a company taking your work, tweaking it slightly, then making it proprietary.

For Companies

One reason a company may choose to incorporate GPL v2-licensed code is, as mentioned, that many innovative developers (and open source projects) find the license appealing. The code resulting from cooperation and knowledge-sharing may be more valuable and effective than a project built in a more closed-off developer ecosystem. And developers will likely appreciate that you’re giving back to the OSS community.

But don’t companies want to make money off of their software and keep their code changes (and associated advantages) to themselves? The Free Software Foundation (FSF), which backs the GNU Project, addressed this in a thought-provoking essay. Permissive licenses allow your competitors to take your open source code, change it and provide bug fixes, then close it off. In other words, your organization is essentially doing the initial groundwork for its competitors without any financial benefit. Through the use of a copyleft license like GPL v2, however, companies end up in a sort of symbiotic relationship, with each contributing to the betterment of the code.

Well-Known Uses of the GPL v2

By far the most notable use of this license is the Linux kernel, the basis of the Linux operating system. While iOS and Microsoft are the operating systems of choice for most personal computers, the developer world runs on Linux. In fact, only 2 of the top 25 websites in the world do not use Linux, and 90% of all cloud infrastructure is Linux-based.

Frequently Asked Questions About the GPL v2 License

What is the GPL v2 License?

The GNU General Public License Version 2.0 (GPL v2) is a strong copyleft open source software license released in 1991. It requires that any modifications or derivatives of GPL v2-licensed code must also be released under the GPL v2 license, ensuring that the code remains open source.

Can I use GPL v2-licensed code in commercial software?

Yes, you can use GPL v2-licensed code in commercial software and charge money for it. However, you must also make the source code available to anyone who receives the software, and any modifications must be released under GPL v2. This means competitors could also distribute your code.

Do I need to share my modifications to GPL v2-licensed code?

Yes, if you distribute your modifications or software that includes GPL v2-licensed code, you must share your modifications under the GPL v2 license. However, if you only use the code internally and don't distribute it, you're not required to share your modifications.

What's the difference between GPL v2 and GPL v3?

GPL v3 is the newer version of the license, released in 2007. Key differences include GPL v3's explicit patent grant provisions, protection against tivoization (devices that prevent users from running modified software), and compatibility with additional licenses like Apache 2.0. Many projects, including the Linux kernel, continue to use GPL v2.

What's the difference between GPL v2 and permissive licenses like MIT?

GPL v2 is a copyleft license that requires you to release modifications under the same license, while permissive licenses like MIT allow you to keep modifications proprietary. GPL v2 also requires you to make source code available when distributing binaries, which permissive licenses don't require.

What happens if I violate the GPL v2 License?

Violating the GPL v2 license means you're using the code without a valid license, which could result in copyright infringement claims. The copyright holders can seek damages and injunctions. However, GPL v2 violations are typically resolved through compliance rather than litigation.

Subscribe to our newsletter

Get the latest insights on open source license compliance and security delivered to your inbox.