GPL software is licensed under the GNU General Public License, a copyleft license that lets you use, study, modify, and redistribute the code freely, on the condition that derivative works you distribute are released under the same terms. That reciprocal condition is what makes the GPL different from permissive licenses like MIT or Apache, and it is why license compliance deserves a place in your engineering process rather than being left to legal at the last minute.
The GPL is not a security vulnerability. But an unnoticed GPL dependency pulled deep into a proprietary product can become a legal and business problem, which is why supply chain tooling treats license data as first-class risk alongside CVEs.
What Copyleft Actually Requires
Copyleft is a clever inversion of copyright. The license uses the author's copyright to guarantee downstream freedoms rather than restrict them. In practical terms, if you distribute software that incorporates GPL-licensed code, you generally must make the corresponding source available under the GPL, including your modifications, and you cannot add restrictions that limit the rights the GPL grants.
The key word is distribute. The obligations are triggered by conveying the software to others. If you use GPL software purely internally and never distribute it, the classic GPL source-disclosure obligation generally is not triggered. This internal-use carve-out is exactly why the AGPL exists, which I will get to.
GPL, LGPL, and AGPL
These three are frequently confused, and the differences drive real decisions.
The GPL (versions 2 and 3 are both in wide use) is the strong copyleft license. Linking your proprietary code against GPL code and distributing the result typically pulls your code into the GPL's orbit.
The LGPL (Lesser GPL) is weaker copyleft designed for libraries. It generally lets you link the library into proprietary software without licensing your own code under the LGPL, provided you meet conditions such as allowing the user to replace the library. Many teams are comfortable using LGPL libraries in commercial products where they would avoid full GPL.
The AGPL (Affero GPL) closes the "software as a service" gap. Under the plain GPL, running modified software on a server you offer over a network is not distribution, so no source obligation is triggered. The AGPL treats network interaction as triggering the source-availability obligation, which is why many companies ban AGPL dependencies outright in commercial products.
Why This Belongs in Your Security Pipeline
License risk and vulnerability risk travel together because they come from the same place: your dependency tree. A permissively licensed package you audited a year ago can pull in a GPL or AGPL transitive dependency after a version bump, and nobody notices until a customer's legal team runs their own scan during due diligence.
This is why modern software composition analysis reports licenses alongside vulnerabilities. The same tool that tells you a package has a known CVE can tell you that a new transitive dependency introduced AGPL code into a product you sell under a proprietary license. Catching that in CI is far cheaper than catching it during an acquisition.
Practical Policy
Most teams settle on a tiered policy. Permissive licenses (MIT, BSD, Apache 2.0) are allowed by default. Weak copyleft (LGPL, MPL) is allowed with review, often depending on how the code is linked. Strong copyleft (GPL, AGPL) is allowed only for internal tooling or explicitly approved cases, and blocked in distributed commercial products.
Encode that policy as a gate in your build so a disallowed license fails the pipeline the moment it appears, rather than surfacing in a manual audit months later. Keep an inventory, often expressed as an SBOM, so you always know what you are shipping. The Safeguard academy has a deeper walkthrough of turning a license policy into an automated gate.
A Note on Good Faith
The GPL exists to keep software free, and the overwhelming majority of enforcement is about getting compliance, not extracting damages. Complying is usually straightforward: publish your source, keep the license notices, and honor the terms. The trouble comes almost entirely from not knowing what is in your dependency tree, which is a solvable visibility problem.
FAQ
Is GPL software free to use commercially?
Yes. The GPL permits commercial use, including selling GPL software. The obligation is about source availability and licensing terms for distributed derivatives, not about charging money, which is explicitly allowed.
Does using a GPL tool force me to open source my whole company?
No. Using GPL tools internally, or running them as part of your workflow, does not affect the licensing of your unrelated proprietary code. Obligations attach to distributing derivative works that incorporate GPL code.
What is the difference between GPL and AGPL?
The AGPL extends the GPL's source-availability requirement to software offered to users over a network, closing the SaaS gap. Under the plain GPL, running modified code on a server you operate is not considered distribution.
How do I find GPL dependencies in my project?
Use a software composition analysis tool or generate an SBOM. These report the license of every direct and transitive dependency, letting you flag GPL and AGPL components before they ship.