Open source licensing models fall into three broad families, permissive, copyleft, and source-available, and the family a dependency belongs to determines what you are legally obligated to do when you ship it. Getting this wrong is not a theoretical concern: a single strong-copyleft library buried deep in your dependency tree can create an obligation to release your own source, and a source-available license can quietly prohibit the exact use you are building. Understanding open source licensing at the model level, rather than memorizing individual licenses, is the fastest way to stay compliant.
The three families
Permissive licenses (MIT, Apache 2.0, BSD, ISC) let you do almost anything, including using the code in closed-source commercial products, as long as you preserve the copyright notice and license text. Apache 2.0 adds an explicit patent grant, which is why many enterprises prefer it over MIT for anything patent-sensitive. These are the low-friction options and the reason MIT and Apache dominate the modern ecosystem.
Copyleft licenses require that derivative works be distributed under the same license. This family splits into two:
- Weak copyleft (LGPL, MPL 2.0, EPL) applies the share-alike obligation at the file or library boundary. You can typically link to an LGPL library from proprietary code without opening your own source, provided you allow the library itself to be replaced.
- Strong copyleft (GPL v2, GPL v3) extends the obligation to the entire work that incorporates the code. If you distribute software that links GPL code, you may be required to license the whole combined work under the GPL and provide corresponding source.
- Network copyleft (AGPL v3) closes the "SaaS loophole" by treating providing the software over a network as distribution, triggering source-disclosure obligations even if you never ship a binary. This is the license most likely to surprise a company that thought "we only run it as a service" made copyleft irrelevant.
Source-available and non-open licenses (BSL/Business Source License, SSPL, Elastic License, Commons Clause) are not OSI-approved open source at all, even though the code is public. They typically restrict competitive or commercial use, or convert to open source only after a delay. Treat these as commercial terms, because that is effectively what they are.
Why the "open source licensing war" happened
The rise of source-available licenses is the heart of what people call the open source licensing war. Companies that built widely used infrastructure watched cloud providers monetize their software as managed services while contributing relatively little back. In response, projects such as those behind well-known databases and search engines relicensed from permissive or weak-copyleft terms to SSPL, BSL, or similar source-available terms.
The practical fallout for you is that a dependency you adopted years ago under Apache 2.0 may have relicensed a later version under terms that forbid your use case. License is not a static attribute of a package; it can change between versions. That is why pinning and monitoring matter as much for licenses as for vulnerabilities.
The obligations that actually trip teams up
A few recurring failure modes account for most license incidents:
- Transitive copyleft. You audited your direct dependencies but a GPL or AGPL library came in three levels down. The obligation attaches regardless of how it entered your tree.
- Attribution debt. Permissive licenses are easy, but they still require preserving notices. Shipping a binary or a container without the required attribution file is a real violation, just a low-drama one.
- License changes on upgrade. Bumping a dependency to a new major version silently accepts new terms. A version that flips to BSL can turn a routine upgrade into a licensing problem.
- Incompatible combinations. Some licenses cannot legally coexist in one distributed work. GPL v2-only and Apache 2.0, for example, have well-documented friction.
Managing it in practice
License compliance is a data problem before it is a legal one. You cannot evaluate obligations you cannot see, so start by generating a complete software bill of materials (SBOM) that records the license of every component, including transitive ones. From there:
- Define a policy that classifies licenses into allow, review, and deny buckets. Most teams allow MIT/Apache/BSD, route weak copyleft to review, and deny AGPL and unknown/source-available terms by default.
- Enforce the policy in CI so a new dependency in a deny bucket fails the build before it merges, not after it ships.
- Re-check on every upgrade, because license terms change with versions.
An SCA tool can attach a license to each component in the SBOM and evaluate it against your policy automatically, which is the only realistic way to catch a transitive AGPL dependency in a tree of thousands of packages. Manual review does not scale past a trivial project.
For the compliance side of this, our academy covers how license obligations map to audit requirements and what evidence auditors expect to see.
A workable default policy
If you need somewhere to start, a defensible baseline is: permit permissive licenses, allow weak copyleft after a documented review of how you link to it, prohibit strong and network copyleft in anything you distribute or offer as a service, and treat every source-available license as requiring a commercial-terms decision. Write it down, enforce it in the pipeline, and revisit the deny list when your product's distribution model changes.
FAQ
What are the main open source licensing models?
Three families: permissive (MIT, Apache, BSD), copyleft (LGPL, GPL, AGPL), and source-available/non-open (BSL, SSPL, Elastic License). Permissive is lowest friction; copyleft carries share-alike obligations; source-available restricts commercial use.
Does using GPL code force me to open source my application?
If you distribute software that incorporates strong-copyleft (GPL) code, you may be required to license the combined work under the GPL and provide source. AGPL extends this to software offered over a network, even without distributing a binary.
Is source-available the same as open source?
No. Source-available licenses like BSL and SSPL make the code visible but restrict use, often prohibiting competitive or commercial deployment. They are not OSI-approved open source and should be treated as commercial terms.
Can a dependency's license change between versions?
Yes. Projects can and do relicense, sometimes moving from permissive to source-available terms in a new version. Upgrading accepts the new license, so re-check license terms on every dependency bump.