GNU Licenses protect user freedom, define redistribution rules, and help developers choose the right balance between openness, compatibility, and long-term software reuse.
GNU Licenses are a family of free software licenses published by the Free Software Foundation. The family includes the GNU General Public License, the GNU Lesser General Public License, the GNU Affero General Public License, and the GNU Free Documentation License. They are related, but they do not behave the same way. That distinction is the first thing a real fact check should make clear.
The core purpose of GNU Licenses is to preserve freedom for users and downstream recipients. The FSF explains that the GPL is intended to guarantee the freedom to share and change software so it remains free for all its users. It also says that free software is about freedom, not price, and that people may distribute copies and charge for that service if they wish.
That means GNU Licenses are not just legal labels. They are policy decisions written into copyright terms. They define what happens when code is copied, modified, redistributed, linked, or served over a network. If you want to understand GNU Licenses properly, you have to read them as operational rules, not slogans.
Why people confuse the family
A lot of confusion comes from using “GNU Licenses” as if every license in the family has the same effect. It does not. GPLv3 is the latest version of the GNU GPL and is a copyleft license recommended by the FSF for most software packages. GPLv2 is the previous version, also a copyleft license, but it is not compatible with GPLv3 by itself.
The same kind of confusion happens with LGPL and AGPL. LGPL is still a free software license, but the FSF says it is not a strong copyleft license because it permits linking with nonfree modules. AGPL is based on GPLv3, but it adds a network-use condition so users who interact with the software over a server can receive the source for the modified version. Those are not small differences. They are the reason GNU Licenses must be read version by version and purpose by purpose.
The GNU GPL License in plain language
The GNU GPL License is the best-known member of the family. The FSF describes GPLv3 as the latest version, a free software license, and a copyleft license. It recommends GPLv3 for most software packages. That recommendation matters because it shows the FSF’s current default position rather than a historical preference.
GPLv2 is still important, but the FSF treats it as the earlier version. The license list says GPLv2 is the previous version and is also a copyleft license. At the same time, the list notes that GPLv2 is not compatible with GPLv3 by itself. If a project is “GPLv2 or later,” that can create more flexibility than “GPLv2 only,” but the exact wording is part of the legal structure and must be checked carefully.
This is where the phrase GNU Licenses becomes more than a label. A project saying “under GNU Licenses” is not enough information. You need the exact license, version, and any “or later” language before you can understand what rights and duties are actually being granted.
What copyleft means
Copyleft is the mechanism that keeps the freedoms in place after redistribution. The GPL is explicitly described by the FSF as a copyleft license intended to guarantee the freedom to share and change software. In practical terms, copyleft is what stops a recipient from taking a protected work, improving it, and then stripping away the same freedoms for the next user.
That idea is the heart of GPL Software Freedom. The point is not simply that the code exists online. The point is that recipients keep the right to study, modify, and share it under the same freedom-preserving terms. That is why many developers choose copyleft in the first place. They want improvements to stay available to the community.
Copyleft is also why GNU Licenses can be controversial in some business settings. Some teams want the ability to combine code with proprietary modules. Others want a stronger guarantee that shared improvements stay shared. GNU Licenses support both goals in different forms, but the choice between GPL, LGPL, and AGPL changes the result significantly.
LGPL is not just a weaker GPL
The GNU Lesser General Public License is often misunderstood because the word “Lesser” sounds like a diluted version of the GPL. The FSF’s own description is more precise. LGPLv3 is a free software license, but not a strong copyleft license, because it permits linking with nonfree modules. The FSF recommends it only for special circumstances.
LGPLv2.1 works similarly in broad terms. The FSF says it is a free software license but not a strong copyleft license, and that it is compatible with GPLv2 and GPLv3. The key point is not that LGPL is “worse.” It is that LGPL is built for a different use case, especially libraries that should remain available to a wider set of applications.
When people discuss GNU Licenses, they often imagine a single ladder from “strict” to “loose.” That is too simple. LGPL is not a compromise in the abstract; it is a deliberate permission structure that changes what can legally link to a library. If you are choosing a license for a library, that distinction matters a lot.
Why AGPL exists
The GNU Affero General Public License was created to address a specific gap. The FSF explains that ordinary GPL terms permit a modified version to be made available on a server without releasing the source to the public. The AGPL is designed to close that gap by requiring the operator of a network server to provide the source code of the modified version to the users of that server.
That makes AGPL especially relevant for server software and hosted applications. The FSF recommends the AGPL for software that will commonly be run over a network. In the modern software world, that is a serious recommendation, because many important tools are used as services rather than as downloadable desktop programs.
This is one of the most important fact-check points in any discussion of GNU Licenses. The GPL alone does not automatically solve every network-distribution problem. AGPL adds an extra rule for network interaction, and that extra rule is what makes it strategically different from the ordinary GPL family.
Version numbers are not optional details
A careful reader should never skip the version number. GNU Licenses are versioned for a reason, and the FSF’s own pages treat those versions as legally meaningful. GPLv3 is the latest version of the GNU GPL. GPLv2 is earlier. LGPLv3 and LGPLv2.1 differ in compatibility details. AGPL is version 3 in the current official form.
GPLv3 was published on June 29, 2007, after a year and a half of public consultation, thousands of comments, and four drafts. That history matters because it shows the license was not a quick rewrite. It was a substantial update meant to address real-world software distribution concerns.
If a project says “GNU Licenses” without naming a version, it is incomplete. A version can change compatibility, downstream obligations, and the range of code that can legally be combined with the work. In other words, version language is not decoration. It is part of the license itself.
Compatibility is where many projects go wrong
Compatibility is one of the most practical issues in GNU Licenses. The FSF’s license list says GPLv3 is a free software license and compatible with the GNU GPL, while GPLv2 by itself is not compatible with GPLv3. It also says LGPLv3 is compatible with GPLv3, LGPLv2.1 is compatible with GPLv2 and GPLv3, and Apache License 2.0 is compatible with GPLv3 but not GPLv2.
This matters because software is rarely built from one isolated file. It is usually assembled from libraries, components, and dependencies. If those pieces use different terms, the final result may be legally shareable, legally restricted, or legally impossible to combine. GNU Licenses are designed with compatibility in mind, but compatibility still has to be checked before release.
The safest habit is to check the official license list before merging code. “Open source” is not enough detail, and “free software” is not enough detail either. The exact license text determines the legal outcome. That is why serious GNU Licenses fact checking always starts with the specific version and ends with the actual combination of components.
What counts as distribution and what does not
The GNU FAQ makes some useful distinctions that many people miss. It says that “making available to the public” is a form of propagation in GPLv3, and it gives the example of putting software on a public web or FTP server. It also says that making copies for yourself, such as for installation or backup, is propagation that does not constitute conveying.
Those distinctions matter because obligations attach differently depending on the act. Uploading a public release is not the same as making a private backup. A team that does not understand the difference may either overcomply out of confusion or undercomply out of assumption. GNU Licenses are precise about this, and the precision is part of why they work.
This is also why fact checks should not treat the word “distribution” casually. In ordinary conversation the word sounds simple, but in licensing it can have exact legal meaning. GNU Licenses use that precision to define when source-sharing obligations are triggered.
The big myths people repeat
One common myth is that GNU Licenses ban commercial use. The FSF directly contradicts that idea. It says the licenses are about freedom, not price, and that users may distribute copies and charge for the service if they wish. So a company can absolutely use GPL-covered software in a commercial context, provided it follows the license terms.
Another myth is that all GNU Licenses force every related project to be public. That is not true either. The actual obligation depends on the specific license, the kind of work involved, whether it is linked, whether it is distributed, and whether it is accessed over a network. GNU Licenses are powerful, but they are still condition-based legal instruments.
A third myth is that GNU Licenses are all interchangeable. They are not. The FSF’s own pages separate the GPL, LGPL, AGPL, and documentation licenses, and they repeatedly note where compatibility exists and where it does not. If you flatten them into one category, you lose the very details that matter most.
How to choose the right license
The FSF’s guidance is straightforward: GPLv3 is recommended for most software packages. LGPL is for special circumstances, especially libraries. AGPL is recommended when software commonly runs over a network. Those recommendations are not guesses; they are the FSF’s current framing of how the GNU Licenses family should be used.
A project should begin by asking what it wants to protect. If the goal is to preserve freedom after redistribution, GPL is usually the strongest default. If the goal is to allow linking by nonfree applications while still maintaining some source-based protections for the library itself, LGPL may fit better. If the goal is to keep modified server software available to users of the server, AGPL is the cleaner choice.
That means GNU Licenses are not a one-size-fits-all toolkit. They are a menu of different legal strategies, each aimed at a different distribution model. Good license selection begins with the project’s goals, not with a favorite acronym.
How to apply the license correctly
The FSF’s “How to Use GNU Licenses for Your Own Software” page gives a practical summary of what a developer needs to do. It explains how to place a program under the GPL, LGPL, or AGPL and points readers to the GNU Free Documentation License separately for documentation work. That separation is important because software licensing and documentation licensing are not identical.
The page also provides example wording that says the program is free software, may be redistributed and/or modified under the terms of the GNU GPL, and may be used under version 3 or any later version if the author chooses. That “or later” language is meaningful because it can preserve future flexibility, while a version-specific notice can preserve tighter control.
A practical fact check should confirm that the license notice matches the developer’s intent. If the repository says one version, the source files say another, and the project website says something different, users will be confused. GNU Licenses work best when the notices are consistent across the repository, download page, and documentation.
Why project websites matter too
License compliance is not only a code-repository issue. If the project website holds the source, the notices, or the download instructions, then the site itself should remain easy to navigate. A Broken Link Checker can help find dead references, and a Redirect Plugin WordPress setup can keep old pages useful when URLs change. Those are maintenance tools, not licensing tools, but they support discoverability, which matters when people are trying to follow the rules.
That connection is easy to miss. The legal text may be perfect, but if the page is broken or the source link is buried, users can still fail to find what they need. GNU Licenses depend on transparency in practice, not just in theory. Good site maintenance supports that transparency.
For that reason, maintaining license pages, source links, and update notes is part of good project hygiene. A well-kept website makes GNU Licenses easier to honor, easier to audit, and easier to trust.
The relationship between freedom and control
The strongest misconception about GNU Licenses is that they are only about restriction. In reality, they are about preserving control for users rather than surrendering it to a closed distribution model. The FSF’s GPL language makes this explicit by tying the license to the freedoms to share, change, and receive source code.
That is why the phrase GNU Licenses matters in policy discussions. These licenses are not designed to eliminate all structure. They are designed to make sure the structure serves user freedom. In that sense, the legal rules and the social goal point in the same direction.
When a project adopts GNU Licenses, it is making a statement about values. It is choosing to keep downstream rights visible and durable rather than leaving them vague. That choice may not fit every business model, but it is coherent, intentional, and well documented by the FSF.
A practical fact-check checklist
Before you rely on a license summary, verify the exact name, version, and wording. Check whether the project says “or later,” whether it is GPL, LGPL, or AGPL, and whether any additional permissions or exceptions exist. Then verify whether any dependencies introduce compatibility issues. That is the most reliable way to avoid confusion around GNU Licenses.
Also check whether the software is distributed, conveyed, or merely used privately. The FAQ’s distinctions matter because public making-available can trigger obligations that private copying does not. If the software is a network service, AGPL rules may apply instead of ordinary GPL expectations.
Finally, confirm that the project’s public pages match the source notices. Consistency is a practical part of compliance. GNU Licenses are easiest to follow when the repository, website, and documentation all say the same thing clearly and accurately.
The bottom line on the fact check
The fact check is simple once the details are clear. GNU Licenses are a family of free software licenses built to preserve freedom, but each license serves a different purpose. GPL is the strongest default for many software projects. LGPL is a special-case solution for certain libraries. AGPL extends source-sharing obligations to network use. Compatibility and version language are not optional details; they are the parts that decide whether code can be combined safely.
If you remember only one thing, remember this: GNU Licenses are not interchangeable, and they are not vague. The official FSF pages are precise about what each license does, when it applies, and how it interacts with others. That precision is what makes the family useful.
Conclusion
GNU Licenses are best understood as a framework for keeping software freedom practical instead of theoretical. The GPL protects redistribution and modification rights, the LGPL relaxes linking rules for special cases, and the AGPL adds network-aware source access. Those differences are not minor. They determine how a project can be shared, combined, and maintained over time. A real fact check therefore starts with the exact license name, then checks the version, the compatibility rules, and the project’s distribution model. When those details are read carefully, GNU Licenses become much less confusing and much more useful. They are a deliberate way to protect users, guide developers, and preserve freedom across versions, platforms, and communities.
Frequently Asked Questions (FAQ)
1. What are GNU Licenses?
GNU Licenses are free software licenses published by the Free Software Foundation, including the GPL, LGPL, AGPL, and GNU Free Documentation License.
2. Is the GNU GPL License the same as all GNU Licenses?
No. The GNU GPL License is one part of the GNU Licenses family. LGPL and AGPL have different rules and are meant for different use cases.
3. What does GPL Software Freedom mean?
GPL Software Freedom refers to the right to share, change, and redistribute software while preserving those same freedoms for downstream users.
4. Can I sell software under GNU Licenses?
Yes. The FSF says free software freedom is about freedom, not price, and charging for distribution is allowed.
5. What is the main difference between GPL and AGPL?
AGPL adds a network-use requirement. If modified software is run on a server for public interaction, AGPL can require the source to be offered to those users.
6. Why is LGPL treated differently?
The FSF says LGPL is not a strong copyleft license because it permits linking with nonfree modules. It is recommended only for special circumstances.
7. Are GPLv2 and GPLv3 compatible?
GPLv3 is not compatible with GPLv2 by itself. Some GPLv2 projects allow later-version terms, which can affect compatibility, but the exact wording matters.
8. Why does version wording matter so much?
Version wording determines compatibility, downstream permissions, and whether later GPL terms can be used. It is a core part of the legal effect.
9. How should a project apply a GNU license correctly?
Use the official FSF guidance, include clear license notices, and make sure the repository, website, and source files all match the intended license version.
10. Do GNU Licenses cover documentation too?
Some do, but not all. The GNU Free Documentation License is handled separately from the software licenses and has its own instructions.
