A software license is the legal instrument that determines whether your engineering team can use, modify, distribute, or sell code someone else wrote — and under what conditions. That's the working software license definition this glossary entry uses throughout. Every open source software license attached to a package pulled into a build, from a two-line npm utility to a multi-million-line database engine, spells out those same terms. Get the terms wrong and the consequences range from a forced code disclosure to a breach-of-contract lawsuit. The Software Package Data Exchange (SPDX) license list, maintained by the Linux Foundation, now catalogs more than 600 distinct license identifiers, and Synopsys's 2024 Open Source Security and Risk Analysis report found that 96% of scanned commercial codebases contained open source code, with 54% containing at least one license conflict. Despite that exposure, license review is still often a manual, once-a-quarter legal exercise rather than a continuous, automated part of the software supply chain. This glossary entry answers the question "what is a software license?" in practical terms: what it actually governs, why the terms diverge so sharply between projects, and how security teams can track license risk at scale.
What Is a Software License?
A software license is a legal grant from a copyright holder that specifies the permissions and obligations attached to using their code. Without one, default copyright law applies, and technically no one but the author has the right to copy, modify, or redistribute the software at all — which is why "unlicensed" code found in a repository (no LICENSE file, no SPDX tag) is actually higher legal risk than code under a restrictive license, not lower. A license typically covers four things: the right to use the software, the right to modify it, the right to redistribute it (as-is or modified), and any conditions attached to those rights, such as attribution, source disclosure, or patent grants. The Open Source Initiative (OSI) has approved over 100 licenses as meeting its Open Source Definition, but in practice fewer than a dozen — MIT, Apache-2.0, BSD-3-Clause, GPL-2.0, GPL-3.0, LGPL, MPL-2.0, and AGPL-3.0 — account for the overwhelming majority of dependencies in a typical application. Any one of those is a workable software license example: each grants the same core rights (use, modify, redistribute) while attaching a different set of conditions.
What's the Difference Between Permissive and Copyleft Licenses?
Permissive licenses let you do almost anything with the code, including relicensing it as proprietary, while copyleft licenses require derivative works to carry the same license forward. The MIT License, first used for the X11 Window System in 1987 and later popularized as "MIT" in the 1990s, is 21 lines long and imposes exactly one real condition: keep the copyright and permission notice. As the most permissive mainstream terms in wide use, the MIT software license is often the reference point teams reach for when writing an internal license allowlist. Apache License 2.0, published by the Apache Software Foundation in January 2004, adds an explicit patent grant and trademark restrictions but is still permissive. GitHub's 2023 Octoverse data shows MIT used in roughly 44% of licensed public repositories and Apache-2.0 in about 13%, making permissive terms the default for most of the ecosystem. Copyleft is a different animal: the GNU General Public License v3, released by the Free Software Foundation on June 29, 2007, requires that any software distributed with GPL-licensed code also be licensed under the GPL, with full corresponding source made available. The GNU Affero GPL (AGPL-3.0), finalized in November 2007, closes the "SaaS loophole" by triggering the same disclosure obligation even when the software is only offered as a network service and never distributed as a binary — which is exactly why many enterprises ban AGPL dependencies outright in internal policy.
Why Do Open Source License Conflicts Create Legal Risk for Enterprises?
License conflicts create legal risk because combining incompatible licenses in one product can void your right to distribute it at all, and courts have started treating open source license terms as enforceable contracts, not just copyright notices. The clearest example is Software Freedom Conservancy v. Vizio, filed in California in 2021, which argued that Vizio's smart TVs used GPL- and LGPL-licensed software (Linux kernel, BusyBox) without providing the required corresponding source code. In June 2024, the California Supreme Court declined further review after an appellate ruling allowed the case to proceed on breach-of-contract grounds — establishing that GPL compliance failures aren't just a copyright question but a contract one, with contract law's longer statute of limitations and different remedies. Commercial license changes create a second flavor of risk: MongoDB switched from AGPL-3.0 to the Server Side Public License (SSPL) in October 2018 specifically to stop cloud providers from offering MongoDB-as-a-service without contributing back, and Elastic moved from Apache 2.0 to SSPL/Elastic License in January 2021 for the same reason (Elastic later relicensed core Elasticsearch back to AGPL in August 2024). HashiCorp converted Terraform, Vault, and other tools from MPL 2.0 to the Business Source License in August 2023, triggering the community Terraform fork OpenTofu within weeks. Any of these changes can silently convert a dependency your build has used safely for years into one that violates your company's licensing policy overnight.
How Do SBOMs Track Software Licenses?
Software Bills of Materials track licenses by attaching a license identifier to every component in a structured, machine-readable inventory of everything shipped in a build. Both major SBOM formats have dedicated license fields: SPDX documents carry a licenseConcluded and licenseDeclared field per package using SPDX license expression syntax — (MIT OR Apache-2.0) for dual-licensed code is a common software license example in the wild — while CycloneDX represents licenses as structured objects that can reference an SPDX ID or an arbitrary license text when no standard identifier applies. The US National Telecommunications and Information Administration's 2021 minimum elements for an SBOM, later folded into CISA guidance, lists license information as a recommended field precisely because procurement and legal teams need it to clear software for use before deployment, not after. In practice, that means every open source software license in the dependency tree — not just the top-level ones a developer chose deliberately — needs to show up in the SBOM. The gap in practice is that most SBOMs are generated once at build time and never diffed against policy — a license violation introduced by a transitive dependency bump can ship for months before anyone notices, because nobody is continuously ingesting and re-evaluating the SBOM against a current license allowlist.
What Happens When a Project Changes Its License?
When a project changes its license, every downstream consumer's compliance posture changes with it, whether or not they update the dependency. License changes are typically forward-only and version-specific: HashiCorp's BSL change applied to versions of Terraform released after August 10, 2023, meaning code already pinned to Terraform 1.5.x or earlier stayed under MPL 2.0, but any team that ran an unpinned upgrade inherited BSL terms — including its restriction on offering the software as a competing commercial product — without a single line of their own code changing. This is why pinning a dependency version doesn't fully insulate a team from license risk; automated dependency bots that auto-merge minor and patch updates can cross a license boundary just as easily as a major version bump, and most vulnerability-focused dependency scanners don't flag a license change as an event worth alerting on at all.
How Can Security Teams Detect License Risk in Their Codebase?
Security teams detect license risk by running automated license scanning against every direct and transitive dependency at build time, then continuously monitoring for license changes on subsequent releases. A one-time audit only captures the moment it ran; the Synopsys OSSRA 2024 data cited above also found that 31% of scanned codebases contained components with no license at all or a custom, unrecognized license — the category most likely to be missed by manual review and most likely to carry hidden restrictions. Effective detection means resolving the full transitive dependency tree (not just top-level package.json or pom.xml entries), normalizing every license to its SPDX identifier, checking that identifier against an organizational allowlist/denylist, and re-running the check on every pull request and every scheduled rebuild — not just once a quarter when legal asks for a report. Most allowlists start from a simple software license definition of "acceptable risk": permissive terms like the MIT software license or Apache-2.0 pass automatically, while anything copyleft gets routed to legal for review.
How Safeguard Helps
Safeguard extends this problem past the license field itself. Its SBOM generation and ingest pipeline produces SPDX- and CycloneDX-compliant inventories with normalized license identifiers for every direct and transitive dependency, and continuously re-ingests third-party SBOMs so a license change upstream — an SSPL relicense, a BSL conversion, an unlicensed transitive package — surfaces as an alert instead of a surprise months later. Griffin AI correlates that license data against actual usage in your codebase, so security and legal teams can see not just that an AGPL package is present, but whether it's linked into a distributed binary or only used in a build-time tool where the disclosure obligation doesn't apply. Where reachability analysis is layered on top, Safeguard shows whether a flagged component's code paths are actually reachable in your application, letting teams prioritize the license conflicts that carry real legal exposure over unused code sitting in a vendored directory. When a policy violation is confirmed, Safeguard can open an auto-fix pull request swapping the dependency for a compatible alternative or pinning it below the version where the license changed, turning a legal review cycle into a code review.