Every modern codebase is a legal document as much as a technical one. Open source software licenses are the terms that dictate how software components can be used, modified, and redistributed — and they carry real legal weight. According to Black Duck's 2024 Open Source Security and Risk Analysis (OSSRA) report, 96% of the 1,067 commercial codebases audited contained open source code, with an average of 526 open source components per application. The same report found that 54% of codebases contained license conflicts, and 31% contained components with no discoverable license at all.
For a compliance or legal team, that gap between "we use open source" and "we know exactly which licenses govern our software" is where risk lives. Misattributed code, missing NOTICE files, and copyleft obligations buried four dependencies deep can turn a routine audit, M&A due diligence process, or customer security questionnaire into a scramble. This glossary post breaks down what open source licenses actually are, how tools like Black Duck approach the compliance problem, and where the real gaps remain in 2026.
What Is an Open Source License?
An open source license is a legal grant that specifies how a piece of software can be used, copied, modified, and distributed, and what obligations attach to each of those actions. The Open Source Initiative (OSI) currently lists over 100 approved licenses, but in practice, a handful dominate real-world usage. Black Duck's own scans consistently show the MIT License, Apache License 2.0, and GNU General Public License (GPL) family accounting for the majority of components found in commercial applications — MIT alone typically appears in more than 25% of scanned codebases.
Every license falls somewhere on a spectrum from permissive to restrictive. Permissive open source licenses (MIT, BSD, Apache 2.0) impose light obligations — usually just preserving a copyright notice. Restrictive, or "copyleft," licenses (GPL, AGPL, LGPL) impose conditions on how derivative works are distributed, and in the case of AGPL, even on code that is only accessed over a network rather than shipped.
Why Do License Types Matter More Than People Think?
License type matters because it determines whether using a component creates an obligation to disclose or relicense your own source code. The GPL family is "viral" in the sense that combining GPL-licensed code with proprietary code in certain ways can require the combined work to also be released under GPL terms. The Affero GPL (AGPL) extends this to SaaS: if you modify AGPL code and offer it as a network service, you may be required to publish your modifications even though you never shipped a binary.
This distinction is why companies like Google and Amazon maintain internal "banned license" lists that block AGPL and similarly restrictive licenses from production use entirely. It is also why a single misclassified dependency — say, a transitive dependency that pulls in an LGPL-licensed library statically linked rather than dynamically linked — can turn a low-risk permissive stack into a compliance incident that legal has to review before a release ships.
What Happens When Companies Get License Compliance Wrong?
Companies that violate open source license terms face lawsuits, forced code disclosure, and reputational damage, and the case history spans two decades. In 2003, the Software Freedom Law Center pursued Cisco's Linksys division over GPL violations in router firmware, resulting in a settlement requiring source disclosure. In 2015, Christoph Hellwig sued VMware in a German court alleging that ESXi improperly incorporated Linux kernel code under GPLv2 without complying with its terms. More recently, in 2021, the FSF and Software Freedom Conservancy pursued Vizio for years over GPL and LGPL compliance failures in its SmartCast TV firmware, a case that wasn't resolved until 2024 with a settlement requiring Vizio to release the source code.
These aren't edge cases confined to embedded firmware vendors. Black Duck's OSSRA reporting has shown for several consecutive years that 90%+ of audited codebases carry at least one license conflict or unlicensed component risk, meaning the exposure described above is closer to the norm than the exception across the industry.
How Does Black Duck Approach Open Source License Compliance?
Black Duck approaches license compliance primarily through Software Composition Analysis (SCA) — scanning source code and binaries to build a Bill of Materials (BOM), then matching each identified component against a license knowledge base to flag conflicts, obligations, and unknown or "No License" findings. This is the same engine underlying the annual OSSRA report, and it's effective at answering the baseline question: what open source is in this codebase, and what license governs each piece.
Where Black Duck's traditional model runs into friction is speed and workflow fit. Its scanning has historically been positioned as a periodic audit step — run before a release, an acquisition, or a customer audit — rather than a control that developers interact with on every pull request. Teams shipping multiple times a day need license findings surfaced at commit time, not discovered in a quarterly compliance sweep after the component is already three releases deep into production.
What Are the Biggest License Compliance Gaps in 2026?
The biggest gap in 2026 is transitive dependency visibility — most license violations don't come from a team's direct dependencies, they come from the second-, third-, and fourth-order dependencies those direct packages pull in silently. A single npm install of a mid-sized web framework can pull in 400+ transitive packages, and studies of package registries consistently find that 5–10% of packages in an average dependency tree carry either no declared license, a "custom" license requiring manual legal review, or a license incompatible with the declared license of the top-level package.
The second gap is AI-generated and AI-assisted code. As more code is produced with LLM coding assistants trained on large corpora that include GPL and other copyleft-licensed repositories, provenance becomes murkier — teams need to verify that generated snippets aren't reproducing licensed code verbatim, a risk that didn't meaningfully exist in this form five years ago and that most legacy SCA tooling wasn't built to detect.
The third gap is container and infrastructure-as-code sprawl. License obligations don't stop at application source — base images, bundled system libraries, and vendored binaries inside containers routinely carry their own license terms, and Black Duck's 2024 findings noted that container images frequently contain outdated or end-of-life open source components that compound both license and vulnerability risk simultaneously.
How Safeguard Helps
Safeguard treats compliance with open source software licenses as a continuous supply chain security control, not a point-in-time audit. Every build generates a Software Bill of Materials (SBOM) automatically, and Safeguard cross-references each component — including transitive dependencies several layers deep — against license data to flag copyleft obligations, license conflicts, and unlicensed or "unknown" components before they merge, not after they've shipped to production.
Because license risk and vulnerability risk both stem from the same root problem — knowing exactly what's in your software — Safeguard correlates the two in a single view. A component flagged for a GPL conflict and a known CVE gets prioritized together, so compliance and security teams aren't working from separate tools with separate backlogs. Policy enforcement happens directly in CI/CD: a pull request introducing an AGPL-licensed dependency into a proprietary codebase can be blocked automatically, based on rules your legal and engineering teams define together, rather than caught six months later during acquisition due diligence.
Safeguard also extends coverage to containers and infrastructure artifacts, not just application source trees, closing the gap where license obligations hide in base images and vendored binaries. For teams that have relied on periodic Black Duck-style scans and found themselves surprised by findings after the fact, the difference is architectural: compliance checks run at the speed of the pipeline, with full transitive visibility, so the question "what licenses govern our software" has an answer that's always current — not one that's accurate as of the last quarterly scan.