In March 2024, Redis Labs re-licensed its core database from the permissive BSD license to a dual SSPL/RSALv2 scheme, instantly reclassifying thousands of downstream deployments as non-compliant with their own procurement policies. It was the third major license swap in three years, following Elastic's move to SSPL in 2021 and HashiCorp's shift of Terraform to the Business Source License in August 2023. Each change forced legal, security, and procurement teams to re-audit software bills of materials (SBOMs) they thought were already settled. This is the reality of open source license risk in 2026: it is no longer a one-time legal review before shipping a product. It is a continuously moving target shaped by maintainer decisions, courtroom precedent, and a wave of new regulation — from the EU Cyber Resilience Act to SEC disclosure expectations — that treats license and provenance data as a compliance obligation, not a courtesy. Below is what changed, what the numbers say, and where the exposure actually sits.
What Makes an Open Source License a Regulatory Risk, Not Just a Legal One?
An open source license becomes a regulatory risk the moment a government agency, rather than a competitor, is the one checking your compliance. Historically, license disputes were private matters resolved between a copyright holder and an infringing vendor — the Free Software Foundation's decade-long campaign against Cisco/Linksys over GPL violations in router firmware, settled in 2009, is the textbook example. That dynamic has changed. The EU Cyber Resilience Act (CRA), which entered into force in December 2024 with most obligations applying from December 11, 2027, requires manufacturers of "products with digital elements" to document the provenance, license, and known vulnerabilities of every open source component in a machine-readable SBOM as a condition of CE marking. Under the CRA, an unresolved GPL conflict or an undisclosed AGPL dependency isn't just a contract breach — it's a market-access problem enforced by national authorities with fines up to €15 million or 2.5% of global turnover.
Which License Changes Since 2021 Should Compliance Teams Actually Track?
Three re-licensing events — Elastic (2021), HashiCorp (2023), and Redis (2024) — should sit at the top of every compliance team's watch list because each retroactively changed the compliance status of code already in production. Elastic switched Elasticsearch and Kibana from Apache 2.0 to SSPL in January 2021, prompting AWS to fork the project into OpenSearch; Elastic then partially reversed course in 2024 by adding AGPL v3 as a third licensing option. HashiCorp moved Terraform, Vault, and Consul from the permissive Mozilla Public License to the Business Source License in August 2023, triggering the community fork OpenTofu under the Linux Foundation. Redis followed the same playbook in March 2024, dropping its BSD-3-Clause license for a dual SSPL/RSALv2 model, only to partially walk it back to AGPLv3 in May 2025 after community and vendor pushback. None of these changes required a single line of code to be modified — the risk materialized purely at the license layer, which is exactly why static, one-time license reviews miss it.
How Do License Violations Actually Turn Into Litigation?
License violations turn into litigation when a copyright holder can show continued distribution of GPL-covered code without corresponding source disclosure, and the Vizio case is the clearest recent example. The Software Freedom Conservancy sued Vizio in California state court in 2021, and again in federal court in 2024, alleging that Vizio's SmartCast TV software incorporated GPLv2 and LGPL-licensed code (including a Linux kernel and BusyBox) without providing the complete corresponding source as the licenses require — a case still winding through the courts in 2025 and closely watched because it treats GPL compliance as a consumer-protection and warranty issue, not just a copyright one. Separately, in the enterprise software space, SAP and Oracle audits routinely surface open source components embedded in commercial products without license reconciliation, turning what should be a routine renewal into a multi-million dollar back-licensing negotiation. The common thread: these disputes almost never start with a security bug. They start with a component nobody flagged when it was pulled into the build.
What Do New SBOM and Disclosure Rules Actually Require?
New SBOM regulations require organizations to produce a structured, machine-readable inventory of every open source component and its license — and the bar for "complete" has risen sharply since 2021. The U.S. framework began with Executive Order 14028 in May 2021, which directed NIST and led to the NTIA's "Minimum Elements for a Software Bill of Materials" in July 2021, requiring supplier name, component name, version, dependency relationships, and — critically — license data for any software sold to the federal government. CISA has since layered on VEX (Vulnerability Exploitability eXchange) attestations. In parallel, the EU CRA and the EU AI Act (obligations phasing in through 2026-2027 for high-risk AI systems) both push license and provenance transparency into product compliance files, and the SEC's 2023 cybersecurity disclosure rule increases pressure on public companies to know what's in their software supply chain well before an incident forces the question. With the SPDX license list now tracking more than 600 distinct identifiers, "we use open source" is no longer a sufficient answer to any of these frameworks — regulators want the specific identifier, the specific version, and the specific obligation it creates.
Why Are AI Model Licenses Becoming the Newest Front in This Fight?
AI model licenses are becoming a new compliance front because they borrow the language of open source while attaching commercial restrictions that most SBOM tooling was never built to detect. Meta's Llama models, for instance, ship under a custom license that is not OSI-approved open source at all — it prohibits use by companies with more than 700 million monthly active users and requires attribution — yet the models are routinely pulled into pipelines and cataloged as "open source" without that distinction being flagged. The Open Source Initiative's 2024 Open Source AI Definition was published specifically to draw a line between genuinely open models and "open-weight" models with usage restrictions, but adoption of that distinction inside procurement and legal review processes is still early. As the EU AI Act's provisions for general-purpose AI models take effect, organizations that can't distinguish a true open source model license from a restrictive one in their inventory will find that gap surfacing during an audit, not before one.
Why Do Standard Vulnerability Scanners Miss This Category of Risk?
Standard vulnerability scanners miss license and regulatory risk because they are built to answer "is this component vulnerable," not "is this component legally and contractually safe to ship." A CVE scanner will flag a known exploit in a package but has no concept of whether that package just changed from MIT to SSPL, whether it triggers copyleft obligations when statically linked, or whether its license conflicts with a component three dependency layers away. Synopsys' Open Source Security and Risk Analysis reports have found license conflicts in roughly a third of the commercial codebases audited each year, and dual-licensing or license-change events are rarely caught because most SCA tools snapshot license data at ingestion and never re-check it. That gap is precisely how a permissively-licensed dependency you approved in 2022 can become an SSPL or BSL obligation in 2026 without anyone on the team noticing until a customer's legal team asks for the SBOM.
How Safeguard Helps
Safeguard treats license and regulatory exposure as a first-class supply chain signal, not an afterthought bolted onto vulnerability scanning. It continuously monitors every open source component in your inventory for license changes — not just at ingestion, but for the entire life of the dependency — so a Redis-style re-licensing event or a copyleft obligation introduced by a transitive dependency gets flagged the moment it appears, not the moment a customer asks. Safeguard generates and maintains SBOMs aligned with NTIA minimum elements and CRA documentation requirements, mapping each component to its current SPDX license identifier, obligation type (permissive, weak copyleft, strong copyleft, source-available, custom/restricted), and any known litigation or enforcement history tied to that license or maintainer. For AI and ML dependencies, Safeguard distinguishes genuinely open source models from restricted "open-weight" licenses so they don't get miscategorized in procurement review. And because regulatory frameworks like the CRA and the EU AI Act require evidence, not just intent, Safeguard produces audit-ready compliance artifacts that map directly to what regulators and enterprise customers are starting to ask for — turning license and regulatory risk from a surprise legal bill into a tracked, manageable part of the software supply chain.