In March 2024, Redis Labs replaced the open source BSD license on Redis with a dual Server Side Public License (SSPL) / RSALv2 license, cutting off cloud providers from freely repackaging it and triggering the Linux Foundation-backed Valkey fork within weeks. Elastic did something similar in January 2021, moving Elasticsearch and Kibana from Apache 2.0 to SSPL, then partially reversed course in August 2024 by re-adding AGPL as an option. HashiCorp moved Terraform from Mozilla Public License 2.0 to the Business Source License in August 2023, spawning the OpenTofu fork. These aren't edge cases — they're what happens when license terms shift underneath production dependency trees, and most engineering teams don't find out until a build breaks, a legal team sends a memo, or a customer's procurement audit flags it. Open source software license compliance is the practice of tracking which licenses govern every component in your software, understanding what each one obligates you to do, and catching violations before they become legal, financial, or shipping-blocking problems.
What is open source license compliance?
Open source license compliance means knowing the license of every open source component in your product and satisfying its legal obligations before you distribute software. Every open source package — from a 2KB npm utility to a Linux kernel module — ships under a license that dictates what you can do with it: MIT and Apache 2.0 are permissive and require only attribution, while GPLv2, GPLv3, and AGPLv3 are copyleft and can require you to release your own source code if you distribute a "derivative work." A single modern application easily pulls in 500-1,000+ transitive dependencies through package managers like npm, pip, and Maven, each carrying its own license, and license compliance is the process of enumerating all of them, classifying the obligations, and resolving conflicts (like a GPLv3 library linked into a proprietary SaaS binary) before code ships to production or to a customer.
Why did Redis, Elasticsearch, and Terraform change their licenses?
These vendors relicensed because permissive and weak-copyleft licenses let competitors — mainly hyperscale cloud providers — resell their software as a managed service without contributing back or paying for it. Redis's move to SSPL/RSALv2 in March 2024 was explicitly aimed at stopping cloud vendors from offering "Redis-as-a-Service" without a commercial agreement; the backlash was swift enough that AWS, Google, Oracle, and Ericsson formed the Linux Foundation's Valkey project as a BSD-licensed fork within about two weeks. MongoDB did the same thing earlier, switching to SSPL in October 2018 after years of watching cloud providers monetize hosted MongoDB. For a security or platform team, the practical risk isn't philosophical — it's that a dependency you pinned as "Apache 2.0, safe to redistribute" can become SSPL or BSL in a routine version bump, and if your CI/CD pipeline auto-upgrades minor versions, you can inherit a materially different license obligation without anyone approving it.
What legal risks come from license violations like copyleft contamination?
The legal risk is that copyleft "contamination" can force you to release proprietary source code or expose you to a breach-of-contract lawsuit, and this isn't theoretical — courts have enforced it. The Software Freedom Conservancy sued Vizio in 2021 over GPL/LGPL violations in Vizio's SmartCast firmware (built on a Linux kernel and other copyleft components), and in June 2024 the California Supreme Court ruled that GPL license terms can be enforced as third-party-beneficiary contract claims, letting the case proceed rather than being dismissed as a mere copyright dispute. Earlier, the Software Freedom Law Center and Software Freedom Conservancy brought roughly 20 enforcement actions between 2007 and 2009 against companies — including Best Buy, Samsung, and Westinghouse — for shipping BusyBox (GPLv2) in consumer electronics without providing corresponding source. Cisco settled a GPL violation claim from the FSF back in 2003 over Linksys router firmware. The common thread: none of these companies set out to violate a license — they inherited copyleft code through a vendor, a firmware SDK, or a transitive dependency and never audited it.
How many codebases actually have license compliance problems?
Most of them: Synopsys's 2024 Open Source Security and Risk Analysis (OSSRA) report found that 96% of the 1,067 commercial codebases it scanned contained open source code, and 65% of those codebases contained license conflicts — meaning at least two components with incompatible license terms coexisting in the same build. The same report found that a substantial share of components shipped with no identifiable license at all, or a custom, non-standard license that legal teams have to review manually because no off-the-shelf policy engine recognizes it. Open source now makes up an estimated 70-90% of the code in a typical commercial application by volume, which means license risk isn't concentrated in a handful of core dependencies — it's distributed across hundreds of transitive packages that no one on the engineering team has ever manually reviewed, let alone tracked through version bumps.
Which license types create the most risk, and why?
Strong copyleft licenses — GPLv2, GPLv3, and AGPLv3 — create the most risk because they can require you to disclose source code, while permissive licenses like MIT, BSD, and Apache 2.0 rarely require more than attribution. AGPLv3 is the strictest in common use: unlike GPL, which is triggered by distribution, AGPL's "network use" clause is triggered when users interact with the software over a network, meaning a SaaS company that never ships a binary to a customer can still trigger disclosure obligations just by running AGPL-licensed code on a server. Source-available licenses like SSPL, BSL, and the Elastic License sit in a gray zone: they're not OSI-approved open source licenses at all, but they're common enough in the ecosystem (Redis, MongoDB pre-2024, Terraform, Elasticsearch) that automated tooling has to specifically classify them rather than lumping them in with permissive licenses. A dependency scanner that only checks for "GPL vs. not GPL" will miss SSPL and BSL entirely, which is exactly the category that caused the most disruption in 2023-2024.
How do you detect and fix license violations before they ship?
You detect them by generating a complete software bill of materials (SBOM) for every build and running it through a license policy engine before code merges or deploys, not after. Manual license review doesn't scale past a handful of direct dependencies — it has to account for transitive dependencies (a package you didn't choose, pulled in by one you did), license changes introduced in a routine npm update or pip install --upgrade, and components with no machine-readable license metadata at all. Effective detection means scanning at the pull-request stage so a GPLv3 library never reaches a release branch, maintaining an SBOM in CycloneDX or SPDX format that maps every component to its declared license and its actual license text (they sometimes disagree), and setting policy rules by team — a library used only in internal tooling might tolerate AGPL, while anything shipped to a customer binary cannot.
How Safeguard Helps
Safeguard treats license compliance as a first-class part of software supply chain security rather than a one-time legal checklist. Safeguard generates and ingests SBOMs across your build pipeline, giving security and legal teams a continuously updated inventory of every component's license — including transitive dependencies and source-available licenses like SSPL and BSL that generic scanners misclassify. Griffin AI flags license changes and copyleft-risk components as they enter the codebase and correlates them with reachability analysis, so teams can tell the difference between a GPL utility that's actually linked into a shipped binary and one that's dead code never invoked at runtime — cutting remediation noise dramatically. When a violation is confirmed, Safeguard can open an auto-fix pull request that swaps the offending dependency for a permissively licensed alternative or pins a pre-relicense version, closing the gap between detection and resolution before the code ever reaches production.