In March 2024, Redis Ltd. swapped its permissive BSD license for the source-available RSALv2, and within days the Linux Foundation had spun up Valkey, a hard fork created specifically to preserve BSD-style freedoms for the caching engine millions of applications depend on. That single license change fragmented an entire ecosystem overnight -- and it's a preview of what happens when engineering teams treat open source licenses as legal boilerplate instead of a live risk surface. A typical modern service pulls in hundreds of open source packages through transitive dependencies, and each one carries a license -- GPL, MIT, the Apache License 2.0, or something more exotic -- that dictates what you can ship, what you must disclose, and who can sue you. GPL's copyleft can force you to release proprietary source code. Apache 2.0's patent grant can shield you from litigation MIT never even mentions. Getting the distinction wrong isn't just a legal footnote -- it's a compliance failure that SOC 2 assessors and enterprise procurement teams now actively test for. Of the three, the permissive MIT license is the one teams most often assume is risk-free simply because it asks so little of you.
What's the actual legal difference between GPL, MIT, and Apache 2.0?
The three sit on a spectrum from copyleft to permissive, and that spectrum determines whether you can keep your modifications private. The GNU General Public License, first published by Richard Stallman and the Free Software Foundation in 1989, requires that any derivative work you distribute be released under the same GPL terms with corresponding source code included -- this is "copyleft." MIT, drafted at MIT in 1988, is roughly 170 words long and imposes almost no obligations beyond preserving the copyright notice: you can take MIT code, modify it, close the source, and sell it. Apache License 2.0, published by the Apache Software Foundation in 2004, is also permissive -- you can relicense derivative works as proprietary -- but it adds two things MIT doesn't: an explicit patent grant and a state-change requirement (Section 4) that obligates you to document what you modified. GPL comes in two active flavors that matter for compliance: GPLv2 (1991) and GPLv3 (2007), the latter adding anti-tivoization language and an explicit patent clause after the 2007 Microsoft-Novell patent dispute made ambiguous patent terms a visible risk.
Why does GPL's copyleft clause create compliance risk for commercial software?
Because copyleft's distribution trigger converts proprietary code into an unintended open source release the moment you ship a binary that links against GPL-licensed code. Under GPLv2 Section 3 and GPLv3 Section 6, distributing a compiled work built on GPL code obligates you to make the corresponding source available under the same license -- and "distribution" includes shipping firmware on a retail device, not just publishing to GitHub. This isn't theoretical: the Free Software Foundation sued Cisco in December 2008 over GPL violations in Linksys router firmware, and the case settled in 2009 with Cisco appointing a compliance officer and making a financial contribution to the FSF. More recently, the Software Freedom Conservancy sued Vizio in October 2021, alleging the company's SmartCast TV firmware embedded GPLv2-licensed Linux kernel and BusyBox code without providing corresponding source -- litigation that worked through California courts on breach-of-contract theory into 2024. Both cases share a root cause: engineering teams didn't track which dependencies carried GPL obligations until legal discovery forced the audit.
What extra protection does Apache 2.0 give you that the MIT license doesn't?
Apache 2.0 gives you an explicit patent license and a patent-retaliation clause, protections MIT's 170-word text never addresses at all. Section 3 of Apache 2.0 grants every user of the code a royalty-free patent license from every contributor covering patent claims those contributors would otherwise be able to assert against you for using their contribution. Section 3 also includes retaliation language: if you sue any contributor for patent infringement over the licensed work, your patent license terminates automatically. MIT is silent on patents entirely, which means MIT users rely on implied license theories that have never been fully tested in court. The value of an explicit grant became visible during Oracle v. Google, filed in 2010 over Java SE API packages used in Android -- a decade of litigation over whether copying an API's structure required a license, resolved only when the Supreme Court ruled for Google on fair use grounds in April 2021. Apache 2.0's explicit terms exist precisely to prevent that kind of multi-year ambiguity.
Can mixing GPL, MIT, and Apache dependencies in one codebase actually get you sued?
Yes -- combining a GPL component with proprietary or differently-licensed code in a single distributed binary is the single most common way engineering teams accidentally trigger copyleft obligations they never agreed to. The complication compounds when GPL meets Apache 2.0 specifically: the Free Software Foundation's own license-compatibility list states that GPLv2 is incompatible with Apache License 2.0, because Apache's patent-retaliation clause imposes a restriction GPLv2 doesn't permit. GPLv3, by contrast, was written to be compatible with Apache 2.0. Practically, that means a codebase built on GPLv2-only components cannot legally incorporate Apache-2.0-licensed code without every GPLv2 component being upgradable to "GPLv2 or later" -- a distinction buried in a SPDX identifier that most build pipelines never check. MIT and Apache 2.0 are mutually compatible with almost everything, including each other and GPL, which is exactly why permissive-license sprawl feels safe until one GPL package gets pulled in three dependency layers deep by a transitive dependency nobody on the team chose directly.
How do you audit a dependency tree for license conflicts at scale?
You can't do it manually past a handful of direct dependencies -- a mid-size Node.js or Java service can easily carry 500-plus transitive packages for every dozen direct ones declared in a manifest file, and each transitive package brings its own license, version, and compatibility profile. The only scalable approach is generating a Software Bill of Materials (SBOM) in a standard format like CycloneDX or SPDX for every build, then running automated license-compatibility checks against that SBOM before the artifact ships, not after. Effective programs gate this in CI: a pull request that introduces a GPLv3 dependency into a proprietary SaaS product should fail a policy check the same way a critical CVE would, before a human ever has to notice it in a legal review. Static dependency-tree scanning alone isn't sufficient either, because a license risk that lives in code your application never actually calls carries a different priority than one compiled into your shipped binary -- which is where reachability matters as much for license risk as it does for vulnerability triage.
How Safeguard Helps
Safeguard treats license risk as a first-class supply chain signal, not a separate legal spreadsheet. Every scan generates and ingests SBOMs in CycloneDX and SPDX formats across your full dependency graph, direct and transitive, and flags GPL, AGPL, and other copyleft components the moment they enter a build. Reachability analysis narrows that list to the components your application actually loads and executes in the shipped artifact, so security and legal teams triage the GPLv3 package compiled into production before the MIT-licensed dev dependency that never ships. Griffin AI, Safeguard's reasoning engine, reads license text and package metadata together to catch edge cases -- dual-licensed packages, "or later" clauses, embedded fonts or assets with their own terms -- that keyword-based scanners miss. When a policy violation is confirmed, Safeguard opens an auto-fix pull request swapping the risky dependency for a permissively licensed, functionally equivalent alternative, turning a legal finding into a merged fix in the same workflow your engineers already use.