A Short Guide to Open Source Licenses
The world of open source licensing can be a confusing place, and there are several misconceptions that many people have about the different license types and what they mean. Whether you’re consuming open source software, contributing to an open source project, or creating and maintaining your own project, it’s important to understand at least the basics of open source licensing. In this short article I will attempt to arm you with the key information that you’ll need, and I will also hopefully dispel a few open source licensing myths and misconceptions as I go.
What is open source licensing and why do we need it?
An open source license is a type of license usually associated with computer software (but it can apply to other products too) that enables the source code to be used, distributed or modified under the defined terms of the license. Effectively this means that an open source license informs people what they can and can’t do with the source code.
Rather than having to grant permissions on a case by case basis, open source licenses provide an easy way for source code to made available for others to use without needing to seek explicit permission. On top of this, they still enable some protection for the original author(s), as typically the copyright attribution statements are preserved and it helps to prevent people from claiming the work of others as their own.
If I make my GitHub repository public then isn’t that enough to make it open source?
There is common misunderstanding that a code repository that has been made public (say, on GitHub.com) will automatically be classed as open source code. This is not the case. Any code that is created by an individual or an organisation is legally under exclusive copyright by default. This means that no one else is allowed to use, distribute or modify it without the explicit permission of the author(s). If source code is made public (either deliberately or accidentally), and if there is no license information available alongside the source code, then this is not open source code.
It is therefore not recommended to use or consume any code that is publicly available unless it has an explicit open source license associated with it. On top of this, if you’re intending to open source some of your own code then make sure you do associate a standard open source license with the code if you want other people to be able to freely use, distribute or modify it.
There are so many different open source licenses — how do I make sense of them all?
There are a very large number of open source licenses that are in use today, and new license types are frequently being created. It can be daunting to try to make sense of each of the hundreds of licenses that are out there, particularly given that most of them are written in hard to understand “legal speak”. Do not fear though, there are only a handful of different licenses that are used across the vast majority of open source projects — so understanding this small selection will be enough in most cases.
According to the Open Source Initiative (OSI), an official/approved open source license is one that complies with their Open Source Definition. This is just one point of view though, and there are numerous licenses that claim to be open source but that don’t meet this definition — however, for simplicity I would recommend sticking with those licenses that are approved by the OSI where possible.
Before we look in detail at some of the most common open source licenses, it’s important to understand that there are two main types of license — restrictive licenses (often referred to as “copyleft”) and permissive licenses. Below is an brief explanation of what these terms mean in the context of open source licensing.
Restrictive/Copyleft: These licenses require derived work to use the same license as the original work. For example, if you choose to modify and distribute some software that was originally released under “copyleft license x”, then your modified version must also be released under “copyleft license x” — including any new code that is written specifically for the modified version. The primary purpose of these copyleft licenses is to ensure that the open source nature of the project is preserved — it prevents someone taking the source code and then using it in their own proprietary software.
Permissive: These licenses are less restrictive than the copyleft licenses. They enable the code to be used with minimal restrictions — including modification and redistribution of the code, and the creation of proprietary software using the original open source code.
Five of the most widely used open source licenses
The following five open source licenses are some of the most widely used across the industry, and are probably the ones that you’re most likely to encounter. I will provide a brief summary of each of these licenses and will show what permissions they cover and what conditions they require.
1. MIT License
This is one of the shortest and simplest licenses. It is a permissive open source license — meaning that derived work and modifications can be distributed under different license terms (or as part of proprietary software). The only condition is that the copyright notice and the license terms must be preserved in all copies and modified versions.
2. Apache License 2.0
This is another permissive open source license — meaning that derived work and modifications can be distributed under different license terms (or as part of proprietary software). It is similar to the MIT License but has longer and slightly more complex terms and conditions as it makes explicit statements about a number of things — such as an explicit statement that the license does not grant trademark rights, and an additional condition mandating that all modified files must contain notices to highlight that they’ve been changed. On top of this, this license includes an express grant of patent rights from the contributors.
3. GNU General Public License (GPL) v2.0 and v3.0
This is a strong restrictive/copyleft open source license — meaning that all derived work must be distributed using the same license, and the complete source code of the derived work must be made available. It mandates that copyright and license notices must be preserved, and also mandates that all changes/modifications that are made must be documented.
There are two main versions of this license in use — an older version (2.0) and an updated version (v3.0). The biggest difference between them is that v3.0 contains an express grant of patent rights, whereas v2.0 doesn’t.
4. GNU Lesser General Public License (LGPL) v2.1 and v.3.0
This is a fairly weak restrictive/copyleft open source license in comparison to the GPL. It allows derived work that only links to the software (i.e. using it as a library) to be exempt from the copyleft restrictions. All derived work that does not merely link to the software must be distributed under the same license as the original work, and the complete source code must be made available. It mandates that copyright and license notices must be preserved, and also mandates that all changes/modifications that are made must be documented.
There are two main versions of this license in use — an older version (2.1) and an updated version (v3.0). The biggest difference between them is that v3.0 contains an express grant of patent rights, whereas v2.1 doesn’t.
5. Berkeley Software Distribution (BSD) 2-clause and 3-clause variants
This is a permissive open source license that is almost identical to the MIT License. There is a “2-clause” variant and a “3-clause” variant. The “3-clause” variant contains an explicit statement to prohibit others from using the name of the copyright holder or contributors to endorse/promote products derived from the software without specific written permission.
Further Information
There is of course a lot more to open source licensing on top of what I’ve included here, however, I’ve covered the basics and this will hopefully provide you with the foundational knowledge that you’ll need to have confidence using, contributing to, or creating open source software.
For further information about open source licensing, including details of specific licenses that I haven’t covered in this article, then I’d recommend visiting the following websites:
