What are software licenses? They're the legal terms that define what you're allowed to do with a piece of code — copy it, modify it, redistribute it, sell it — and every dependency in your build has one, whether anyone on the team has read it or not. The types of licenses engineers deal with day-to-day fall into three broad buckets: permissive (use it however you want, minimal obligations), copyleft (derivative works must stay under the same or a compatible license), and proprietary/commercial (usage governed entirely by a negotiated agreement, not a public standard license). Knowing which bucket a dependency falls into matters more than memorizing every license's exact text, because the obligations within each bucket are broadly similar — that's really what "software licenses explained" comes down to in practice.
Across the different types of software licenses covered below, the software licenses types that matter most for a dependency audit are the ones with real obligations attached — permissive licenses rarely cause problems, copyleft licenses sometimes do.
What are permissive licenses, and why are they the default choice for most open source?
Permissive licenses — MIT, BSD (2-clause and 3-clause), and the Apache 2.0 license — let you use, modify, and redistribute code, including inside closed-source commercial products, with minimal requirements beyond preserving copyright notices and the license text. This is why the vast majority of packages on npm and PyPI use a permissive license: it imposes the fewest constraints on downstream users, which maximizes adoption. Among the different types of licenses in this bucket, Apache 2.0 stands out for including an explicit patent grant that MIT and BSD don't address at all, which matters more than it sounds like the first time a patent dispute actually touches a dependency tree.
What is copyleft, and how strong is "strong" copyleft?
Copyleft licenses require that derivative works — code that incorporates or is built on top of the licensed code — be distributed under the same or a compatible license, which for "strong" copyleft licenses like the GPL family means your own code can be pulled into that obligation if you link against or incorporate GPL-licensed code closely enough. This is the single biggest source of legal risk in dependency trees: a company shipping a proprietary product that unknowingly bundles a strongly copyleft-licensed library may be legally obligated to release source code it never intended to open, and "unknowingly" is the operative word — this almost always happens through a transitive dependency nobody reviewed directly.
What is weak copyleft, and how is it different?
Weak copyleft licenses — LGPL, MPL 2.0, EPL — narrow the copyleft obligation to the licensed file or module itself rather than the entire combined work, so you can link a weak-copyleft library into a proprietary application and only need to release modifications to the library's own source, not your surrounding proprietary code. This distinction is exactly why "know your license type" matters more than "read every license" — the practical obligation difference between GPL and LGPL, despite one letter of difference in the name, is enormous.
What do proprietary and commercial licenses actually govern?
Proprietary licenses aren't standardized public texts at all — they're bespoke agreements (or SaaS terms of service) that define exactly what you're allowed to do, usually far more restrictively than any open source license: no redistribution, no modification, usage capped to specific seats or environments, and often an explicit prohibition on reverse engineering. The "source available" licenses that have become more common recently (Elastic License, BSL) sit in an ambiguous middle ground — visible source code, but with commercial-use restrictions that make them functionally proprietary for competing use cases even though you can read the code.
Why does license type of license matter as much as vulnerability scanning?
A dependency's license risk doesn't show up as a CVE, so teams that only scan for vulnerabilities routinely miss license exposure sitting in the same dependency tree — a transitive package with a copyleft license buried four levels deep is invisible to a vulnerability-only scan but can become a genuine legal blocker during a fundraising or acquisition due-diligence review. Software composition analysis tooling that inventories both vulnerabilities and license types in the same pass catches this before it becomes a legal fire drill rather than after, when the fix might mean re-architecting around a component that's already deeply embedded.
FAQ
What are the main types of licenses I should know as an engineer?
Permissive (MIT, BSD, Apache 2.0), weak copyleft (LGPL, MPL), strong copyleft (GPL, AGPL), and proprietary/commercial. Nearly every license you'll encounter falls into one of these four groups.
What are the 4 types of software licenses?
Permissive, weak copyleft, strong copyleft, and proprietary/commercial. Some references collapse this to three buckets by grouping weak and strong copyleft together, but the four-way split is more useful in practice because the obligations differ so much between LGPL-style and GPL-style copyleft.
Can I mix different types of license in one codebase?
Often yes, but not always — permissive licenses mix freely with almost anything, while combining copyleft-licensed code with proprietary code can create obligations you didn't intend, so check compatibility before combining, not after shipping.
Is a proprietary license the same as "no license"?
No. Code with no license at all defaults to full copyright protection with no usage rights granted to anyone — it's actually more restrictive than most proprietary licenses, which at least explicitly grant some defined usage rights.
How do I find out what license a dependency uses?
Check the package's LICENSE file or manifest metadata directly, or use an SCA tool that inventories license types automatically across your full dependency tree, including transitive dependencies you never directly installed.