Every time I create a public project on GitHub, while trying to provide the most complete and professional description of my code possible, I end up facing the choice of which license file to put there, in plain sight, before ignoring it forever. Given my limited experience with the topic and my general lack of interest in legal matters, especially when they involve something that, in my view, should first and foremost be a way to share what might improve, even imperceptibly, your own experience and that of others, I have always relied on the most popular licenses without digging too deep. As a result, most of my GitHub projects are released under the MIT license. However, as I increasingly deal with proprietary software, where obtaining a license is an extremely long, cumbersome, boring, and expensive process, and as I also need to publish code that depends on libraries with stricter licenses, I decided to look into this topic a bit more to better understand how this necessary evil works.
The main sources for this post, for anyone who wants to dive deeper, are Choose a License and the article You Clicked “Add a License” on GitHub…But Do You Know What You Picked?.
What is a software license for?
In short, a software license is a legal document that clearly states the terms under which software can be used. It becomes even more important when source code is public, because the license also clarifies:
- What you are allowed to do with the code,
- What you are not allowed to do with the code,
- Any limitations or conditions you must follow when using, modifying, or distributing the software.
The most popular licenses
Most open-source projects on GitHub use one of these licenses, with minor variations.
No license = no permission
You can look, but you cannot touch.
If a GitHub project has no license, legally no one has permission to use, modify, or distribute that code. In practice, it is as if the code were “all rights reserved”, and anyone who wants to use, modify, or share it would first need explicit permission from the author. This can discourage people from contributing to or using the project, assuming they are aware of the rules in the first place.
MIT License
You can do whatever you want at your own risk, as long as you credit me.
Under the MIT license, anyone can use, modify, and distribute the code, including for commercial purposes, as long as they include a copy of the license and credit the original author. It is one of the most permissive and popular licenses, ideal for projects that want to maximize adoption and distribution.
Best for
- Personal projects
- Academic projects
- Fully open-source libraries
Apache License 2.0
You can do what you want, but if you use my code, you must credit me and I am protected from potential patent-related lawsuits.
Very similar to MIT, but with additional clauses that protect the author from patent-related claims. It is a good choice for projects that want a permissive license with stronger legal protection, especially in business contexts.
Best for
- Commercial projects
- Frameworks
- Long-term open-source projects
Used by
- Android
- Kubernetes
- Progetti Apache
- Apache projects
GPL (GNU General Public License)
You can use my code, but if you modify or distribute it, you must release your code under the same license.
This is a copyleft license, which requires any software derived from the original code to be released under the same GPL license. It behaves somewhat like a “virus” that spreads to any project using code covered by this license. It is a popular choice for projects that want to ensure their code always remains open-source, but it can be restrictive for those who want to use the code in proprietary projects or projects with more permissive licenses. In practice, it prevents GPL code from being included in projects that do not want to release their own code under GPL.
Best for
- Educational projects
- Community-driven software
- Projects intended to stay open-source forever
LGPL (Lesser GPL)
You can use my library, but if you modify the library itself, you must release those changes under the same license.
LGPL is a more permissive version of GPL that allows the library to be used in proprietary projects, as long as modifications to the library itself are released under the same license.
Best for
- Libraries
- SDKs
BSD License
Similar to MIT, but more formal.
BSD is a permissive license that allows use, modification, and distribution of code, with some minor restrictions compared to MIT. It was one of the first open-source licenses and, although it is less common today, it is still respected and used in some academic and research projects.
Best for
- Academic projects
- Research software
Summary table
| License | Commercial use? | Attribution? | Copyleft? | Best for |
|---|---|---|---|---|
| MIT | ✓ | ✓ | X | Personal and academic projects, open-source libraries |
| Apache 2.0 | ✓ | ✓ | X | Commercial projects, frameworks |
| GPL | ✓ | ✓ | ✓ | Projects meant to remain open-source |
| LGPL | ✓ | ✓ | ⚠ (for the library) | Libraries, SDKs |
| BSD | ✓ | ✓ | X | Academic projects, research software |
Some well-known projects
- Apache requires Apache License 2.0
- Cloud Native Computing Foundation requires Apache License 2.0
- GNU recommends GNU GPLv3
- npm packages often use MIT or ISC, which is very similar
- OpenBSD tends to prefer ISC
- Rust crates are often under MIT or Apache License 2.0
- WordPress plugins and themes must be released under GNU GPLv2 or later.
- Joomla extensions and templates must be released under GNU GPLv2 for PHP code.