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 2 is a copyleft license, meaning users must abide by some strict rules and requirements. 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 let users do pretty much anything they want with the 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.
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:
- The full text of the license
- The original copyright notice
But as a copyleft license, the GPL v2 also requires users to:
- State any significant changes made to the original software (this requirement also applies to some permissive licenses)
- Release any copies or modifications of the code under the same license (reciprocity)
- 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
Joining the GPL family among the most-used copyleft licenses are the likes of the Mozilla Public License 2.0 and the Eclipse Public License.
GPL v2 vs. Mozilla Public License 2.0
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.
GPL v2 vs. 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.
The Future of GPL v2
While copyleft licenses like the GPL v2 are less popular than some of their permissive counterparts, they are definitely still in use. And even though the GPL v2 is not the latest version of the GNU GPL license, a number of open source projects continue to use it.
To learn more about the GNU project, the GNU General Public Licenses, and the Free Software Foundation, visit GNU’s extensive and thorough FAQs page.
