Most developers interact with open source licenses the way most people interact with terms of service: they scroll past them. This works fine until it does not — until your company’s legal team asks what licenses are in your dependency tree, until a GPL library shows up in your proprietary SaaS, or until you need to choose a license for your own project and realize you do not understand the differences.
Licensing is not optional. Every piece of open source software you use comes with legal terms that affect what you can do with your code. Understanding these terms is not about becoming a lawyer; it is about making informed decisions that will not create problems six months from now.
The Core Concepts You Need
Before comparing specific licenses, you need to understand two fundamental concepts that determine how a license affects your work.
Permissive vs. Copyleft
Permissive licenses (MIT, Apache 2.0, BSD) say: “Do whatever you want with this code, just keep the copyright notice.” You can use permissive-licensed code in proprietary software, modify it, redistribute it, sell products built on it. The only obligation is attribution — usually keeping the license file in your distribution.
Copyleft licenses (GPL, AGPL, LGPL, MPL) say: “If you distribute software that includes or is derived from this code, the distributed software must also be available under the same license.” The intent is to ensure that improvements to open source software remain open source. The practical implication is that copyleft code can “infect” your proprietary codebase if you are not careful about boundaries.
Distribution Triggers
Most license obligations are triggered by distribution — giving the software to someone else. Running GPL-licensed code on your own server is generally fine, even for proprietary purposes, because you are not distributing it. The AGPL specifically closes this “loophole” by extending the distribution trigger to network interaction: if users interact with AGPL software over a network, they have the right to the source code.
This distinction matters enormously for SaaS companies. A SaaS product can use GPL libraries internally without open-sourcing anything, because the software is never distributed — users interact with it over HTTP. But AGPL changes this equation entirely.
The Major Licenses, Practically Explained
MIT License
The MIT License is the most popular open source license, and for good reason: it is short (about 170 words), easy to understand, and maximally permissive. You can do essentially anything with MIT-licensed code as long as you include the copyright notice and license text.
When to use it: When you want maximum adoption and do not care if someone uses your code in a proprietary product. Most JavaScript/TypeScript libraries, many Rust crates, and a significant portion of the Python ecosystem use MIT.
What to watch for: MIT provides no patent protection. If the code implements a patented algorithm, the copyright license does not grant you a patent license. In practice, this rarely matters for small projects, but it is a real concern for enterprise adoption of code that touches patented territory.
Apache License 2.0
Apache 2.0 is similar to MIT in permissiveness but adds two important provisions: an explicit patent grant and a contribution agreement. When someone releases code under Apache 2.0, they are granting you a license to any patents they hold that are necessarily infringed by the code. This patent protection is why many companies and foundations prefer Apache 2.0 over MIT.
The contribution clause means that anyone who contributes to an Apache 2.0 project automatically grants the same patent license for their contributions. This creates a clean intellectual property chain that legal teams appreciate.
When to use it: When you want permissive licensing with patent protection. Kubernetes, TensorFlow, and most Apache Foundation projects use this. If your project might be adopted by enterprises with patent-sensitive legal teams, Apache 2.0 removes a potential objection.
What to watch for: Apache 2.0 is incompatible with GPLv2 (but compatible with GPLv3). If you need to combine your code with GPLv2-only libraries, Apache 2.0 creates a conflict. This is a niche issue but worth knowing about.
GPL (v2 and v3)
The GNU General Public License is the original copyleft license and the most philosophically opinionated. Its central principle: if you distribute software that includes GPL code, the entire combined work must be distributed under GPL with source code available.
GPLv2 is the older version, used by Linux, Git, and many foundational projects. It requires source availability for distributed binaries but has a narrower definition of what constitutes a “derived work.”
GPLv3 adds protections against Tivoization (using hardware restrictions to prevent users from running modified software) and has clearer patent language. It is more restrictive in some ways but more compatible with Apache 2.0.
The SaaS loophole: GPL obligations trigger on distribution. If you run GPL software as a service and users only interact with it over a network, you are not distributing the software. Many SaaS companies use GPL libraries internally for this reason.
When to use it: When you want to ensure that derivative works remain open source. If you believe your software is valuable enough that companies would build proprietary products on it, GPL ensures they contribute back.
What to watch for: GPL’s copyleft requirement is the most common source of license compliance issues. If any dependency in your proprietary application is GPL (not LGPL, not a system library exception), you have a potential problem. Audit your dependency tree.
AGPL (Affero General Public License)
AGPL is GPL with one critical addition: if users interact with the software over a network, that counts as distribution. This closes the SaaS loophole. If you modify AGPL software and serve it to users over HTTP, you must make the source code of your modified version available.
When to use it: When you want to prevent SaaS companies from using your software without contributing back. MongoDB’s original license was AGPL (before they switched to SSPL). Many developer tools use AGPL to ensure cloud providers cannot offer managed versions without open-sourcing their modifications.
What to watch for: AGPL is the license that makes corporate legal teams most nervous. Many companies have blanket policies prohibiting AGPL dependencies. If you license your project under AGPL, you will limit enterprise adoption — which may or may not be your intent.
LGPL (Lesser General Public License)
LGPL is a compromise between GPL and permissive licenses. It allows proprietary software to link against LGPL libraries without the copyleft requirement spreading to the proprietary code. The obligation is limited: if you modify the LGPL library itself, those modifications must be shared. But your application code that merely uses the library remains your own.
When to use it: When you want your library to be usable in proprietary software but want modifications to the library itself to remain open. Many C/C++ libraries use LGPL (glibc, Qt’s open source edition).
MPL 2.0 (Mozilla Public License)
MPL 2.0 is a file-level copyleft license. Modifications to MPL-licensed files must be shared under MPL, but you can combine MPL files with proprietary files in the same project without the copyleft requirement spreading. This makes it a pragmatic middle ground — stricter than MIT/Apache on modifications but far less restrictive than GPL on combined works.
When to use it: When you want modifications to your code shared back but do not want to prevent proprietary use. Firefox, Terraform (before the BUSL switch), and HashiCorp’s earlier tools used MPL.
The New Licenses: BUSL, SSPL, and the Source-Available Movement
The last few years have seen a wave of projects moving from traditional open source licenses to “source-available” licenses that restrict specific commercial uses. These are not open source by the OSI definition, but the source code is publicly available.
Business Source License (BUSL): Allows most use but restricts specific commercial activities (typically offering the software as a managed service). After a set period (usually 3-4 years), the code converts to a permissive open source license. Used by MariaDB, HashiCorp (Terraform, Vault), and Sentry.
Server Side Public License (SSPL): MongoDB’s license that requires anyone offering the software as a service to open-source their entire service stack. Deliberately designed to be too restrictive for cloud providers to comply with.
These licenses are a response to the “open source sustainability” problem: companies building billion-dollar businesses on open source software without contributing back. Whether they are the right response is a matter of genuine debate in the community.
For developers consuming these tools: treat BUSL and SSPL as proprietary for practical purposes. Check the specific restrictions carefully before building dependencies on them. For developers choosing a license: understand that these licenses reduce adoption and community contribution in exchange for commercial protection.
Practical Decision Framework
When choosing a license for your project, ask these questions in order:
- Do you care if someone uses your code in a proprietary product? No: use MIT or Apache 2.0. Yes: continue to question 2.
- Do you care specifically about SaaS use? No: use GPL. Yes: use AGPL.
- Do you need patent protection? Yes: prefer Apache 2.0 over MIT. This matters more as your project grows and attracts corporate users.
- Are you building a library or an application? Libraries generally benefit from permissive licenses (wider adoption). Applications can afford copyleft licenses because they are end products, not dependencies.
For most developers shipping side projects, libraries, or tools: MIT or Apache 2.0. MIT if simplicity matters. Apache 2.0 if patent protection matters. The vast majority of open source software uses one of these two, and for good reason.
Auditing Your Dependencies
Knowing your own license is half the picture. You also need to know what licenses exist in your dependency tree. A single GPL dependency in a proprietary application is a compliance issue, and transitive dependencies are where surprises hide.
Tools that help:
- license-checker (npm): Scans your node_modules and reports every license.
- pip-licenses (Python): Same for pip packages.
- cargo-license (Rust): Lists licenses for all crate dependencies.
- FOSSA / Snyk: Commercial tools that provide continuous license monitoring and compliance reporting.
Run a license audit before your first production release, and add it to your CI pipeline so you catch new license introductions as they enter your dependency tree. A five-minute CI check is cheaper than a legal review after the fact.
Key Takeaways
- Permissive licenses (MIT, Apache 2.0) let you do almost anything with attribution. Copyleft licenses (GPL, AGPL) require derivative works to carry the same license.
- GPL obligations trigger on distribution, not use. Running GPL software on your servers for SaaS is generally fine — but AGPL closes this gap by treating network interaction as distribution.
- Apache 2.0 over MIT when patent protection matters. MIT when simplicity is your priority. For most side projects and libraries, either works well.
- BUSL and SSPL are source-available, not open source. Treat them as proprietary when evaluating dependencies.
- Audit your dependency tree with automated tools (license-checker, pip-licenses) and add license checks to CI. Transitive dependencies are where licensing surprises hide.