Software licenses come down to three families — permissive, copyleft, and proprietary — and the family a dependency belongs to determines whether you can ship your product the way you intend. Everything else is detail. Once you can place a license into the right bucket and know that bucket's core rule, the thousands of individual license texts stop being intimidating. This guide is the map, aimed at engineers who need to make correct decisions without a lawyer on speed dial.
Why licenses matter to engineers, not just lawyers
Every open-source package you pull in grants you rights under a license, and in exchange imposes conditions. Ignore those conditions and you expose your company to legal risk that can force a rewrite, block a release, or complicate an acquisition. The uncomfortable reality is that a modern app depends on hundreds of packages, each with its own terms, and most of them arrive transitively — you never chose them directly. That is why license awareness has moved from a legal afterthought to an engineering concern.
Permissive licenses: do almost anything
Permissive licenses let you use, modify, and redistribute the code — including in closed-source commercial products — as long as you preserve attribution. The common ones:
- MIT: shortest and most popular; attribution only. Covered in depth in our MIT license guide.
- BSD (2-clause, 3-clause): similar to MIT, the 3-clause adds a no-endorsement rule.
- Apache 2.0: permissive plus an explicit patent grant and a modified-files notice. Preferred when patents are a concern.
- ISC: functionally equivalent to MIT, even shorter.
If your entire dependency tree is permissive, your obligations are light: keep the notices, ship an attribution file, done.
Copyleft licenses: share alike
Copyleft licenses use copyright to require that derivative works stay open under the same terms. This is where distribution decisions get sharp:
- GPL (v2, v3): if you distribute a derivative work, you must offer its complete source under the GPL. Linking against GPL code can pull your code into that obligation.
- LGPL: a "lesser" copyleft designed for libraries; dynamic linking generally does not force your application open, but modifications to the library itself do.
- AGPL: extends copyleft to network use. If users interact with your modified AGPL software over a network, you must offer them the source — a clause that specifically targets the SaaS loophole.
- MPL 2.0: file-level copyleft, a middle ground. Modified MPL files must stay open, but you can combine them with proprietary files.
Copyleft is not "bad" — it powers Linux and countless critical tools — but shipping copyleft code inside a proprietary product you distribute is exactly the scenario that creates legal exposure if you have not planned for it.
Proprietary and source-available licenses
Beyond open source sits a growing category of source-available licenses that let you read and sometimes modify code but restrict commercial use or hosting. Examples include the Business Source License (BSL) and the Server Side Public License (SSPL). These are decidedly not open source under the OSI definition, and treating a BSL dependency as if it were MIT can be a costly mistake. Read the terms; the freedom to view source is not the freedom to build a competing service on it.
The real problem: license risk at scale
Nobody reads hundreds of license files per release. The scalable approach is a software bill of materials (SBOM) that enumerates every component and its SPDX license identifier, combined with a policy that your CI enforces. A workable default policy:
ALLOW: MIT, BSD-2-Clause, BSD-3-Clause, Apache-2.0, ISC
REVIEW: MPL-2.0, LGPL-2.1, LGPL-3.0
BLOCK: GPL-3.0, AGPL-3.0, SSPL-1.0, UNKNOWN
An SCA tool that generates an SBOM and evaluates this policy on every build catches a disallowed license the moment it enters a lockfile, rather than during a rushed pre-acquisition audit. Standardize on SPDX expressions (like Apache-2.0 or MIT OR Apache-2.0) so the policy engine parses licenses unambiguously instead of guessing from free-text fields.
Dual licensing and exceptions
Many projects ship under a choice: MIT OR Apache-2.0 means you pick either. Others sell a commercial license alongside a GPL one, so businesses that cannot accept copyleft can pay to opt out. And some GPL projects grant exceptions — the Classpath Exception on the JDK, for instance, lets you link without triggering copyleft. When you see an "OR" or an "exception," read which path you are choosing and record it, because auditors will ask.
FAQ
What are the main types of software licenses?
Three families: permissive (MIT, Apache, BSD — attribution only), copyleft (GPL, LGPL, AGPL — derivatives must stay open), and proprietary or source-available (restrict use or hosting). The family sets the core obligation.
Can I use GPL code in a proprietary product?
Distributing a proprietary product that includes GPL-licensed code generally obligates you to release your source under the GPL. Using GPL tools internally without distribution is usually fine; distribution is the trigger.
What is the safest license for using code in a commercial app?
Permissive licenses — MIT, Apache 2.0, BSD, ISC — are the safest for commercial use. They allow closed-source distribution with only an attribution requirement.
How do I track licenses across all my dependencies?
Generate a software bill of materials that lists each component's SPDX license, and enforce an allow/review/block policy in CI. This scales far beyond reading individual license files.