Every dependency your build pulls in carries a license, and that license dictates what you can legally do with the code — ship it, modify it, relicense it, or none of the above. Knowing the different types of licenses sitting in your dependency tree matters well before an audit forces the question. Open source licenses fall into a handful of distinct families: permissive (MIT, Apache 2.0, BSD), weak copyleft (LGPL, MPL 2.0), strong copyleft (GPLv2, GPLv3), network copyleft (AGPLv3), and a growing category of "source-available" licenses (SSPL, Elastic License, RSALv2) that the OSI, Google, and the Linux Foundation don't consider open source at all. The SPDX License List now catalogs more than 700 distinct identifiers, and a 2015 GitHub study of 2.8 million repositories found that 85% shipped with no license file whatsoever. For security and legal teams tracking thousands of transitive dependencies, knowing which license type sits in a build isn't academic — it determines compliance exposure, M&A due diligence outcomes, and in some cases whether a SaaS product can legally exist in its current form.
What Are the Main Types of Open Source Licenses?
The main types of open source licenses are permissive, weak copyleft, strong copyleft, network copyleft, and non-OSI "source-available" licenses, each imposing progressively stricter obligations on downstream use. Permissive licenses (MIT, Apache 2.0, BSD-2-Clause, BSD-3-Clause) let you use, modify, and redistribute code — including in closed-source products — with little more than an attribution requirement. Weak copyleft licenses (LGPL 2.1/3.0, MPL 2.0) require you to share modifications to the licensed files themselves but not to your own surrounding code. Strong copyleft licenses (GPLv2, GPLv3) require that any derivative work distributed to others be released under the same license, in full source form. Network copyleft (AGPLv3) extends that obligation to software accessed over a network, closing the "SaaS loophole" that plain GPL leaves open. The Open Source Initiative (OSI) has approved roughly 120 licenses as meeting its Open Source Definition; everything outside that list, including source-available licenses, falls outside the strict OSI definition even if the source code is publicly visible.
What Is a Permissive License and Why Does MIT Dominate?
A permissive license grants broad rights to use, modify, and redistribute code with minimal conditions, and the MIT License is the most widely used because it's short, simple, and imposes almost no downstream obligations. The MIT License, drafted at MIT in the late 1980s, is roughly 170 words and requires only that the copyright notice and license text be preserved in copies. Apache License 2.0, released by the Apache Software Foundation in January 2004, adds an express patent grant and a patent-retaliation clause, which is why many enterprises prefer it over MIT for anything involving hardware or algorithmic IP. The BSD licenses, tracing back to UC Berkeley's 1988 release of BSD Unix code, come in 2-clause and 3-clause variants, the latter adding a non-endorsement clause. According to Synopsys's 2024 Open Source Security and Risk Analysis (OSSRA) report, permissive licenses account for the large majority of components found in the 1,067 commercial codebases it audited, with MIT alone appearing in the majority of scanned repositories.
What Is a Copyleft License and How Do GPL, LGPL, and AGPL Differ?
A copyleft license requires that derivative works be distributed under the same license terms, and GPL, LGPL, and AGPL differ mainly in how far that requirement reaches. GPLv2 (1991) and GPLv3 (June 29, 2007) require full source disclosure for any software that statically or dynamically links against GPL code and is then distributed — GPLv3 additionally added anti-tivoization provisions and an explicit patent grant that GPLv2 lacked. LGPL (Lesser GPL, versions 2.1 and 3.0) was carved out specifically so libraries could be linked into proprietary applications without forcing the whole application under GPL, provided the LGPL component itself remains separately modifiable. AGPLv3, published by the Free Software Foundation in November 2007, closes the loophole that let companies run modified GPL code as a hosted service without ever "distributing" it — under AGPL, offering the software over a network counts as distribution, triggering source-disclosure obligations. This distinction is why many companies maintain an internal policy that flatly bans AGPL-licensed dependencies from production services.
What Happened When Companies Tried to Move Away From Open Source Licensing?
Several major infrastructure vendors relicensed away from OSI-approved terms in the last decade, and each move triggered a community fork. MongoDB switched its server code from AGPLv3 to the Server Side Public License (SSPL) in October 2018 specifically to stop cloud providers from offering MongoDB-as-a-service without contributing back. Elastic followed in January 2021, moving Elasticsearch and Kibana from Apache 2.0 to a dual SSPL/Elastic License model; AWS responded within three months by forking the pre-change code into OpenSearch in April 2021. Redis Labs made the same move in March 2024, switching Redis from the permissive BSD-3-Clause license to a dual RSALv2/SSPLv1 model, and the Linux Foundation announced the Valkey fork of the last BSD-licensed Redis release within weeks. None of SSPL, the Elastic License, or RSALv2 are OSI-approved open source licenses — they're "source-available," meaning the code is visible but usage rights are restricted, which matters enormously if your build pipeline assumes a dependency is freely redistributable.
Why Do License Types Create Real Security Risk, Not Just Legal Risk?
License types create security risk because unmanaged or misidentified licenses hide the same blind spots that let vulnerable code go undetected. Synopsys's 2024 OSSRA report found license conflicts in 53% of the 1,067 codebases it audited, and 31% contained components with no license identified at all or a custom, unreviewable license — the same opaque dependency corners where unpatched CVEs and unmaintained packages also tend to cluster. A component with an unknown license is, by definition, one your organization hasn't formally reviewed, which means neither its legal terms nor its patch history nor its provenance have gone through governance. With more than 700 license identifiers in the SPDX License List and license text embedded inconsistently across README files, LICENSE files, and package metadata, manual review doesn't scale past a few dozen dependencies — and modern applications routinely pull in hundreds to thousands of transitive packages.
How Can Security and Legal Teams Detect License Types Across a Dependency Tree?
Security and legal teams detect license types at scale by generating a Software Bill of Materials (SBOM) in SPDX or CycloneDX format and running automated license classification against every direct and transitive dependency. An SBOM captures the declared license identifier, package version, and origin for every component in a build, which turns "what license is this?" from a manual grep-through-README exercise into a queryable inventory. Mature programs pair SBOM generation with policy-as-code — flagging AGPL or SSPL-licensed packages the moment they land in a manifest, rather than discovering them during an acquisition's legal due diligence months later. Continuous ingestion matters as much as one-time generation, since a transitive dependency can change license terms in a point release, as Redis and Elastic customers learned firsthand.
How Safeguard Helps
Safeguard generates and ingests SBOMs across your full dependency graph, surfacing the declared license for every direct and transitive package alongside its vulnerability and provenance data in one inventory. Griffin AI correlates license findings with reachability analysis, so your team can see not just that an AGPL or SSPL component exists, but whether the flagged code path is actually reachable and exercised in production — cutting through noise from unused or dev-only dependencies. When a license or vulnerability issue needs remediation, Safeguard's auto-fix PRs propose the dependency swap or version bump directly in your repository, so legal and security review happens against a concrete diff instead of a spreadsheet. That combination — continuous SBOM visibility, reachability-scored risk, and automated remediation — lets teams manage license exposure with the same rigor they apply to CVEs, rather than treating it as a once-a-year compliance fire drill. Whatever you call the exercise — tracking types of open source licenses or just sorting out the different types of licenses in a dependency tree — the underlying work is the same: know what you're running before an auditor or acquirer asks.