GNU General Public License (GPL): Purpose, history, and obligations

Core requirements and typical clauses

When software is distributed under the GPL, a few central obligations usually apply. These obligations are intended to preserve recipients' freedoms rather than to restrict use:

• Source availability: Distributors must provide the complete corresponding source code or a written offer to supply it, so downstream users can study and modify the program. Many projects place this requirement in the main license text; additional guidance appears on project pages such as project documentation.
• Copyleft: Any distributed modified or extended versions must be licensed under the GPL as well, so recipients receive the same rights.
• Notice and attribution: Copyright notices, disclaimers of warranty, and license texts must be preserved in redistributed copies.
• No additional restrictions: Distributors may not impose further legal or technical constraints that contradict the GPL terms.

History and development

The GPL was authored and stewarded by Richard Stallman and the Free Software Foundation in the late 1980s and early 1990s to implement the goals of the GNU Project. The first formal GPL (v1) appeared in 1989, followed by GPLv2 in 1991 and GPLv3 in 2007. Each revision addressed new technical and legal challenges: compatibility with other licenses, anti‑circumvention concerns, hardware restrictions (sometimes called "tivoization"), and patent issues. For details on specific version differences see explanatory materials and FAQ pages such as those linked at official explanations and community commentaries like analyses.

Practical effects and examples

Because the GPL protects recipients' freedoms, it has shaped many major free software projects. Well‑known examples include the Linux kernel (released under the GPLv2), numerous GNU utilities and libraries, and many desktop and server applications. The license allows selling GPL software: however, any distributed binaries must be accompanied by source or an offer for source. If modifications are kept private and not distributed, the GPL does not require publication of those changes — obligations arise on distribution, not mere internal use. For more on how distribution triggers obligations see guidance at developer resources and community FAQs like common questions.

Distinctions, compatibility and common questions

The GPL differs from permissive licenses (such as MIT or BSD) in that those licenses allow derived code to be relicensed under more restrictive terms, while the GPL does not. License compatibility is a practical concern: combining GPL code with code under an incompatible license can prevent lawful redistribution of the combined work. Some projects declare "GPLv2 or later," granting permissive upgrade options, while others (notably some kernels and libraries) choose a fixed version. Issues like linking, plugins and network use can prompt detailed legal and technical analysis; for special cases, alternative licenses such as the Affero GPL address network‑use distribution and are discussed at resources like comparisons and license guides.

Because the GPL's goals are legal and social as much as technical, project maintainers, distributors and users often consult the Free Software Foundation or licensed counsel for complex cases. For official texts and licensing tools consult the primary sources at official license resources.