Choosing the wrong open source license for your project—or ignoring licensing altogether—is one of the most common and costly mistakes developers make. A license determines what others can do with your code, whether your contributors retain rights, and whether your open source project can ever be used in proprietary products. This guide breaks down the six most important open source licenses, explains the copyleft vs. permissive divide, and gives you a framework for picking the right license in 2026.
📑 Table of Contents
⚖️ Why Open Source Licenses Matter
Without a license, your copyright defaults to "all rights reserved." That means nobody can legally use, copy, modify, or distribute your code—not even to submit bug fixes. An open source license grants specific permissions (use, modify, distribute) while attaching conditions that protect both you and your users.
The choice between licenses is fundamentally about values: how much you care about derivative works being open source, whether you want commercial use to be allowed, and what attribution requirements you're comfortable with. There's no objectively correct answer—but there are wrong answers that create legal liability or kill adoption.
📜 Anatomy of an Open Source License
Every open source license has a few standard clauses. Understanding these lets you read any license and know what you're agreeing to.
Grant of Rights
The core of any license: what rights does the licensor grant to the licensee? Typically: permission to use, copy, modify, and distribute the software. The scope of "distribute" matters—is distribution only for source code, or also for binaries?
Conditions
Every license attaches conditions to the grant of rights. Common conditions include:
- Attribution — You must include the original copyright notice and license text
- Copyleft — If you distribute derivative works, they must be released under the same license
- Source code disclosure — If you distribute binaries, you must also distribute or offer the source code
- Patent grants — Some licenses explicitly grant patents from contributors to users
- Static vs dynamic linking — Copyleft licenses differ on whether linking (especially dynamic) creates a derivative work
Limitations
Licenses typically include disclaimers of warranty ("AS IS" without warranty of any kind) and limitations of liability. These are standard and largely non-negotiable—don't expect any open source license to be liable for your lost revenue.
✅ Permissive Licenses: Maximum Freedom for Users
Permissive licenses impose the minimum conditions necessary to be considered "open source." Their goal is broad adoption and commercial use. If you want your code to spread as far as possible with minimal friction for users, start here.
MIT License
The MIT License is the most popular open source license in the world, used by projects from React to VS Code to Laravel. It's also the simplest: a single short paragraph that grants permission to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the software, provided you include the copyright notice and license text.
Extremely short and readable, widely understood by legal teams, allows proprietary use, commercial use, and sublicensing, minimal compliance burden
No patent grant (contributors don't explicitly grant patents to users), doesn't address trademark rights, no explicit source code disclosure requirement
BSD 3-Clause License
The BSD 3-Clause License (often just "BSD") is similar to MIT but with two important additions: a non-endorsement clause (forbidding use of the project's name to promote derived products without written permission) and an explicit prohibition on using contributor names for promotional purposes. The BSD 2-Clause variant drops the non-endorsement clause and is effectively identical to MIT.
Allows proprietary use, includes non-endorsement protection, well-understood, clear about what you can and cannot do with project names
No patent grant, somewhat longer than MIT (still very short), same limitations on source code disclosure as MIT
Apache License 2.0
The Apache License 2.0 is the most comprehensive of the permissive licenses. It includes everything in MIT and BSD plus explicit patent grants from contributors to users, explicit trademark provisions (clarifying that trademarks are not licensed), and requirements for maintaining attribution notices and NOTICE files (if the project distributes modified files with additional attributions).
Explicit patent grant protects users from patent trolls, covers trademarks, explicit about NOTICE file requirements, approved by the Open Source Initiative (OSI)
Longer and more complex than MIT/BSD, still permissive so doesn't require derivative works to stay open source, NOTICE file requirements add slight compliance overhead
🔒 Copyleft Licenses: Derivatives Must Stay Open
Copyleft (a play on "copyright") is the principle that if you distribute derivative works of a piece of software, you must release them under the same license. It's a deliberate mechanism to ensure that open source remains open. Think of it as a "viral" license—the openness spreads to derivative works.
GNU GPL v3 (and v2)
The GNU General Public License, created by Richard Stallman and the Free Software Foundation, is the original copyleft license. GPLv3 (released in 2007) added explicit patent provisions, anti-tivoization clauses (preventing "tivoization" where hardware locks prevent software modification), and compatibility with Apache 2.0. GPLv2 (1991) remains widely used but lacks these protections.
Strongest copyleft protection, ensures derivative works remain open, explicit patent provisions in v3, huge ecosystem of GPL'd software, well-litigated (legal precedent exists)
Viral: any code that links to (or in v2, incorporates) GPL code may need to be released as GPL, can conflict with proprietary software, interpreted differently on dynamic vs static linking, some corporate legal teams are wary of it
GNU LGPL v3
The Lesser General Public License is a "weaker" copyleft license specifically designed for libraries. Under LGPL, you can link to an LGPL library from proprietary software without needing to release your proprietary software as LGPL—provided you do dynamic (not static) linking and follow specific requirements for making the LGPL library's source available.
Allows proprietary software to use LGPL-licensed libraries, easier adoption for commercial projects, good choice for libraries that you want to be widely used while keeping some copyleft protection
Dynamic vs static linking distinction is a compliance minefield, legal interpretation of "linking" varies by jurisdiction, compliance is more complex than permissive licenses
Mozilla Public License 2.0 (MPL)
The MPL occupies a middle ground between permissive and strong copyleft licenses. It uses a "file-level" copyleft instead of a "link-level" copyleft: if you modify an MPL-licensed file, those modifications must be released under MPL. But you can combine MPL code with proprietary code without affecting the proprietary code's license.
File-level copyleft is less viral than GPL, good for mixed open/proprietary projects, explicit patent provisions, well-balanced between openness and commercial usability
Less understood by developers outside the Mozilla ecosystem, compliance is more complex than MIT/BSD, smaller community than GPL
📊 The Big Comparison Table
| License | Type | Patent Grant | Trademark | Proprietary Use | Requires Derivative Source | Complexity |
|---|---|---|---|---|---|---|
| MIT | Permissive | ❌ | ❌ | ✅ | ❌ | Very Low |
| BSD 3-Clause | Permissive | ❌ | ✅ Non-endorsement | ✅ | ❌ | Low |
| Apache 2.0 | Permissive | ✅ | ✅ Explicit | ✅ | ❌ | Medium |
| GPL v3 | Strong Copyleft | ✅ | ❌ | ✅ | ✅ (link-level) | High |
| LGPL v3 | Weak Copyleft | ✅ | ❌ | ✅ | ⚠️ Dynamic linking only | High |
| MPL 2.0 | Medium Copyleft | ✅ | ❌ | ✅ | ⚠️ File-level only | Medium |
🎯 How to Choose the Right License
The license you choose depends on your goals. Here are the most common scenarios and the conventional choices.
"I want maximum adoption. I don't care how others use my code."
Use MIT. It's the path of least resistance. Contributors can take your code and do anything with it, including building proprietary products. This is why React, jQuery, and Ruby on Rails all use MIT—broad adoption is the explicit goal.
"I want my code to remain open and I don't want companies to take it proprietary."
Use GPL v3. The strong copyleft ensures that any derivative work that gets distributed must also be open source. If someone takes your GPL code and builds a product on top of it, they must release their modifications.
"I'm building a library that should be free to use in any project."
Use LGPL v3 or MPL 2.0. LGPL explicitly permits dynamic linking from proprietary software. MPL's file-level copyleft is also designed for this scenario. Libraries like zlib, most Linux kernel modules, and many system utilities use LGPL.
"I want patent protection for users and trademark clarity."
Use Apache 2.0. The explicit patent grant protects users from contributors who might otherwise sue over patent claims. This is why many Apache Foundation projects (Kafka, Spark, Hadoop) and large open infrastructure projects use it.
If you're contributing to someone else's open source project (a pull request), check the LICENSE file before submitting. Your contribution will be licensed under the project's license. If you're uncomfortable with the license—for example, you don't want your code potentially appearing in proprietary products—discuss it with the maintainers before contributing.
🔧 Practical Decisions for 2026
Should You Add a Contributor License Agreement (CLA)?
Some projects (notably, Google and Facebook's open source projects) require contributors to sign a CLA that grants additional rights beyond the project's license—typically an explicit patent license or a broader copyright grant. The CLA gives the project maintainers more flexibility in how they can use contributions (for example, changing the license in the future).
CLAs add friction to contributions and have become somewhat controversial. Projects like Node.js and Rust have moved away from CLAs toward a "Developer Certificate of Origin" (DCO), which is a lightweight sign-off that the contributor has the right to contribute the code.
Dual Licensing
Some projects use dual licensing—offering both an open source license (like GPL) and a commercial/proprietary license for companies that want to use the software without copyleft obligations. MySQL is the canonical example: GPL for open source users, a paid commercial license for proprietary use. If you need to commercialize your open source project, dual licensing is a viable model—but it adds significant complexity.
Creative Commons for Documentation
Code isn't the only thing that needs licensing. Documentation, guides, and educational content are typically licensed under Creative Commons (CC). The most common open source documentation licenses are CC BY (attribution required, derivatives allowed) and CC BY-SA (attribution + share-alike, the Creative Commons equivalent of copyleft). Wikipedia uses CC BY-SA, which is why content scraped from Wikipedia without attribution and released under a proprietary license is a licensing violation.
🏁 Quick Reference
License Decision Tree
New open source project, want maximum adoption → MIT License. Simple, permissive, no friction for contributors or users.
Building a library that should be free in closed-source products → LGPL v3. Designed precisely for this use case.
Want strong copyleft to prevent proprietary exploitation → GPL v3. The strongest copyleft license in common use.
Want permissive but need explicit patent protection → Apache 2.0. Comprehensive rights grant with patent coverage.
Want copyleft for your contributions but allow proprietary use of your library → MPL 2.0. File-level copyleft is the most practical middle ground.
Not sure → Start with MIT. You can always add restrictions later. It's much harder to remove restrictions once a project has a community built around a permissive license.
Licensing isn't exciting, but getting it right from day one prevents painful conversations later. Put a LICENSE file in your repository before you push your first commit. If you're taking on contributors, add a CONTRIBUTING.md that references the license and explains the contribution process. These two files are the foundation of a healthy open source project.
Affiliate Disclosure: This article is for informational purposes only and does not constitute legal advice. For specific legal questions about open source licensing, consult a qualified attorney.