I am sure you are all aware that open source also has a license. I knew that, but I always managed my GitHub repositories under the MIT License for some reason.
I knew that I should be aware of the differences in the characteristics of each license before using them, but I have been using MIT only because it is easy to use.
So today, I took another look at the major open source licenses.
Open source licenses Overview
Open source licenses are a fundamental aspect of the open source software ecosystem. There are various types of open source licenses, each with its own set of terms and conditions regarding how the software can be used, modified, and distributed. Some of the most common open source licenses include the GNU General Public License (GPL), MIT License, Apache License, BSD Licenses, and many others.
Open source licenses are an essential part of the open source software ecosystem, as they define the terms under which the software can be used, modified, and distributed. They play a crucial role in promoting collaboration, ensuring proper attribution, and protecting the rights of both developers and users.
Open source license on GitHub
The license picker is only available when you create a new project on GitHub.
You can choose from the following licenses:
- Apache license 2.0 (Apache-2.0)
- GNU General Public License v3.0 (GPL-3/0)
- MIT License (MIT)
- BSD 2-clause "Simplified" license (BSD-2-Clause)
- BSD 3-clause "New" or "Revised" license (BSD-3-Clause)
- Boost Software License 1.0 (BSL-1.0)
- Creative Commons Zero v1.0 Universal (CC0-1.0)
- Eclipse Public License 2.0 (EPL-2.0)
- GNU Affero General Public License v3.0 (AGPL-3.0)
- GNU General Public License v2.0 (GNU-2.0)
- GNU Lesser General Public License v2.1 (LGPL-2.1)
- Mozilla Public License 2.0 (MPL-2.0)
- The Unlicense (Unlicense)
MIT and BSD (2/3-Clause): Permissive licenses that allow very liberal use, modification, distribution with minimal restrictions. Great for maximizing adoption.
Apache 2.0: Also a permissive license, but has a patent grant clause and restricts trademark use. Popular for libraries/tools.
GPL (v2/v3): Copyleft/protective licenses that require derivative works to be distributed under the same license terms. Used to keep code free/open.
LGPL: Similar copyleft spirit as GPL but designed for code libraries to allow linking with non-GPL software.
AGPL: Like GPL but also applies copyleft to network/cloud services to prevent SaaSing of the code.
MPL 2.0: Copyleft but allows mixing with proprietary code and static linking. Used by Mozilla projects.
EPL: Another weak copyleft license used by Eclipse projects allowing mixing with proprietary code.
Characteristics of each open source license
Apache License 2.0
- Permissive license that allows users to use, modify, distribute, and sublicense the software.
- Requires preservation of copyright notice, license, and disclaimer.
- Provides an express grant of patent rights from contributors.
- Contains a limitation of liability clause.
- Compatible with GPL version 3, but not GPL version 2.
GNU General Public License v3.0
- Copyleft license that requires derivative works to be licensed under the GPL and mandates sharing source code for derivative works under the same license.
- Requires preservation of copyright notice, license, and disclaimer.
- Provides explicit permissions for conveying modified works.
MIT License
- Permissive license that allows users to use, modify, distribute, and sublicense the software for any purpose.
- Requires preservation of copyright notice and disclaimer.
- Contains a limitation of liability clause.
- Very simple and permissive, widely used for both commercial and non-commercial projects.
BSD 2-clause "Simplified" license
- Permissive license similar to the MIT License but with slightly different wording.
- Allows users to use, modify, and distribute the software with minimal restrictions.
- Requires preservation of copyright notice and disclaimer.
BSD 3-clause "New" or "Revised" license
- Permissive license similar to the BSD 2-clause license but with an additional clause prohibiting the use of the name of the contributors for endorsement of derived products.
Boost Software License 1.0
- Permissive license similar to the BSD and MIT licenses but with additional requirements related to attribution, disclaimers, and redistribution.
- Allows users to use, modify, distribute, and sublicense the software with minimal restrictions.
Creative Commons Zero v1.0 Universal
- Public domain dedication that allows for the unrestricted use, modification, and distribution of the software without any restrictions.
- Users are not required to provide attribution or maintain any copyright notices.
Eclipse Public License 2.0
- Copyleft license similar to the GPL but with additional provisions for patent grants and compatibility with other licenses.
- Requires preservation of copyright notice, license, and disclaimer.
- Contains a limitation of liability clause.
GNU Affero General Public License v3.0
- Copyleft license similar to the GPL but specifically designed for software distributed over a network.
- Requires the source code to be made available to users interacting with the software over a network.
- Contains provisions for additional permissions regarding linking and exceptions for certain types of software.
GNU General Public License v2.0
- Similar to the GPL version 3 but with some differences in terms of patent protection and compatibility with other licenses.
- Requires preservation of copyright notice, license, and disclaimer.
- Provides an express grant of patent rights from contributors.
GNU Lesser General Public License v2.1
- Similar to the GPL but with fewer restrictions on linking with non-GPL code.
- Allows for the use of the software in both proprietary and open source projects.
- Contains provisions for library code and allows for dynamic linking with non-GPL code.
Mozilla Public License 2.0
- Permissive license with some copyleft provisions.
- Allows for modification, distribution, and use of the software under certain conditions, including sharing source code for derivative works.
- Requires preservation of copyright notice, license, and disclaimer.
The Unlicense
- Public domain dedication that allows for the unrestricted use, modification, and distribution of the software without any restrictions or requirements for attribution.
- Essentially relinquishes all copyright and related rights.
Guidelines to select open source license
1. Understand your goals
- Do you want to maximize adoption and permissiveness? Go with a permissive license like MIT, BSD, or Apache.
- Do you want to ensure derivatives remain open source and share alike? Go with a copyleft license like GPL.
- Do you need to allow links to closed-source code? Consider LGPL.
2. Look at similar projects
- See what license other popular projects in your domain are using. Consistency reduces friction.
- For libraries, permissive Apache is very common. For apps, GPL-type licenses are more prevalent.
3. Commercial interests
- If commercial use and monetization is a goal, avoid copyleft and go permissive (MIT, Apache).
- If commercial use is not a priority, copyleft (GPL) ensures freedoms are protected.
4. Patent clause
- Apache has an explicit patent grant clause which may be beneficial for patent-heavy fields.
5. Community norms
- Some communities have strong preferences (e.g. GNU core utils tend to use GPLv3).
- Follow those norms unless you have a specific reasons to diverge.
6. Future-proofing
- Newer licenses like Apache 2.0 were designed for modern use cases like patent termination.
- Older licenses like BSD may be more ambiguous for edge cases.
7. Subsidiary projects
- For multiple linked projects, use a permissive license on libraries and tools.
- And a copyleft license on the main application, if desired.
Key Takeaways
MIT, which I now use, is said to be suitable for the following situations:
- Maximizing Adoption: If your primary goal is to have your software used as widely as possible, with minimal restrictions, then the MIT license is an excellent option. Its extremely permissive nature allows unrestricted use, modification, and distribution, even for commercial purposes. This makes it appealing to both individuals and companies looking to build upon your work.
- Libraries and Utilities: The MIT license works very well for libraries, utilities, or other code that is meant to be integrated into other software projects. Since it permits combining MIT-licensed code with other licenses (including proprietary), it avoids licensing conflicts.
- Open Source, not Copyleft: If you want to release your code as open source but are not particularly concerned about enforcing a share-alike component (i.e. copyleft), then MIT's permissive nature is a good fit. Developers can use your code in closed-source/proprietary applications without any obligations.
- Academic or Research Projects: For academic or research-oriented projects where dissemination and unrestricted use is important, MIT provides that freedom without obligations.
- No Warranty/Liability Concerns: The MIT explicitly states no warranties and clears you of liability, which is beneficial if that's a concern.
- Personal/Hobby Projects: For personal projects or code you are releasing publicly but not too concerned about enforcement, MIT is a simple, permissive choice.
Therefore, I understood that I may continue to use MIT. It feels good to use MIT after understanding what kind of open source licenses exist and what the characteristics of each license are, rather than just continuing to use MIT.
