Every modern application is a legal document as much as a technical one. When a build pulls in a package under GPL-3.0, AGPL-3.0, or a source-available license like SSPL, it can trigger obligations to disclose source code, publish modifications, or avoid commercial use entirely — obligations most engineering teams never read before running npm install. License scanning is the automated process of identifying every open source license attached to every dependency in an application, flagging the ones that create legal, commercial, or compliance risk. It matters more than ever: Redis switched its license from BSD to a source-available model in March 2024, Elastic moved from Apache 2.0 to SSPL in January 2021, and HashiCorp shifted Terraform from MPL to BSL in August 2023 — each change altering the legal terms under which thousands of downstream companies were already running that code.
What is license scanning and how does it work?
License scanning is the automated inventory and evaluation of every open source license present in a codebase, from direct dependencies down to transitive sub-dependencies four or five layers deep. Tools parse package manifests and lockfiles — package-lock.json, requirements.txt, go.sum, pom.xml, Gemfile.lock — to build a dependency tree, then match each component's declared or detected license against the SPDX License List, which currently catalogs more than 600 standardized license identifiers. Where a package's metadata is missing or wrong (common in older or abandoned projects), mature scanners fall back to file-level fingerprinting against known license text, similar to how tools like ScanCode Toolkit or FOSSology detect licenses embedded in source headers, COPYING files, or README sections. The output is typically mapped onto a Software Bill of Materials (SBOM) in SPDX or CycloneDX format, so license data travels with the component inventory rather than living in a separate spreadsheet.
Which open source licenses create the most legal exposure?
Copyleft and network-copyleft licenses create the most legal exposure because they impose reciprocal obligations that permissive licenses do not. Permissive licenses — MIT, Apache-2.0, BSD-3-Clause — let you use, modify, and redistribute code with minimal requirements beyond attribution, and they cover the majority of packages on npm and PyPI. Weak copyleft licenses like LGPL-2.1 and MPL-2.0 only require you to share modifications to the licensed files themselves. Strong copyleft licenses — GPL-2.0 and GPL-3.0 — require that any derivative work you distribute be released under the same license, which is a serious problem if that derivative work is your proprietary product. AGPL-3.0 goes further, extending that disclosure obligation to software offered as a network service (SaaS), which is precisely why MongoDB moved off AGPL in 2018 in favor of its own SSPL. Source-available licenses such as SSPL, BSL 1.1, and the Elastic License restrict competitors from offering the software as a managed service, which is a business risk rather than a copyleft one, but it still requires legal review before use in a commercial product.
What happens when companies ignore license compliance?
Ignoring license compliance has produced real litigation, not hypothetical risk. The Free Software Foundation sued Cisco in December 2008 over GPL violations in Linksys router firmware, reaching a settlement in May 2009 that required Cisco to appoint a compliance officer and make a payment to the FSF. Between 2007 and 2009, the Software Freedom Law Center filed a string of GPL enforcement suits on behalf of BusyBox developers against more than a dozen companies, including Verizon, Best Buy, Samsung, and Westinghouse, for shipping BusyBox in devices without providing corresponding source. In Artifex v. Hancom (2017), a U.S. federal court ruled that the GPL is enforceable as a binding contract, not merely a permissive grant that evaporates on breach, giving license holders contract-law remedies in addition to copyright claims. More recently, Software Freedom Conservancy's 2021 suit against Vizio over GPL and LGPL source-code obligations in its SmartCast TV software reached the California Supreme Court, which in 2024 held that consumers can enforce GPL compliance as third-party beneficiaries of the license — meaningfully widening who can bring a claim.
How can a dependency's license change without any of your code changing?
A dependency's license can change the moment its maintainer publishes a new version, with zero changes to your own source. This is the fastest-growing category of license risk because it defeats one-time audits: you can be fully compliant on Monday and out of compliance after a routine npm update on Tuesday. Redis Labs relicensed Redis from the permissive BSD-3-Clause to the source-available RSALv2/SSPL combination in March 2024, prompting the Linux Foundation to back a BSD-licensed fork, Valkey, within weeks. Elastic relicensed Elasticsearch and Kibana from Apache 2.0 to SSPL in January 2021, then reversed part of that decision in August 2024 by re-releasing under AGPL-3.0 alongside SSPL. HashiCorp moved Terraform, Vault, and other tools from the permissive Mozilla Public License to the more restrictive Business Source License in August 2023, which led a group of vendors to fork Terraform into OpenTofu under the Linux Foundation. In every case, teams that pinned dependency scanning to an annual audit rather than continuous CI checks were the last to know their license posture had changed.
What regulations now require license and SBOM visibility?
Regulators now require organizations to produce machine-readable records of every component's license and origin, not just its vulnerabilities. In the United States, Executive Order 14028 (May 2021) directed federal agencies to require SBOMs from software vendors, and the NTIA's "minimum elements" guidance published in July 2021 specified that a compliant SBOM must include supplier, component name, version, and dependency relationships — license data is a standard extension most agencies now expect. In the European Union, the Cyber Resilience Act entered into force in December 2024, with SBOM and vulnerability-handling obligations for manufacturers of products with digital elements phasing in through December 2027. The two dominant machine-readable formats for carrying this data — SPDX, which reached version 3.0 in April 2024, and CycloneDX, at version 1.6 in the same year — both include native fields for license identifiers, which is what lets a license scanner and an SBOM generator share a single source of truth instead of maintaining two disconnected inventories.
How Safeguard Helps
Safeguard treats license risk as part of the same continuous pipeline as vulnerability and reachability data, not a separate one-off audit. Every SBOM Safeguard generates — or ingests from an existing CycloneDX or SPDX feed — carries license metadata down to transitive dependencies, so a Redis-style relicensing or a newly introduced AGPL transitive package surfaces the moment it enters a build, not at the next quarterly review. Griffin AI correlates that license data with reachability analysis, distinguishing a copyleft package that's actually linked into your shipped binary from one that sits unused in a dev-only dependency tree, so legal review time goes to real exposure instead of noise. Where a license conflict or a disallowed package is confirmed, Safeguard opens an auto-fix pull request to swap in a permissively licensed alternative or pin to a pre-relicensing version, giving engineering teams a reviewable, one-click path back to compliance instead of a spreadsheet ticket.