The GPL (GNU General Public License) is a free software license with strong copyleft. It grants everyone the right to run, study, modify and redistribute a program, and it requires that anyone who distributes the program or a derivative work must do so under the same license and make the corresponding source code available.
In software licensing, the GPL is the most widely known copyleft license. It was written by Richard Stallman for the GNU Project and is published by the Free Software Foundation (FSF). Its main versions, GPLv2 (1991) and GPLv3 (2007), govern major projects such as the Linux kernel, GCC, Git and many command-line tools, and its terms shape how companies combine open-source code with their own products.
How the GPL works
The GPL is built on copyright law used in reverse. The author keeps copyright but grants broad permissions on the condition that recipients pass the same freedoms on. This mechanism, called copyleft, prevents a GPL program from being turned into proprietary software when it is redistributed.
The license distinguishes clearly between private use and distribution. A person or company may modify GPL code internally without publishing anything. The obligations apply when copies, in source or binary form, are conveyed to third parties, for example by selling a device, shipping an installer or offering a download.
The core permissions and obligations of the GPL are summarized below.
| Area | What the GPL allows | What it requires |
|---|---|---|
| Use | Run the program for any purpose | No conditions for running |
| Modification | Change the code freely | Mark modified files with notices |
| Distribution | Share copies, also for a fee | Provide source code and the license text |
| Derivative works | Combine and extend the program | License the whole work under the GPL |
| Warranty | Offer paid warranty or support | No warranty by default from the authors |
Source code must be the preferred form for making modifications, including build scripts needed to compile it. Distributing only obfuscated code or omitting essential build files does not satisfy the license.
GPL versions and related licenses
The GPL family has several versions and siblings that differ in how far the copyleft reaches. Projects choose among them deliberately, and the version clause in each project matters.
| License | Scope of copyleft | Notable features |
|---|---|---|
| GPLv2 | Whole program on distribution | Used by the Linux kernel, no explicit patent clause |
| GPLv3 | Whole program on distribution | Patent license, anti-tivoization, compatibility with Apache 2.0 |
| LGPL | The library itself only | Allows linking from proprietary programs under conditions |
| AGPLv3 | Includes use over a network | Users of a hosted service can obtain the source |
Many projects use the wording “version 2 or any later version”, which lets recipients choose GPLv3. Projects licensed GPLv2 only, such as the Linux kernel, cannot be relicensed to GPLv3 without the agreement of all copyright holders, which is practically impossible for large codebases.
GPLv3 added rules on installation information for consumer devices, commonly called anti-tivoization: if GPLv3 software ships on a consumer product, users must be able to install modified versions. It also includes an explicit patent grant and a process for curing license violations within 30 days.
GPL compared with other open-source licenses
Open-source licenses fall into permissive and copyleft groups. The GPL is the strongest common copyleft license, while the MIT and Apache licenses allow use in proprietary products with few conditions.
| License | Type | Can be used in closed-source products | Main condition |
|---|---|---|---|
| GPL | Strong copyleft | Not when distributing a combined work | Release the whole work under the GPL |
| LGPL | Weak copyleft | Yes, through dynamic linking | Keep library changes open |
| MPL 2.0 | File-level copyleft | Yes | Keep modified files open |
| MIT license | Permissive | Yes | Keep the copyright notice |
| Apache License 2.0 | Permissive with patent grant | Yes | Keep notices, state changes |
Compatibility matters when combining code. Apache 2.0 code can be included in GPLv3 projects but not in GPLv2-only projects, because of additional patent and termination terms. MIT-licensed code can generally be incorporated into GPL projects.
Compliance in practice
Organizations that ship products containing GPL software need a repeatable compliance process. Most violations come from oversight, such as a supplier’s firmware containing GPL components without source code available.
- Maintain a software bill of materials (SBOM) that lists every component and its license.
- Provide complete corresponding source, either with the product or through a written offer valid for at least three years.
- Include license texts and copyright notices in documentation or in an on-device notices screen.
- Review linking and architecture early, because separating proprietary code is easier at design time than after release.
- Check supplier deliveries, since GPL obligations pass to whoever distributes the final product.
Running GPL software as an internal tool or a hosted service is generally not distribution, so no source release is required under GPLv2 or GPLv3. The AGPL closes that gap for network services, which is why some companies restrict its use internally.
Common misconceptions about the GPL
The GPL is often misunderstood in both directions, either as forbidding commercial use or as having no real obligations. Both views are wrong.
| Misconception | Reality |
|---|---|
| GPL software cannot be sold | Selling copies is explicitly allowed |
| Using a GPL tool makes output GPL | Output of a program is generally not covered |
| Internal modifications must be published | Obligations start only with distribution |
| Any contact with GPL code infects a project | The question is whether a combined derivative work is distributed |
| The GPL is public domain | Copyright remains and the license is enforceable |
Where the boundary of a derivative work lies, for example with plugins, dynamic linking or interpreted languages, is not fully settled and can depend on jurisdiction and technical details. Legal review is advisable for borderline architectures.
In everyday language
The GPL is a set of rules attached to some free software. It says: you may use, change and share this program as you like, but if you give it, or your improved version, to someone else, you must give them the same freedom and the source code too.
It works like a shared recipe that must always be passed on with the full list of ingredients. Nobody can take the recipe, change it and keep the result secret while handing out the dish.
Seen in the real world
A company building network routers bases its firmware on the Linux kernel and BusyBox, both licensed under GPLv2, and adds its own proprietary management application that runs as a separate program. Before launch, the legal and engineering teams create an SBOM listing 210 components and their licenses.
The company publishes the modified kernel and BusyBox source code together with build instructions on a download page referenced in the product manual, and includes all license texts on a notices screen in the web interface. The proprietary application stays closed because it communicates with the kernel only through standard system interfaces. The router ships compliant, and a later inquiry from a customer is answered simply by pointing to the published source.