Most developers have read the words "MIT License" at least a hundred times and couldn't explain what they actually permit or require. That's fine until the day someone in Legal asks you to audit the licenses in a product you're about to ship, or until you open-source your work and discover it's tangled up with a copyleft library.
Open-source licenses are legal contracts. They grant you rights to use, modify and redistribute code — but with conditions. Understanding those conditions matters in three situations: when you're using open-source code commercially, when you're distributing software to customers, and when you're open-sourcing your own work.
The permissive licenses (low obligation)
MIT is as permissive as it gets: you can use, copy, modify, merge, publish, distribute, sublicense, and sell the software with no restrictions beyond including the copyright notice and license text. A NOTICE file that lists the MIT dependencies you ship satisfies your obligations. MIT is compatible with everything.
BSD 2-Clause and 3-Clause are nearly identical to MIT. BSD 3-Clause adds a non-endorsement clause (you can't use the project's name to promote your product) that rarely matters in practice.
ISC License is MIT-equivalent and used heavily in the npm ecosystem (OpenSSH, many Node.js core utilities).
Apache License 2.0 is permissive but adds two significant clauses over MIT:
- Patent grant — contributors explicitly grant you a license to any patents they hold that are necessarily infringed by the code.
- Patent retaliation — if you sue anyone for patent infringement related to the software, your license terminates.
- NOTICE file requirement — you must include the NOTICE file from Apache-licensed components in your distribution.
Apache 2.0 is generally preferred over MIT for commercial use because the explicit patent grant protects you from patent claims by contributors. Apache 2.0 is not compatible with GPL 2.0 (because of the additional conditions), but is compatible with GPL 3.0.
The weak copyleft licenses (medium obligation)
LGPL (GNU Lesser General Public License) applies to libraries and requires that the LGPL library remain modifiable by the end user. In practice:
- You can use an LGPL library in a proprietary application if users can replace the LGPL component (e.g. it's dynamically linked and you provide a mechanism to swap it).
- If you statically link the LGPL library into your binary, you're effectively distributing it as part of your software and need to comply with the linking requirements.
- Modifications to the LGPL library itself must be published under LGPL.
LGPL is the license for many widely-used libraries: Qt, glibc, FFmpeg.
Mozilla Public License 2.0 (MPL-2.0) is file-level copyleft: modifications to MPL-licensed files must be shared under MPL, but you can combine them with proprietary code. It's a practical middle ground for commercial use.
Eclipse Public License (EPL) is similar to MPL but at the module level. Contributions to EPL modules must be shared, but combining with proprietary code is permitted.
The strong copyleft licenses (high obligation)
GPL 2.0 and GPL 3.0 are the "viral" licenses that commercial developers fear. Any software that incorporates GPL-licensed code and is distributed to users must be distributed under the GPL as well, with source code. If your commercial product statically links a GPL library and ships to customers, your product must also be GPL.
The critical caveat: network use is not distribution under GPL 2.0/3.0. Running GPL software on a server and making it available over a network (SaaS) does not trigger copyleft. This is the so-called "ASP loophole" that the AGPL was designed to close.
AGPL (Affero GPL) extends GPL to cover network use. If your SaaS uses an AGPL library, users accessing it over the network are considered to receive the software, and you must provide the AGPL source. Many commercial organizations have an explicit policy against using AGPL dependencies.
Practical compliance steps
Generate a NOTICE file. For every permissive dependency you ship, include the copyright notice and license text. This is a legal requirement for MIT, BSD and Apache 2.0 — not optional. DepWarden generates this automatically.
Audit before you ship. The time to discover a GPL library deep in your transitive tree is before the customer agreement is signed, not after. A dependency scan with SPDX categorisation surfaces this.
Separate concerns. Keep copyleft code in clearly separated modules, invoked via a well-defined API rather than imported directly, if you must use it at all. Dynamic linking (rather than static) gives you more flexibility with LGPL.
Track license changes. Libraries change licenses between versions. Redis went from BSD to SSPL. Elasticsearch moved from Apache 2.0 to Elastic License. A scanner that checks licenses at scan time, not just at adoption time, catches these changes.
Dual-licensed libraries. Some libraries offer both an open-source license and a commercial license. MySQL (GPL + commercial), Qt (LGPL + commercial), and many others follow this model. If you need to avoid the open-source obligations, purchasing a commercial license is the legitimate path.
The bottom line: permissive licenses (MIT, Apache 2.0, BSD) allow commercial use with attribution. Weak copyleft (LGPL, MPL) requires sharing modifications to the library but allows proprietary combination. Strong copyleft (GPL, AGPL) requires distributing your entire work under the same terms. Knowing which category each dependency falls into, before you ship, is non-negotiable for any commercial product.
Run this check on your own project with DepWarden's free open-source license compliance checker — SPDX categorisation and a generated NOTICE file, no account needed.
Top comments (0)