A single unvetted AGPL dependency can force a company to open-source a proprietary codebase; a single unvetted "no license" package can leave legal with nothing to point to when a customer's procurement team asks for proof. Both scenarios trace back to the same root problem: most organizations don't actually know what open source licenses are running in production. The 2025 Black Duck OSSRA report found that 33% of audited codebases contained open source components with no discernible license at all, and NuGet's own registry shows roughly 27% of packages ship with no license declaration and another 32% flagged NOASSERTION — meaning automated tools can't even guess. As platforms like Aikido Security have folded license scanning into broader application security suites, and as GPL enforcement litigation like Software Freedom Conservancy v. Vizio heads to trial in 2026, open source license compliance has stopped being a legal afterthought and become an engineering requirement. This piece breaks down what that requirement actually involves.
What is open source license compliance, and why is it suddenly a boardroom issue?
Open source license compliance is the practice of identifying every open source license obligation attached to the code your product ships, and satisfying those obligations before release — attribution, source disclosure, patent grants, or outright prohibitions on commercial use. It became a boardroom issue for three concrete reasons converging in 2024-2026. First, litigation risk went from theoretical to active: Software Freedom Conservancy sued Vizio in October 2021 over GPLv2 and LGPLv2.1 source-disclosure obligations tied to SmartCast, Vizio's Linux-based smart TV software; a California judge rejected Vizio's motion for summary judgment in January 2024, and as of a December 2025 ruling and a February 2026 order, the case is headed to a jury trial on whether consumers can enforce the GPL as third-party beneficiaries. Second, regulation caught up: the EU Cyber Resilience Act, which entered into force in December 2024, requires manufacturers to document components and their licenses as part of conformance, with software bill of materials expectations phasing in through 2027. Third, M&A due diligence now routinely kills or re-prices deals over license findings — a copyleft component buried four dependency layers deep in an acquisition target's codebase can trigger a source-disclosure obligation the acquirer never priced in.
How does Aikido Security's license scanning actually work?
Aikido Security scans manifest files and lockfiles across a repository, resolves each declared and transitive dependency's license from package registry metadata, and flags the result against a policy the customer configures — for example, "block AGPL, warn on LGPL, allow MIT/Apache-2.0." The product, built by a Ghent-based team that reached unicorn status in January 2026 after a $60 million Series B at a $1 billion valuation, packages license scanning as one module inside a broader platform that also covers SAST, secrets detection, container scanning, and IaC checks. Aikido generates SBOMs in CycloneDX, SPDX, or CSV format, pulls copyright and license metadata from package registries to populate them, and can fail a CI build when a disallowed license is detected in a new pull request. It also extends the same license checks into container images, catching licenses introduced through OS packages rather than just application dependencies. For a team that has never done any license review, this is a meaningful step up from spreadsheets — but the coverage is bounded by what registry metadata and lockfiles can tell you, which is narrower than it sounds.
Which open source licenses create the most compliance risk?
Copyleft licenses — GPL, LGPL, AGPL, and their variants — create the most compliance risk because they impose obligations that propagate to code that merely links against or, in AGPL's case, provides network access to the licensed component. The SPDX License List, the closest thing the industry has to a canonical registry of license text, has grown past 600 distinct identifiers, roughly double what it tracked a decade ago — license proliferation itself is now a compliance burden, since a scanner has to correctly classify obscure or custom variants rather than just the "big five." AGPL-3.0 is the sharpest edge case: unlike GPL, its network-use clause means offering a modified version as a hosted service triggers the same source-disclosure obligation that shipping a binary would under GPL, which is why companies like MongoDB (with SSPL, a further-restricted derivative) and Elastic moved away from pure open source licensing in the first place after seeing cloud providers repackage their software without reciprocation. Permissive licenses (MIT, Apache-2.0, BSD-3-Clause) carry far lower legal risk but aren't risk-free — Apache-2.0's patent grant and termination clause, and BSD's attribution requirements, still need to be tracked and satisfied at ship time, particularly for regulated customers who require a complete attribution notice file (a "NOTICE" or "THIRD-PARTY-LICENSES" document) as a contractual deliverable.
How real is license litigation risk, and what does it actually cost?
License litigation risk is real and current, not hypothetical: beyond SFC v. Vizio, the Software Freedom Conservancy has run active GPL enforcement actions against multiple consumer electronics and networking vendors over the past decade, and the pattern is consistent — a vendor ships GPL-licensed Linux-based firmware, a compliance group requests corresponding source under Section 3 of the license, the vendor stalls or refuses, and litigation follows years later once informal enforcement fails. The cost isn't limited to settlements or judgments. Engineering cost dominates: retrofitting license compliance into a product line that shipped without it means auditing every release going back to the earliest shipped version, which for a hardware vendor with years of firmware history can mean months of forensic dependency reconstruction. Deal cost is the other half — private equity and strategic acquirers increasingly run open source license audits as a standard diligence workstream, and an unresolved AGPL or GPL finding discovered during that process routinely becomes a purchase-price adjustment or an indemnification carve-out, not just a line item to fix later.
What do manifest-based scanners like Aikido miss?
Manifest-based scanners miss anything that isn't declared in a lockfile or resolvable from registry metadata, which in practice means vendored code, statically linked binaries, container base-image contents beyond the package manager's own records, and code copied directly into a repository without going through a package manager at all. A scanner reading package-lock.json or requirements.txt sees what npm or PyPI say the license is — but registry-declared license fields are frequently wrong or stale relative to the actual LICENSE file in the source repository, and NOASSERTION packages (the roughly 32% of NuGet packages mentioned earlier) return no answer at all rather than a wrong one, which is arguably worse because it looks like a clean scan. The other gap is transitive depth: dependency graphs on modern JavaScript and Java projects routinely run 5-10 levels deep, and a copyleft license introduced at level 8 by a package with almost no name recognition is exactly the kind of finding that a shallow scan, or a scan that times out on large graphs, will quietly drop. License obligations also change on version bumps — a dependency that shipped under MIT in one release can relicense under a more restrictive license in the next (as happened when several formerly-permissive projects moved to Business Source License or SSPL variants over the past few years), and a point-in-time scan that isn't re-run on every dependency update will miss the transition entirely.
How Safeguard Helps
Safeguard treats license data as a first-class signal alongside vulnerabilities, not a bolted-on report generated once a quarter. Our SBOM generation and ingestion module resolves license identifiers from actual source-tree license files and copyright headers, not just registry metadata, and cross-checks that against SPDX identifiers to catch the NOASSERTION and stale-metadata gaps that trip up manifest-only scanners. With 100-level dependency depth scanning, Safeguard resolves license obligations at the depth where copyleft components actually hide — not just direct dependencies — and re-evaluates the full graph on every dependency update, so a relicense event doesn't sit undetected until the next quarterly audit. License policy runs through the same policy engine as vulnerability and malware policy, meaning a team can block AGPL and require legal review for LGPL in the same gate that already blocks critical CVEs and known-malicious packages, with no separate tool or dashboard to maintain. For M&A and vendor risk scenarios, the TPRM module extends license visibility to third-party and acquired codebases, surfacing copyleft and no-license findings before they become a purchase-price adjustment. And because reachability analysis already cuts 60-80% of vulnerability noise by identifying which code paths actually execute, the same dependency graph gives legal and engineering teams a single, accurate source of truth for what's shipping — and under what terms — rather than reconciling separate SCA and license reports that were never guaranteed to agree.