Open source license types fall into two broad families — permissive and copyleft — and the difference determines whether you can bundle a dependency into proprietary, closed-source software without any obligation to release your own code, or whether using it at all requires you to open-source parts of your product. Most engineers never read a LICENSE file until legal or a customer asks about it, which is exactly when the different types of licenses in a dependency tree stop being a formality and start being a real constraint on a release.
What's the difference between permissive and copyleft licenses?
Permissive licenses (MIT, Apache 2.0, BSD) let you use, modify, and redistribute the code with minimal conditions — usually just preserving the original copyright notice — including inside proprietary, closed-source products you never publish the source for. Copyleft licenses (GPL, AGPL, and their variants) require that if you distribute a modified version, or in some cases even just use the software in a certain way, you must release your own source code under the same license. The practical consequence: pulling in an MIT-licensed library is close to risk-free for a closed-source product, while pulling in a GPL-licensed library the wrong way can create a real obligation to open-source code you never intended to share.
What are the most common types of licenses engineers actually encounter?
MIT and Apache 2.0 dominate the JavaScript and Python ecosystems and are effectively "use it and don't worry" for commercial products, with Apache 2.0 additionally including an explicit patent grant that MIT doesn't. BSD (2-clause and 3-clause) behaves similarly to MIT with slightly different notice requirements. LGPL is a middle ground — it allows dynamic linking into proprietary software without triggering copyleft obligations on your own code, as long as you don't modify the LGPL-licensed library itself. Full GPL is the strongest common copyleft license — statically linking GPL code into your application generally does create an obligation to release your combined work under GPL. AGPL extends that obligation to software used over a network, even if you never distribute the binary at all, which matters specifically for SaaS products that would otherwise think they're in the clear because they never "ship" anything.
Why does this matter more for a company than for a hobby project?
Because the obligations attach to distribution and, for AGPL, to network use — exactly what a commercial product does by definition. A hobby project that never leaves someone's laptop has no distribution event to trigger copyleft terms. A SaaS company running an AGPL-licensed dependency in production, or a company shipping a binary that statically links GPL code, has created a real legal question about whether their own code now needs to be open-sourced, which is not a decision most engineering teams are equipped or authorized to make on their own.
How do you actually track license types across a real dependency tree?
Our resources blog has coverage of specific license-change incidents worth knowing about if you track this closely. Manually reading LICENSE files across hundreds of transitive dependencies isn't realistic, which is why tracking oss license types (sometimes called code license types) is typically bundled into the same SCA tooling that already scans dependencies for known vulnerabilities — both problems come from the same source (an inventory of every open-source package your build actually pulls in) and both need continuous re-checking, since a dependency's license can change between versions even if the package name stays the same. A policy that flags AGPL and GPL dependencies for legal review, while allowing MIT/Apache/BSD through automatically, is the most common pattern for keeping this from becoming a manual audit exercise.
What should a team actually do when a scan flags a copyleft dependency?
The first step is confirming how the code is actually used — statically linked into your binary, dynamically linked, or just invoked as a separate process — because the obligations differ meaningfully between those patterns, and "GPL" alone doesn't tell you which situation you're in. The second step is routing it to whoever in the organization actually owns license risk (often legal, sometimes a dedicated open-source program office at larger companies) rather than an individual engineer deciding unilaterally that it's "probably fine." Swapping a flagged dependency for a permissively-licensed alternative is often the fastest resolution when one exists, which is part of why catching this at dependency-add time, not at a pre-acquisition due diligence review two years later, matters.
FAQ
Is Apache 2.0 a copyleft license? No — Apache 2.0 is permissive. It adds an explicit patent grant that MIT and BSD don't include, which is meaningfully different for companies concerned about patent litigation risk, but it doesn't impose copyleft obligations.
Can you use a GPL-licensed library in a proprietary product at all? It depends on how it's used. Calling it as a separate, unmodified process (not linked into your binary) generally avoids copyleft obligations under most interpretations, while statically linking it into your own compiled application typically does trigger them — this is genuinely a gray area that benefits from actual legal review, not a blanket rule.
What's the risk with AGPL specifically for SaaS companies? AGPL extends copyleft obligations to network use, not just distribution, which closes the loophole SaaS companies otherwise rely on for GPL (never distributing a binary). A SaaS product using an AGPL dependency in its backend can trigger the same obligations as if it had shipped source code, even without ever releasing a binary.
Do license obligations expire or change per version? A package's license can change between major versions — some projects have re-licensed from permissive to copyleft (or the reverse) — which is exactly why license scanning needs to run continuously against the versions you actually use, not once at the start of a project.
Is there a difference between OSS license types and code license types? Not really — "OSS license types," "code license types," and "types of license" are just different phrasings for the same permissive-versus-copyleft breakdown covered above. The terminology varies by who's asking (legal teams tend to say "license types," engineers tend to say "OSS licenses"), but the underlying categories are identical.