Every once in a while, community uproar over contentious open source licensing in a popular product will grab headlines, causing all of us to debate what open source licenses are really about. Last year it was the Apache Foundation’s ban of components with Facebook React’s contentious patent clause which caused a stir that sent developers running for the Reddit boards. These past few months, Redis Labs and MongoDB have made changes in the open source licenses of some of their most popular open source databases, leaving many to scratch their heads, highlighting the need to have open source licenses explained in human speak.
Each open source license states what users are permitted do with the software components, their obligations, and what they cannot do as per the terms and conditions. This might sound pretty straight forward, but there are over 200 open source licenses out there so good luck keeping them all organized. Varying in complexity and requirements, it is up to organizations to choose which licenses are most compatible with their policies to ensure that they remain compliant.
The two main categories of open source licenses often require in-depth explanation. Open source licenses can be divided into two main categories: copyleft and permissive. This division is based on the requirements and restrictions the license places on users.
Copyright is a law that restricts the right to use, modify, and share creative works without the permission of the copyright holder. Think about music, movies, etc that are the intellectual property of their creator. When an author releases a program under a copyleft license, they make a claim on the copyright of the work and issue a statement that other people have the right to use, modify, and share the work as long as the reciprocity of the obligation is maintained. In short, if they are using a component with this kind of open source license, then they too must make their code open for use by others as well.
A permissive open source license is a non-copyleft open source license that guarantees the freedom to use, modify, and redistribute, while also permitting proprietary derivative works. Permissive open source licenses, lovingly referred to as “Anything Goes”, place minimal restrictions on how others can use open source components. That means that this type of license allows varying degrees of freedom to use, modify, and redistribute open source code, permitting its use in proprietary derivative works, and requiring nearly nothing in return in regards to obligations moving forward.
It’s important to note that there are no good or bad licenses, and that no one license is better than another. Anyone can create an open source license that suits their fancy, which is the reason that there are so many out there. This could make choosing an open source license complicated business, especially for those of us who are not well versed in the law and have never had open source licenses explained thoroughly. In order to help narrow down the decision and make sense of it all, the OSI put together a list of approved licenses, consisting of a little over 80 open source licenses that are most commonly used.
Of the tens of open source licenses in the OSI approved list, some reign supreme and are used by some of the most popular open source projects out there.
We’ve put together a quick list explaining the most commonly used open source licenses:
The GNU’s General Public License is the most popular open source license around. Richard Stallman created the GPL to protect the GNU software from becoming proprietary, and it is a specific implementation of his “copyleft” concept.
GPL is a copyleft license. This means that any software that is written based on any GPL component must be released as open source. The result is that any software that uses any GPL open source component (regardless of its percentage in the entire code) is required to release its full source code and all of the rights to modify and distribute the entire code.
There has always been some confusion regarding what constitutes a ‘work based on’ another work, which in turn triggers the GPL reciprocity obligation. The FSF tried to add more clarity to GPLv3 as to when the reciprocity obligation is triggered. The FSF even wrote a new GPL license, the Affero license, to address a specific confusion referred to as the “ASP loophole”.
In addition, the FSF tried to increase the compatibility of the GPLv3 with other licenses. To combine two codes into a larger work, both the programs must permit it. If such rights are granted by both the programs’ licenses, they are compatible. By making the GPLv3 more compatible, the FSF expanded development options.
The third difference between the two versions is that the GPLv3 was written in an attempt to increase usage worldwide. The language used in GPLv3 to describe the license rights was modified to ensure that international laws will interpret it as the FSF intended, unlike the language used in GPLv2, which is considered very US-centric. GPLv3 also allows developers to add local disclaimers, which also helps increase its usage outside the US.
The Apache License is an open source software license released by the Apache Software Foundation (ASF). It’s a popular and widely deployed license backed by a strong community. The Apache License allows you to freely use, modify, and distribute any Apache licensed product. However, while doing so, you’re required to follow the terms of the Apache License.
The Apache Group (later named the Apache Software Foundation) released the first version of its license in 1995, but it’s rare that you’ll come across components that still carry this license.
In 2000, when Berkeley accepted the argument put to it by the Free Software Foundation and retired their advertising clause from the BSD license and formed the modified BSD license, Apache did likewise and created the Apache License version 1.1.
Removing the advertising clause meant that the advertising materials of the derivative works of any Apache licensed product were no longer required to include the Apache License attribution. It became ok to include the attribution in the documentation alone.
In 2004, the ASF decided to depart from the BSD model a little more radically and produced the Apache License version 2.0 by granting patents rights and defining solid definitions of the concepts it uses to make it more coherent.
The Microsoft Public License is a free and open source software license released by Microsoft, which wrote it for its projects that were released as open source.
You are free to reproduce and distribute original or derivative works of any software licensed under the Ms-PL license. However, you may not use any contributors’ name, logo, or trademarks when you do so. The Ms-PL protects the authors by explicitly not offering any express warranties or guarantees for using your code, so the author is not liable if the code doesn’t work well in some cases.
When you distribute software (or its portion) under the Ms-PL, you’re not required to distribute its source code. You may do so if you want to, but you’re not obliged. However, you’re required to retain all copyright, patent, trademark, and attribution notices that are originally present in the software.
Additionally, if you distribute any portion of the software in its source code form, you may do so only under the Ms-PL by including a complete copy of this license with your distribution. If you distribute any portion of the software in its compiled or object code form, you may only do so under any other license that complies with the Ms-PL.
It is important to note that the Ms-PL terms and conditions document is very short, concise and written in a very coherent language. Microsoft wanted to be very clear and direct with the open source community, which also helps the adoption rate (as we know from the BSD license).
BSD Licenses or the original BSD License and its two variants – the Modified BSD License (3-clause), and the Simplified BSD License/FreeBSD License (2-clause) are a family of permissive free software licenses.
The BSD License lets you freely modify and distribute your software’s code in the source or binary format as long as you retain a copy of the copyright notice, list of conditions, and the disclaimer.
The original BSD License or the 4-clause BSD License also contains an advertising clause and a non-endorsement clause (detailed explanation about these clauses are offered in the following questions). The modified BSD License or the 3-clause BSD License was formed by removing the advertising clause from the original BSD License. Further, the FreeBSD version or the 2-clause BSD License was formed by removing the non-endorsement clause from the modified BSD License or the 3-clause BSD License.
CDDL is an open source license published by Sun Microsystems to replace the Sun Public License (SPL). The CDDL license is considered by Sun (now Oracle) to be SPL version 2. It is inspired by the Mozilla Public License (MPL). Sun used to release its free software / open source projects under its Sun Public License (SPL) before it turned to rely upon the CDDL in 2004. CDDL is often dubbed as a cleaned up version of the MPL and is made to facilitate reusability.
You’re free to reproduce and distribute any original or derivative works of any software licensed under the CDDL. However, you must not remove or make any changes to any copyright, patent or trademark notices contained in the software. You must also retain any notices of licensing or any descriptive text giving attribution to any contributor or the initial developer.
When you distribute your software in an executable form (any form other than source code), you are required to make the source code available as well under the CDDL. The executable form may be released under the CDDL or any CDDL compatible licenses.
The source code that you have to make available includes your contributions as long as they are an addition to, deletion from or modification of the contents of a file containing the original software – or new files that contain parts of the original program. That means that if your additions are made in separate and independent files that do not contain the original code, you do not have to release it under the CDDL. You may do that if you choose to, but you’re not obliged.
In addition, you must include a copy of the CDDL with any source code that you distribute. For each modification that you make, you must identify yourself as the modifier by including a notice in your modified files.
The Eclipse Public License (EPL) is an open source license developed by the Eclipse Foundation. It’s derived from the Common Public License (CPL). The Eclipse codebase now available under the EPL was formerly licensed under the CPL.
The EPL license is a copyleft license. If you modify an EPL’ed component and distribute it in the source code form as part of your program, you’re required to disclose the modified code under the EPL. If you distribute such a program in its object code form, you’re required to state that the source code can be made available to the recipient upon request. You’re also required to share the method for requesting the source code.
The Eclipse Foundation makes clear that, in their opinion, ‘merely interfacing or interoperating’ with an Eclipse plugin does not make your code a derivative work of the plugin.
If you redistribute a program with an EPL component, you are obligated to include the full license text and the copyrights.
The EPL protects the author from possible lawsuits or damages caused if a company used his/her component in a commercial product. It also offers a patent grant.
The MIT License, created at the Massachusetts Institute of Technology, in the late ‘80s, is one of the most permissive free software licenses. Basically, you can do whatever you want with software licensed under the MIT license — as long as you add a copy of the original MIT license and copyright notice to it. The MIT License is very simple, short and to the point, which is why it has such a high adoption rate among developers, although some avoid it because it doesn’t expressly grant patent rights. Commercial organizations often prefer it because of its “no strings attached” nature.
If you’ve gotten this far, then you know that open source licenses are not for the faint of heart.
However, considering the fact that nearly all software developers rely heavily on open source components, it’s crucial to understand the basics of open source licensing, and the main differences between the popular open source licenses out there.
We only hope that this explanation has made the potential minefield of licenses just a little more navigatable.