Sonatype built its brand on open source governance, and its 2024 State of the Software Supply Chain report put a number on the problem that should worry every legal and engineering leader: malicious open source packages grew 156% year over year, while license ambiguity across the 700,000+ packages ingested through Maven Central alone continues to expose companies to takedown notices, audit failures, and M&A delays. License compliance is no longer a checkbox exercise for a lone open source review board — it is a continuous, automated discipline that has to keep pace with dependency graphs that regenerate every time a developer runs npm install. Companies like IBM, Cisco, and VMware have all faced public license disputes tied to GPL-derived code shipped without proper attribution or source disclosure. This post breaks down what open source license compliance actually requires in 2026, where tools like Sonatype fit, and how Safeguard approaches the problem differently — treating license risk as part of the same continuous supply chain signal as vulnerabilities and provenance.
What Is Open Source License Compliance, and Why Does It Matter Now?
Open source license compliance is the practice of identifying every open source component in your software, determining its license obligations, and ensuring your usage — and distribution — satisfies those obligations before code ships. It matters now because the average commercial codebase is over 70% open source by volume, according to Synopsys's 2024 Open Source Security and Risk Analysis report, and 96% of scanned codebases contained at least one open source component. The same report found that 54% of codebases contained license conflicts, and 31% contained components with no license at all — meaning legal status is simply unknown. For a company preparing for acquisition, a Series C raise, or a government contract under FedRAMP, an unresolved license conflict discovered during due diligence can delay a deal by weeks. Compliance isn't a one-time audit; it's a live inventory that has to reflect every dependency added between quarterly reviews.
Why Do Copyleft Licenses Like GPL and AGPL Create the Most Risk?
Copyleft licenses create outsized risk because they impose obligations on derivative works, not just the original code, and those obligations can propagate silently through a dependency tree. GPLv3 and AGPLv3 in particular require that if you distribute a derivative work — or in AGPL's case, even offer it as a network service — you must make the corresponding source code available under the same license. This became a flashpoint in 2018 when the Software Freedom Conservancy sued VMware over alleged GPL violations in ESXi related to Linux kernel code, a case that dragged on for years before being dismissed on procedural grounds in 2021. More recently, the rise of AGPL-licensed AI and database tooling (MongoDB moved to SSPL in 2018 specifically to close what it saw as an AGPL loophole) has forced SaaS companies to re-audit their stacks, because AGPL's "network use" trigger catches hosted products that GPL alone would not. A single transitive dependency four levels deep pulling in an AGPL-licensed logging library can theoretically obligate an entire proprietary backend's source disclosure — which is exactly why automated, transitive-aware scanning matters more than manual review.
How Does Sonatype Approach License Compliance, and Where Does It Fall Short?
Sonatype approaches license compliance primarily through its Nexus Lifecycle and IQ Server products, which scan component metadata against a proprietary data set built from its Nexus Repository usage telemetry to flag license type and policy violations at build time. This works well for organizations already standardized on Sonatype's repository manager and willing to invest in policy engine configuration, but it has real gaps. First, Sonatype's license identification leans heavily on declared metadata and package registry manifests, which multiple studies — including a 2023 FOSSA analysis — found to be inaccurate or missing in roughly 15-20% of packages, requiring fallback to slower, less-automated legal review. Second, Sonatype's pricing model, which scales with component volume and adds cost for policy automation and legal risk features as separate tiers, becomes expensive fast for organizations with large monorepos or many microservices repos, and customers on community forums and G2 reviews have repeatedly flagged the license/policy engine as a premium add-on rather than a core included capability. Third, Sonatype's compliance workflow is largely decoupled from its vulnerability and malware detection pipeline, meaning teams often triage license risk and CVE risk in two separate dashboards with two separate remediation queues — slowing down the single "should this dependency ship" decision engineering teams actually need to make.
What Does a License Compliance Violation Actually Cost a Company?
A license compliance violation costs a company in three concrete ways: legal exposure, remediation engineering time, and deal friction, and all three compound the longer the violation goes undetected. On the legal side, the Software Freedom Law Center and Software Freedom Conservancy have pursued dozens of GPL enforcement actions since 2003, with settlements historically requiring public source disclosure, compliance officer appointments, and in some cases financial penalties, even when the underlying infringement was unintentional. On the engineering side, Synopsys's 2024 OSSRA report noted that resolving a single license conflict discovered late in the release cycle — after the component is already embedded in shipped binaries — takes materially longer than catching it at pull request time, because teams must often re-architect around a replacement library rather than simply swap a version pin. On the deal side, license compliance has become a standard line item in technical due diligence for M&A and enterprise procurement; a 2023 survey by the Linux Foundation and Snyk found that most organizations now require a software bill of materials (SBOM) with license attribution as part of vendor onboarding, meaning an incomplete SBOM can stall a sales cycle before a contract is ever signed.
How Do Regulations Like the EU Cyber Resilience Act Change the Compliance Bar?
Regulations like the EU Cyber Resilience Act (CRA), which entered into force in December 2024 with core obligations phasing in through December 2027, raise the compliance bar by legally mandating SBOM production and vulnerability handling processes for any "product with digital elements" sold in the EU — and license transparency is inseparable from an accurate SBOM. The CRA requires manufacturers to document the composition of their software supply chain, and while it's framed primarily around security, an SBOM that misidentifies or omits license data is definitionally incomplete under the standard's intent. In the U.S., Executive Order 14028 already pushed federal agencies toward SBOM requirements starting in 2021, and NTIA's minimum elements for an SBOM explicitly include license information as a recommended field. For companies selling into regulated sectors — finance under DORA, healthcare under HIPAA-adjacent vendor requirements, or any EU-facing product under CRA — license compliance has moved from "best practice" to a documented, auditable requirement with regulatory teeth, including CRA fines that can reach up to €15 million or 2.5% of global annual turnover for serious non-conformity.
Can Automated Tooling Actually Replace Manual Legal Review for License Risk?
Automated tooling can replace the bulk of manual legal review, but not all of it — the realistic model is automation for triage and known-license classification, with human legal review reserved for genuine ambiguity and dual-licensing edge cases. Modern scanners can now match license text against SPDX's catalog of over 700 recognized license identifiers with high confidence for the roughly 80-85% of packages that use standard, well-declared licenses. The remaining share — packages with custom licenses, missing license files, or license text embedded only in comments rather than manifests — still benefits from a legal reviewer, but the volume they need to review drops dramatically once automation handles the straightforward cases. This division of labor is what makes continuous compliance feasible at all: no legal team can manually review every one of the thousands of transitive dependencies a modern application pulls in, but they can review the dozen flagged exceptions a well-tuned scanner surfaces each sprint.
How Safeguard Helps
Safeguard treats license compliance as one signal inside a unified supply chain risk pipeline, not a separate product tier bolted onto a repository manager. Every component that enters a build is resolved through its full transitive dependency graph, matched against SPDX license identifiers, and flagged for copyleft, dual-license, or unknown-license conditions in the same policy engine that evaluates CVEs, malicious package indicators, and provenance attestations — so engineering teams get one remediation queue instead of two. Safeguard generates and maintains SBOMs continuously as dependencies change, keeping license attribution current for CRA, EO 14028, and procurement due diligence without a manual export step before every audit. Policy rules are configurable per team or business unit, so a legal team can block AGPL and unlicensed packages from shipping in customer-facing products while allowing more permissive terms for internal tooling, and every policy decision is logged for audit trail purposes. Because Safeguard prices around usage and risk coverage rather than gating legal-risk features behind a premium tier, growing organizations can extend license policy enforcement across every repository and microservice without renegotiating a contract each time headcount or repo count grows. The result is a license compliance program that scales with the dependency graph instead of falling further behind it.