Get Your Free GPL Compliance Guide

Understanding Core GPL License Obligations

The GNU General Public License (GPL) is a legal framework that governs how software can be used, modified, and shared. When you incorporate GPL-licensed software into your product or service, you accept specific responsibilities that differ significantly from proprietary software agreements. These obligations exist to ensure that software freedoms remain available to all users throughout the chain of distribution.

At its foundation, the GPL requires that anyone who receives software built with GPL components must also receive the same freedoms. This creates a legal chain: if you use GPL code in your project, your project typically falls under GPL requirements as well. The license distinguishes between different versions—primarily GPLv2 and GPLv3—each with slightly different requirements. GPLv2, released in 1991, remains one of the most widely used open-source licenses in existence. GPLv3, released in 2007, includes additional provisions around digital restrictions management and patent protection.

The GPL operates on the principle of "copyleft," which is fundamentally different from permissive licenses like MIT or Apache. Where permissive licenses allow you to use code in closed proprietary products with minimal restrictions, copyleft licenses require that derivative works maintain the same open-source status. This means if you modify GPL code and distribute it, you cannot restrict others from accessing that modified code.

One critical distinction in GPL compliance is the difference between internal use and distribution. If your organization uses GPL software only internally—without distributing it to customers or the public—you may not trigger all GPL obligations. However, this internal-use exception has important limits. If you distribute your software to customers, even in binary form only, GPL typically activates. The license was designed this way to prevent companies from using open-source code in products while keeping improvements proprietary.

Common scenarios that trigger GPL obligations include: incorporating GPL libraries into your application, modifying GPL source code for your needs, bundling GPL tools with your product, and linking against GPL components. Each scenario carries different compliance requirements, and misunderstanding these distinctions is where many organizations encounter problems.

Practical Takeaway: Before using any GPL software, identify which GPL version applies and whether your use involves modification or distribution. Create an inventory of all GPL dependencies in your codebase. This foundational step prevents compliance issues later in your product development cycle.

Source Code Disclosure Requirements and Timing

One of the most significant GPL obligations involves making source code publicly available when you distribute GPL-covered software. This requirement applies whether you distribute software as a downloadable file, through a cloud service, embedded in hardware, or as a service. Understanding when, how, and what to disclose is essential for compliance.

The disclosure requirement activates when you "distribute" software to others. Distribution includes giving software to customers, making it available for download, deploying it on servers that customers access, or embedding it in devices you sell. If you modify GPL code and keep those modifications internal only, disclosure doesn't apply. However, once you share the software with anyone outside your organization—including employees at partner companies—the obligation typically begins.

The GPL requires that source code be made available in a form that allows others to understand and modify it. This means the actual human-readable code, not compiled binaries. The code must be complete enough that someone with programming knowledge could compile it and reproduce the functionality. You cannot provide obfuscated or partially functional source code and claim compliance.

Timing requirements vary slightly between GPL versions. Under GPLv2, you must provide source code "for at least three years" after your last distribution of the software. Under GPLv3, the requirement extends to the entire period during which you offer products or services to that user. Some companies maintain source code repositories indefinitely to avoid disputes about how long they've been distributing.

The actual mechanism for disclosure is flexible. Common approaches include: providing a publicly accessible website where source code can be downloaded without charge, including source code on physical media with the product, offering to provide source code on CD or via mail at cost of reproduction, or maintaining a public repository on platforms like GitHub where anyone can access it. The GPL does not require you to use any particular platform—only that the source code remains available and accessible.

An important nuance involves "corresponding source." If you distribute compiled binary code, the corresponding source must match that binary. If you distribute version 1.5 of a program to customers, you must keep version 1.5 source available—not just the latest development version. This prevents companies from releasing outdated binaries while only maintaining current source code.

Practical Takeaway: Establish a documented process for tracking which GPL software versions you distribute and when. Set up a source code repository that mirrors your distributed versions, and commit to a retention policy that meets your chosen GPL version's timing requirements. Document this process in writing so that future team members understand your compliance approach.

License Notices, Copyright Attribution, and Documentation

Proper documentation of GPL licensing is not optional—it is a specific requirement of the license terms. When you distribute GPL software, whether modified or unmodified, you must include appropriate copyright notices, license text, and attribution information. These requirements serve multiple purposes: they inform users of their rights, they acknowledge original developers, and they create a clear legal record of licensing status.

Every GPL-covered file should include a license header. This is typically a comment at the top of source code files stating that the file is licensed under the GPL and providing a brief description of its purpose. The header should reference the specific GPL version (GPLv2, GPLv3, or "GPLv2 or later"). A standard GPL header looks like this: a notice that the program is free software distributed under GPL terms, a statement that it comes with no warranty, and a reference to where the full license text can be found.

You must provide the complete text of the GPL license itself. For GPLv2 and GPLv3, this is the full legal document. Many companies include this as a file named COPYING or LICENSE in the root directory of the project or product distribution. If you distribute binary software, users must be able to obtain the license text. This can be accomplished through documentation files, online links, or printed materials included with physical products.

Copyright notices must clearly identify the original developers and the year(s) of development. When you modify GPL code, you may add your own copyright notice for your modifications while preserving the original author's notice. For example, if you modify a 2010 GPL project in 2024, both copyright notices should appear: "Copyright 2010 Original Author" and "Modifications Copyright 2024 Your Company." This creates transparency about who created what portions of the code.

If you distribute modified GPL software, you must clearly document what changes you made. The GPL requires that modifications be "marked in reasonable ways so that their author knows they are not the responsibility of the previous developer." Many projects use CHANGELOG files or similar documentation to track modifications. Some include comments in the modified code itself. The standard is reasonableness—anyone looking at the code should understand what has been changed and by whom.

Additional documentation considerations include: maintaining a list of all GPL dependencies in your product, noting which license version applies to each, explaining how to obtain source code for each dependency, and providing instructions for building or compiling the software. Some organizations create a NOTICE or ATTRIBUTION file that lists all GPL components in their product, their versions, and where source code can be found.

Practical Takeaway: Create a template GPL header for your organization and apply it to all source files that use GPL components. Maintain a bill-of-materials document listing every GPL library or component your product uses, its version, and the GPL version it operates under. Update this documentation before each release and include it in your distributed software.

Common Compliance Mistakes and How to Prevent Them

Organizations regularly encounter GPL compliance issues not from intentional violation but from misunderstanding or oversight. Learning about common mistakes allows you to implement preventive measures in your development workflow and avoid costly corrections later.

One widespread mistake involves failing to identify GPL dependencies in the first place. Many organizations use package managers (npm, pip, Maven, etc.) to incorporate libraries without carefully reviewing their licenses. A project might include dozens of indirect dependencies—libraries that are required by libraries you directly use—without anyone realizing that one of these nested dependencies is GPL-licensed. The solution involves implementing automated license scanning tools that analyze every dependency in your build process. Tools like FOSSA, WhiteSource, or Black Duck can scan your codebase and flag GPL components automatically. Many teams integrate these tools into their continuous integration pipeline so that GPL dependencies are caught before code is