Disclaimer: This post is for informational purposes only, and should not be used in place of legal advice.
Overview
Before we dive into the specifics of the GNU General Public License (GPL) version 3, let’s talk first about what it means to have an open source license. Unlike proprietary software, open source allows for use, modification, and distribution, within the legal constraints defined by the license. It’s important to understand and fully comply with license terms and conditions, because they protect both software creators and the users.
Open source licenses can be roughly categorized as either “permissive” or “copyleft.” Copyleft licenses (like GNU GPL) require developers to use the same distribution terms if they use, modify, and redistribute the open source code, while permissive licenses (like the MIT License) permit users to redistribute source code with a different license or set of terms and conditions.
GNU General Public License (GPL): Terms and conditions
The GPL License was created by Richard Stallman (who launched the GNU Project and the Free Software Foundation) to protect GNU software from being made proprietary.
As a copyleft license, the GPL allows developers to freely use, modify, and distribute GPL-licensed code, as long as the source code is made available to others to modify and distribute further and licensed under the same GPL terms. Developers can distribute this code either as commercial or non-commercial software. However, they can’t impose any additional limitations on the rights granted by the GPL, like for example distributing software under a contract or an NDA.
The GPL also does not provide any warranty or liability protection, so users of GPL-licensed software assume all risks associated with it.
Critically, if you use a GPL-licensed component anywhere in your source code, your entire project must be GPL-licensed and comply with the GPL terms.
Ansible, Azure Linux, GNU Compiler, and Drupal are all examples of software programs that use a GPL license.
GPL License variations
Since the GPL License was first created, several variations have been introduced to serve specific software licensing needs. Below is a list of those variations.
GNU Lesser GPL Public License (LGPL)
The GNU LGPL is known as a “weak copyleft” license. Similar to the original GPL, it requires developers to release the source code of any changes to the original software. But that requirement only applies if the developer has modified the original LGPL-licensed code. If the developer simply uses the code in their software program, they do not need to release their source code, and they could even make their part of the software program proprietary. The LGPL also grants patent rights.
The LGPL tends to be a good choice for developers who want to balance using OSS software and supporting the community with a desire or need to incorporate their code into proprietary software.
GNU Affero Public License (AGPL)
The GNU AGPL is likewise based on the original GPL, but has an additional term to allow users who interact with the licensed software over a network to receive the source for that program. It’s recommended that developers consider using the GNU AGPL for any software that will be run over a network.
GNU Free Documentation License (FDL)
The GNU Free Documentation License is intended for use on a manual, textbook or other document to assure everyone the effective freedom to copy and redistribute it, with or without modifications, either commercially or non-commercially.
How can I use the GNU GPL license?
To use the GNU GPL License, you’ll need to include the following in any copies or substantial portions of your software:
1. The original copyright notice
2. A copy of the license itself
You’ll also need to make sure that the modified source code is available to users upon request.
It’s common for developers to include this information in a LICENSE.md or LICENSE.txt file in their source code repository (see Drupal's LICENSE.txt file here). Developers also commonly include a short license summary at the top of each source file referencing the license and linking to its full text.
Is the GNU GPL License compatible with other licenses, like the MIT License?
Your software project may reuse and distribute code governed by different licenses, like the MIT License and the GPL. The GPL is generally compatible with the MIT License. But keep in mind that, if you’re reusing and distributing code that is governed by GPL, your final project must be GPL-compliant and publicly available.
How is the GNU GPL license different from permissive licenses, like the MIT License?
A major difference between permissive licenses like the MIT License, the BSD License, and the Apache 2.0 license and the GNU GPL license is the distribution terms. Permissive licenses like the MIT License allow modifications without restrictions, while the GPL requires the modified code to be distributed under the same license, with the goal of keeping open source code open.
How do I make sure I stay in compliance with the GNU GPL License?
To make sure that you know what dependencies are governed by an MIT License and make sure they’re compatible with dependencies governed by other license types, here are two suggested actions:
Create a mapping of your open source dependencies
To understand which dependencies are governed by the GPL License, you first need to understand what dependencies are in your software—including both direct dependencies and transitive dependencies, which are the dependencies of your dependencies.
You can generate a Software Bill of Materials, or SBOM, for your software program to get a list of all of your dependencies, including package names, versions, and licenses. If you're already using an SCA (Software Composition Analysis) tool, you can likely use this tool to generate an SBOM automatically. You can also use free and open source tools like Syft or Tern to generate SBOMs from container images, filesystems, and Dockerfiles.
Enforce policies for license usage
Implementing policies to allowlist or block certain types of open source licenses can help make sure that you're staying compliant with your organization's requirements. Many commercial SCA tools include automated license scanning capabilities. FOSSology is an open source license compliance toolkit that can execute license and copyright scans.
Looking for information on open source software licenses? Stacklok offers a free-to-use web app, Trusty, that provides license data and supply chain risk analysis for packages across five different language ecosystems. Try it out now at www.trustypkg.dev.
