authors are vetted experts in their fields and write on topics in which they have demonstrated experience. All of our content is peer reviewed and validated by Toptal experts in the same field.
David is an open source and open data enthusiast with 18 years of experience as a professional developer specialing in web development.
PREVIOUSLY AT
Not all open-source licenses are the same. Some of them obligate the software supplier to grant patent licenses to users and developers of the software. Other licenses oblige the developer that uses the licensed product or library to offer the source code of this product or library under the same terms. Others simply give away the code, with no warranty of any kind or any concerns. In this article I’ll try to highlight the main differences between the most used open-source licenses from the perspective of a software user and of a software developer.
When in 1984 Richard Stallman begun the GNU project for creating a free operating system, he recovered the idea that software should be shared between developers, engineers and users; and they should be able to improve it in a collaborative way in the same way that science is usually done.
This option contrasted with the usual concept of licensed software chosen by most of the software corporations and developers for distributing and selling their programs. Today, more than thirty years later, open-source software slowly continues conquering wide sectors of our industry: Linux, Android, Apache and Git are examples of leading open-source products in their categories.
In this article, I’ll use the terms “open-source” and “free” as synonyms while referring to software or licenses. In my opinion, both terms express the same idea. “Open-source” expresses it in a practical and technical way, and using “Free” put the focus in a philosophical and political meaning of the concept.
Unfortunately the word “free” in English, in addition to being the adjective associated with “freedom”, also means “without cost”. This is the reason that I usually prefer to say “open-source”.
I suppose that you already have an approximate idea of what open-source software is. But as we are going to talk about the details of the different licenses, first we need to speak about the specific properties that define open-source software.
First of all: I am not a lawyer, and this is not legal advice. In case of doubt, please refer to the actual text of the licenses I am talking about, and to your legal counselor.
All open-source software, according to the Open Source Initiative, is distributed under a license that gives its users and developers (the licensees) some rights. The full list can be consulted in the Open Source Definition, but here is a basic summary:
But you must keep in mind that software licenses speak only about using or distributing permissions granted by the copyright holders. Open-source licenses may allow you to redistribute the software or derived works freely, but that allowance may also be restricted in some countries where exporting cryptographic software is banned. In a similar way, open-source licenses allow you to use the software for any purpose, but that doesn’t mean that they allow you to hack into a bank using open-source licensed software. Software patents are another example of this: some open-source licenses grant permissions to use patents freely, but not all of them.
So, can we use an open-source software in the development of a product or project? Basically, it depends on the license of the used software and the intended license for the final product. The different licenses also matter when you want to publish your own code as open-source and you are deciding which license you should use.
One pretty interesting concept about open-source licenses is what is usually called copyleft, the opposite of copyright. Where copyright is used to protect intellectual property (including software) from being copied or distributed, copyleft is used to ensure that open-sourced intellectual property and software can be copied or distributed as open source.
According to its strength, there are two kinds of copyleft:
There are also open-source licenses without copyleft: they simply don’t care about future openness of derived software.
According to their permissiveness, the licenses can also be classified in:
Usually, strong copyleft licenses are also strict, and weak copyleft licenses are more permissive, but it doesn’t have to be that way.
There exist many open-source licenses. The Open Source Initiative has already approved more than 80 of them. Some are redundant and could be considered as equivalent to other ones. Others are specific to the interests of the software publisher (such as the NASA license), or for a given environment or purpose (such as the Educational Community License, or the Open Font License).
This proliferation of licenses is based in specific terms in the license that, added to the basic open-source properties, allow or disallow other uses. Examples of these additional conditions can include:
According to what we have already said before, some licenses are permissive, allowing the users to combine the code with differently-licensed source code (perhaps with additional conditions). This case would allow to mix this kind of open-source licensed software with closed-source software. An example of this kind of license is MIT License.
Others are more restrictive, so the source code can only be combined with code that is licensed in a similar way, and the final result must be licensed with the same original license. An example of this kind of license is General Public License (GPL).
Maybe you want to combine code licensed with two different restrictive open-source licenses. Using the open-source freedom to use the software as you want, you can do this. But the final program cannot be redistributed, as it should be distributed under two licenses that are not compatible with each other.
One example of this situation was ZFS. ZFS is a very advanced and innovative filesystem that was included in OpenSolaris in 2005. It is an open-source software licensed under the terms of the Common Development and Distribution License (CDDL). Although it is open-source code, it can’t be integrated into the Linux kernel because the source code of Linux is distributed under the terms of the General Public License, another restrictive open-source license. Binaries of Linux kernel compiled with ZFS support cannot be distributed due to the license conflict.
These kinds of conflict can only be solved if all the owners of one of the open-source programs agree on changing the license, or on adding exception terms in the software license. For example: a lot of GPL licensed programs are linked with OpenSSL library. OpenSSL library distribution is licensed requiring a phrase to appear in advertising material and any redistributions. These extra conditions are not compatible with the GPL, and because of this developers of GPL products that use OpenSSL have included an exception in their license specifically allowing the linking with OpenSSL.
Now I’ll try to analyze the most popular open-source licenses, remarking their differential features, with a little guide about when to use them or not. I have sorted them from the more to less used, according to the Black Duck Knowledgebase.
The GPL is the most popular open-source license. It was created by the FSF as the license for the GNU project, and it’s also the license of the Linux kernel.
Its differential characteristics:
Usually, the used license text includes the text saying that the software is distributed under the terms of the GPL version N (or any later version).
Currently there exist two versions of GPL license in use: v2 and v3. The version 3 was released in 2007 for addressing some problems that had appeared since the release of version 2 in 1991.
The GPL v3 includes some extra clauses and terms, addressing compatibility regulations with other open-source licenses, obliging patent licensing, defining the conditions for using GPL-licensed software as firmware in appliances, and taking into account concepts as digital rights management.
The open-source license usually known as MIT License, a.k.a. X11 license, is a very permissive non-copyleft license that allows everyone to basically use the so-licensed code for whatever you want as long as you keep the copyright message, and know that the software comes without warranty of any kind.
This license is very popular, and is used by several projects as the X Window System, Ruby on Rails, jQuery or Node.js.
It’s compatible with the GPL, so you can mix MIT-licensed code into GPL software.
The Apache License was created by the Apache Software Foundation (ASF) as the license for its Apache HTTP Server.
Just as MIT License, it’s a very permissive non-copyleft license that allows using the software for any purpose, distributing it, modifying it, and distributing derived works of it without concern for royalties. Its main difference compared to the MIT License are:
This license is interesting because of the automatic patent license, and the clause about contribution submission.
It’s compatible with the GPL, so you can mix Apache licensed-code into GPL software.
There are 3 different BSD licenses. All of them are very permissive licenses without copyleft.
The 2-clause BSD License (or Simplified BSD License) is totally equivalent of the MIT License that was explained before.
The 3-clause BSD License (or New BSD License) adds one clause, specifying that neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from the software without specific prior written permission. This version is compatible with the GPL allowing you to mix 3-clause-BSD licensed code into GPL software.
The 4-clause BSD License (or Original BSD License) adds another clause, specifying that all advertising materials mentioning features or use of the software must display an acknowledgement saying that the product includes software developed by the copyright holder. This 4-clause BSD License is not compatible with the GPL. Code with this license cannot be relicensed according to the GPL terms, as the fourth clause adds a requirement that is not required in the GPL.
The LGPL was created by the FSF as a modification of the GPL with a weaker copyleft, allowing the linking of LGPL-licensed software with any other software. In its origins LGPL stood for “Library General Public License”, but afterwards it took its current name “Lesser General Public License” standing for the FSF’s opinion that says that all software should be free, and because of that the LGPL shouldn’t be generally used.
You can link closed-source code against an LGPL library or software and distribute the final results as long as:
The LGPL v3 is compatible with GPLv3, so you can enter LGPLv3 code into GPL software.
The Artistic License, in its current version 2.0, is a permissive open-source license with no copyleft similar to the MIT license.
The main difference between the MIT license and the Artistic License is that the latter requires that any modification made to the code must be clearly stated.
This license is almost exclusively used in the Perl community.
The current Artistic License 2.0 is compatible with GPL: you can mix Artistic-Licensed code into GPL software.
The Microsoft Public License was created in 2008 by this company as one of the open-source licenses created by their Shared Source Initiative.
It’s a strict, weak copyleft license: it allows the creation and distribution of closed-source programs with MS-PLed code, but it obliges to use the MS-PL as the license of derived works if these are distributed in source code.
I personally think that this license is a bit perverse and contrary to the spirit of the open-source, allowing the closure of code so that in a way the copyright holder doesn’t care about what you can do with the software, but you cannot share the code for being mixed with other copyleft source code. So in another way, the copyright holder really does care about what you can do, and he doesn’t want you to use the code for reasons such as improving Linux.
The MS-PL is incompatible with the GPL.
The Eclipse Public License is the license created by the Eclipse Foundation for their Integrated Development Environment. It’s a restrictive and weak-copyleft license, similar in many ways to LGPL. It also includes clauses for automatic patent license granting.
The EPL is incompatible with the GPL.
The Mozilla Public License version 2.0 is a weak-copyleft, permissive license created by the Mozilla Foundation for its products.
We could consider this license as similar to LGPL, but with the main difference that MPL also allows the static-linking of the MPLed pieces of code into closed-source software.
The MPL, in its current version 2.0 is compatible with the GPL. This isn’t true for previous versions of the MPL.
The CDDL is a weak-copyleft, permissive license created by Sun (now Oracle) based on MPL version 1.1. Basically, it has the same properties as the MPL. Its terms were clarified, but not substantially changed.
The CDDL is the open-source license chosen by Sun (now Oracle) for many of its products, as OpenSolaris or NetBeans, among others.
As this license was based on the MPLv1.1, this license is not compatible with GPL, so you cannot mix CDDL-licensed source into a GPL licensed software. Many people say that this was intentional, so OpenSolaris source code cannot be introduced into the Linux kernel.
The AGPL is a version of the GPL with even stronger and more restrictive copyleft. It obliges to provide the source code of the application not only to the people receiving a copy of the software, but also to the people who use this software through a computer network.
This license was created by the FSF for giving the developers the means for avoiding the practical closure of open-source software when it is executed in network servers or in the cloud, as the GPL cannot force the service providers to give source code to the users. In this case the software is not distributed.
The AGPLv3 is compatible with the GPL3. You can put AGPLv3 code into GPLv3 code, as long as the final result is licensed under the AGPLv3.
The ISC License is a permissive free software license written by the Internet Software Consortium (ISC). It is functionally equivalent to the 2-clause BSD and MIT licenses, after removing some language that was deemed unnecessary.
Initially used for ISC’s own software releases, it has since become the preferred license of OpenBSD (starting June 2003), among other projects.
It’s compatible with the GPL: you can mix ISC-licensed code into GPL software.
The Microsoft Reciprocal License was created in 2008 by this company as one of the open-source licenses created by their Shared Source Initiative.
It’s similar to the MS-PL explained before, but it has a bit stronger copyleft, resembling the conditions of the LGPL, CDDL, and EPL. It requires that if you mix your code with MS-RL-licensed source code and want to distribute the final results, at least the original MS-RL-licensed part must continue to be licensed with this license.
It isn’t compatible with the GPL.
According to Wikipedia, “works in the public domain are those whose intellectual property rights have expired, have been forfeited, or are inapplicable”. Dedicating a work to the public domain, the author waives all his rights over it under copyright law.
There are several software projects under Public Domain, for example SQLite, the library that implements an embeddable and simple SQL database engine that is included in several other projects, such as Mozilla projects, Android, etc.
There are many ways for dedicating a piece of software to the public domain. Creative Commons has created the CC0 Public Domain Dedication, a universal way for giving away a work into the public domain. The FSF recommends using this text for dedicating software to the public domain.
Works under public domain are compatible with any open or closed source licenses, and can be mixed into any other software.
There’s some open-source software that is double or even triple licensed. This means that a person who receives this multiple-licensed software can choose under which license he or she wants to distribute it. As every license grants different permissions and imposes different obligations, a selection must be made for choosing the license that best meets the needs.
This is a usual case for some libraries. For example, NSS is a library made by Mozilla that implements SSL/TLS support, among other security-related features. It’s triply-licensed under MPL, GPL, and LGPL licenses.
A lot of people publish code in platforms as GitHub without any written license. Nobody should use that code. We don’t have any idea what permissions we have for using it. If you use it, you could be sued for that. It’s like if these people were teasing us, saying “Hey, look what I’ve made! Cool, isn’t it? But you can’t use it, I only wanted to show you!”.
Please don’t be one of them. If you upload your code to GitHub or similar public sites, allow others to use it and enhance it. If you don’t want to think a lot, these are my recommendations:
If you care about sharing modifications and you don’t want your code to be used in closed developments (neither in closed software products nor in closed hardware appliances), use GPL v3.
After all this, you may be exhausted of all these almost-nonsense quasi-legal gibberish. But do you know what? It’s needed. Because without a license, you don’t have the rights for using or distributing any code.
Cobeña, Spain
July 2, 2015
David is an open source and open data enthusiast with 18 years of experience as a professional developer specialing in web development.
PREVIOUSLY AT
World-class articles, delivered weekly.
World-class articles, delivered weekly.
Join the Toptal® community.