Why Licenses Matter in Open Source
Every open source project carries a license, and that license determines what anyone — including you — can legally do with the code. Using a project without understanding its license can create legal exposure, especially in commercial contexts. This guide demystifies the most widely-used open source licenses so you can make informed decisions.
The Permissive License Family
Permissive licenses place minimal restrictions on how you use, modify, and redistribute software. They are generally business-friendly.
MIT License
The MIT License is one of the most popular licenses in the open source ecosystem. It allows you to:
- Use the code commercially
- Modify and distribute it
- Include it in proprietary software
The only requirement is that the original copyright notice and license text are included in any distribution. React, Rails, and jQuery all use the MIT License.
Apache License 2.0
Similar to MIT in permissiveness, the Apache 2.0 License adds explicit patent grants. This means contributors grant users rights to any patents that cover the code, providing additional legal protection. It also requires a NOTICE file to be maintained. Kubernetes, TensorFlow, and Android use Apache 2.0.
BSD Licenses (2-Clause and 3-Clause)
BSD licenses are also permissive, with the 3-Clause version adding a non-endorsement clause — you cannot use the project's name to promote your derivative works without permission.
The Copyleft License Family
Copyleft licenses require that derivative works be released under the same (or compatible) license. They ensure that software — and improvements to it — remain open.
GNU General Public License (GPL v2 and v3)
The GPL is the strongest copyleft license. If you distribute software that incorporates GPL-licensed code, you must:
- Release your source code under the GPL
- Include the original license and copyright notices
GPL v3 adds protections against hardware restrictions (tivoization) and software patents. Linux kernel uses GPLv2; GCC uses GPLv3.
GNU Lesser General Public License (LGPL)
The LGPL is a weaker form of copyleft designed for libraries. It allows proprietary applications to link to LGPL libraries without being required to open their source, but modifications to the LGPL library itself must remain open.
Mozilla Public License 2.0 (MPL)
A file-level copyleft license. MPL-licensed files must remain open, but you can combine them with proprietary code in the same project as long as the MPL files stay separate and open.
Quick Comparison
| License | Commercial Use | Can Close Source | Patent Grant |
|---|---|---|---|
| MIT | Yes | Yes | No |
| Apache 2.0 | Yes | Yes | Yes |
| GPL v3 | Yes | No | Yes |
| LGPL | Yes | Partial | Yes |
| MPL 2.0 | Yes | Partial | Yes |
Which License Should You Use?
A few practical rules of thumb:
- Maximum adoption: Use MIT or Apache 2.0. Developers and companies are most comfortable with these.
- Protect against proprietary forks: Use GPL v3. Nobody can take your work and close it.
- Library that businesses will adopt: Consider LGPL or MPL 2.0.
When in doubt, choosealicense.com (a GitHub initiative) offers a clear, plain-language guide to help you choose.
A Note on "Source Available" Licenses
In recent years, some companies have adopted licenses like BUSL or SSPL that look open source but include commercial restrictions. These are not considered open source by the Open Source Initiative (OSI). Always check whether a license is OSI-approved if true open source compliance matters to you.