The GPLv3 license is a strong copyleft license, meaning that if you distribute software that incorporates GPLv3 code, you must make your corresponding source available under GPLv3 as well — an obligation that can force open-sourcing of proprietary code if you are not tracking it. Published by the Free Software Foundation in 2007, GPLv3 is not a security vulnerability in the technical sense, but an undetected GPLv3 dependency is a genuine business risk that belongs in the same scanning pipeline as your CVEs. License non-compliance has ended acquisitions and triggered litigation.
What "copyleft" actually obligates
Permissive licenses like MIT or Apache 2.0 let you use the code with minimal strings attached — mostly attribution. Copyleft licenses are different by design: they use copyright to require that derivative works stay open. GPLv3 is the strongest common form of this.
The core obligations when you distribute (convey, in GPLv3's language) software containing GPLv3 code:
- Provide the complete corresponding source code to recipients.
- License the combined work under GPLv3.
- Preserve copyright and license notices.
- Do not impose additional restrictions that contradict the license.
The word to internalize is distribute. GPLv3 obligations are generally triggered by conveying the software to others, not merely by using it. This is the crucial distinction from GPLv3's cousin, the AGPLv3, which extends the obligation to software accessed over a network — a trap for SaaS companies who assume "we never ship a binary" means they are safe.
What GPLv3 added over GPLv2
GPLv3 was written to close gaps that emerged after GPLv2. Three additions matter for risk assessment:
Anti-Tivoization. If you distribute GPLv3 software in a consumer device, you must provide the information needed to install modified versions. This targets hardware that technically ships the source but locks down the device so users cannot run their own builds.
Patent provisions. GPLv3 includes an explicit patent grant from contributors and language designed to prevent patent-based restrictions on users. If your company holds patents, legal review of GPLv3 contributions and use is warranted.
License compatibility. GPLv3 clarified compatibility with certain other licenses (including Apache 2.0), which GPLv2 did not permit. This affects which components you can legally combine.
Why this belongs in your security pipeline
License risk and vulnerability risk enter your codebase through the same door: dependencies, most of them transitive. A developer runs npm install or adds a Maven artifact, and three levels down sits a GPLv3-licensed library nobody reviewed. In a proprietary product, that single transitive dependency can create an obligation to release source you never intended to open.
Because the mechanism is identical to how vulnerable versions sneak in, the detection tooling is the same. A software bill of materials (SBOM) that captures the license of every component — direct and transitive — is what makes GPLv3 exposure visible before it ships. An SCA tool that records license metadata will flag a GPLv3 or AGPLv3 component the moment it enters the tree, rather than during acquisition due diligence when it is far more expensive to fix.
A workable license policy usually looks like:
- Allow permissive licenses (MIT, BSD, Apache 2.0) freely.
- Review weak copyleft (LGPL, MPL) with legal guidance on linking boundaries.
- Flag / block strong copyleft (GPLv3, AGPLv3) in proprietary distributed products unless legal explicitly approves.
Encode that policy as a build gate so a newly introduced GPLv3 dependency fails CI with a clear message, not a surprise months later.
Practical steps for a distributed product
- Generate and retain an SBOM for every release, with license fields populated for all components.
- Set a license policy gate in CI that blocks or flags disallowed licenses automatically.
- When GPLv3 code is genuinely needed, keep it architecturally isolated (for example, a separately distributed component) and get legal sign-off on the boundary.
- Preserve required notices and source-offer text in your distribution.
- Re-scan on every dependency change — license terms travel with versions, and a new major version can change a component's license.
The goal is not to avoid open source, which is neither realistic nor desirable. It is to know exactly what you are shipping and under what terms, the same way you want to know exactly which vulnerable versions you ship. Our Academy covers building an SBOM-driven compliance workflow end to end.
FAQ
Does using GPLv3 software internally require me to open-source my code?
Generally no. GPLv3's copyleft obligations are triggered by distributing (conveying) the software to others, not by internal use. The major exception is AGPLv3, which extends obligations to software users interact with over a network — relevant for SaaS.
What is the difference between GPLv3 and AGPLv3?
AGPLv3 adds a "network use" clause: if users interact with modified AGPLv3 software over a network, you must offer them the corresponding source. GPLv3 alone is triggered by distribution of the software itself. SaaS companies especially need to distinguish the two.
How do I find GPLv3 dependencies in my project?
Generate a software bill of materials (SBOM) that records each component's license, including transitive dependencies, using an SCA tool. It surfaces GPLv3 or AGPLv3 components as they enter the tree rather than during a costly later audit.
Is a GPLv3 dependency a security vulnerability?
Not in the technical sense — it does not introduce a CVE. But it is a compliance and legal risk that enters through the same dependency path as vulnerabilities, so it belongs in the same scanning and policy-gate workflow.