The GNU General Public License v3.0, explained in the terms lawyers actually use in a contract review, is dense enough that most engineers just skim a summary and move on. The short version that matters for day-to-day engineering decisions: if you distribute software that includes GPL-3.0 code, in source or compiled form, you're obligated to make the complete corresponding source available to whoever receives it, under the same license, and you can't add restrictions on top of what the GPL already permits.
What does GPL-3.0 actually require?
The core obligation is source availability triggered by distribution. If you ship a binary, an installer, a compiled application, that links against or includes GPL-3.0 licensed code, you must provide the complete source code needed to build and run that same binary, to anyone you gave the binary to. That includes your own modifications to the GPL code, and it includes build scripts and installation instructions, the license isn't satisfied by handing over an incomplete source tree that doesn't actually let the recipient reproduce the binary.
Critically, "distribute" is the trigger, not "use." If you run GPL-3.0 licensed software internally, on your own servers, and never ship a binary containing it to anyone outside your organization, the source-disclosure obligation generally doesn't activate. This is the reason SaaS companies could historically use GPL code server-side without the same disclosure obligations that apply to shipped desktop or mobile software, a gap the AGPL was specifically written to close.
What changed from GPL-2.0 to GPL-3.0?
GPL-3.0 added explicit patent provisions: contributors grant a patent license covering their contributions, and it includes language intended to prevent Tivoization, the practice of shipping GPL-licensed software on hardware that cryptographically refuses to run modified versions of that software. If your product locks down a device so users can't run their own build of the GPL-licensed firmware on it, GPL-3.0 requires you to provide whatever keys or signing mechanism is needed for the user to actually install a modified version.
GPL-3.0 also has more explicit compatibility language for combining GPL code with code under other licenses, and it clarified some ambiguity around what counts as a derivative work versus mere aggregation, though this remains one of the genuinely gray areas of open source licensing regardless of which GPL version you're reading.
Does using a GPL-3.0 library make my whole application GPL?
This is the question that generates the most anxiety, and the honest answer is: it depends on how the code is combined, and reasonable lawyers disagree on some of the edge cases. Static linking or directly incorporating GPL-3.0 source into your codebase is broadly understood to create a derivative work subject to the GPL's copyleft, meaning your combined work needs to be distributable under GPL-3.0 terms too if you distribute it. Dynamic linking is more contested; the Free Software Foundation's position is that dynamic linking still creates a derivative work, but this isn't universally accepted, and it's part of why the LGPL exists as a separate, more permissive variant specifically for library use.
If your product is architected so that a GPL-3.0 component runs as a separate process communicating over a well-defined interface, rather than being compiled into your application, the copyleft obligations are generally understood to not extend across that process boundary, though this again isn't a bright legal line, it's a widely held interpretation.
What should engineering teams actually do about this?
Practically, the decision that matters is made earlier than most teams realize: whether to pull in a GPL-3.0 dependency at all, before it's woven through the codebase and expensive to remove. Most companies building proprietary, closed-source products maintain a policy that excludes GPL-3.0 (and AGPL-3.0) from approved dependency lists specifically to avoid the compliance analysis described above, reserving GPL usage for cases where the team has deliberately decided the copyleft obligations are acceptable.
Tracking which dependencies, including transitive ones several layers deep, carry GPL-family licenses is the actual engineering task here, and it's tedious to do by hand across a modern dependency tree with hundreds of transitive packages. Open source license scanning that flags copyleft licenses automatically as part of your build pipeline catches this before a GPL-3.0 dependency gets baked into a shipped binary, rather than discovering it during a due diligence review or an acquisition, which is a genuinely common and expensive way for this to surface.
FAQ
Do I have to release my source code just for using a GPL-3.0 tool internally?
No. Internal use without distribution to third parties generally doesn't trigger the source-disclosure obligation. It's distribution, shipping a binary that includes the GPL code, that activates it.
What's the difference between GPL-3.0 and LGPL-3.0?
LGPL permits dynamic linking from proprietary code without extending copyleft to the linking application, specifically to make GPL-family licensing workable for shared libraries. GPL-3.0 has no such carve-out.
Can I sell software that includes GPL-3.0 code?
Yes, the GPL doesn't prohibit charging money for distribution. What it requires is that anyone who receives the binary also receives (or can obtain) the source and the right to redistribute and modify it, which in practice means charging for the binary alone rarely works as a business model, since the recipient can redistribute the source for free.
Is GPL-3.0 compatible with Apache 2.0?
GPL-3.0 is generally considered one-way compatible with Apache 2.0, meaning Apache 2.0 code can be incorporated into a GPL-3.0 project, but not the reverse, because Apache 2.0 doesn't carry GPL's copyleft requirements forward.