Open Source License Comparison: Connecting and Contrasting The Dots
Table of Contents
Delving into the world of open source license comparison is not for the faint of heart. Copy-left this, permissive that, and what, in the name of GNU, is the difference between GPL 2 and GPL 3?
With over 80 OSI-approved open source licenses out there, and hundreds of others floating around the open source ecosystem, putting together an open source license comparison is no easy feat.
While some open source licenses are short and simply-worded for those of us who just want to release our open source project, others are lengthy, complex, and have been known to keep legal teams long into the night, running up plenty of billable hours. In the hopes of clearing up some of the confusion, we’ve mapped out some of the elements that can help us conduct an actionable open source license comparison.
Comparison basics: Permissive vs. copyleft open source licenses
Open source licenses are usually divided into two main groups: permissive, also known as “anything goes”, and copyleft, otherwise known as “viral”. Theis open source license comparison is based on how restrictive, or — you guessed it — permissive the license is, as well as how many requirements and permissions are attached to using an open source software component.
When an open source component is released under a copyleft license, developers have the right to use, modify, and share the work as long as the reciprocity of the obligation is maintained. Using a component with this kind of open source license requires that you too must make the code open for use by others. The GPL family of licenses is the first and most popular of this bunch, and includes a number of versions and variations.
On the other end of the spectrum lies the permissive open source license. This 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 place very few restrictions on how the components that they are attached to are used, and require nearly nothing in return. The most simply worded and popular of this group of licenses is the MIT license, which is a favorite for developers that just want to get their open source project out there.
Licensing limitations, conditions, and permissions — Oh my!
While the distinction between permissive and non-permissive open source licenses is an important one, the licenses and license families in each of the groups differ based on a number of additional parameters.
For example, MIT and Apache licenses might both belong in the “anything goes” category, but they are far from identical. The same is true for, say, the Eclipse and GPLv3 viral licenses — just because they are both viral, that doesn’t mean they share the exact same terms and conditions.
Every open source license has its own unique set of limitations, conditions, and permissions that differentiates it from the rest. GitHub’s choosealicense.com site, created to help developers working on open source projects to easily find the open source license that suits their needs, offers an appendix that compares open source licenses and maps out the differences and similarities based on what they permit and what they restrict.
According to the appendix, open source licenses grant permissions to do things with licensed works that might not be allowed under copyright or other intellectual property laws. These permissions are often subject to compliance with conditions, and most open source licenses also have limitations that disclaim warranty and liability and sometimes expressly exclude patent or trademark from licenses’ grants.
Sharing is caring: Permissions in open source licenses
The actions that are most often granted permissions in an open source license relate to commercial use, distribution, modification, and private use.
Patent use is a big differentiator in the group of permitted actions. Many open source licenses provide an express grant of patent rights from contributors under certain conditions, like GPLv3, the Apache License version 2.0, Eclipse Public License versions 1.0 and 2.0, and others. Other open source licenses explicitly state that they do not grant any rights in the patents of contributors. Open source licenses that deny patent rights include the BSD 3-Clause Clear License, the Creative Commons Attribution 4.0 International, the Creative Commons Attribution Share Alike 4.0 International, the Creative Commons Zero v1.0 Universal, and the ODC Open Database License v1.0.
While all open source licenses grant permissions for commercial use, distribution, modification, and private use, the permissions are subject to certain conditions, which vary from license to license. Conditions might include making the source code available when the software is distributed via network or other channels, including a license and copyright notice to the software using the open source project, releasing code modifications under the same license, and documenting any changes made to the code.
There’s always a but: Conditions in open source licenses
As a rule, copyleft licenses usually carry more conditions compared to permissive open source licenses. This is one of the reasons their popularity continues to decline as open source usage has become the norm in commercial organizations.
One of the most well-known examples is the GPL licensing family. We can see a good example in the case of distribution via a network, also known as the SaaS loophole. While GPL versions 2.0 and 3.0 ‘s conditions don’t state that network use is distribution, the AGPL v3.0, considered the strongest copyleft license, does require that when a modified version is used to provide a service over a network, that the complete source code of the modified version must be made available.
Drawing a line: Limitations in open source licenses
Another way to compare open source licenses is to look at their limitations. Limitations in open source licenses touch on liability, an explicit statement that the license does not grant trademark rights, and an explicit statement that it does not provide a warranty.
The main differentiator here is trademark use. Most GPL family licenses don’t explicitly state that they don’t grant trademark rights, as opposed to Creative Commons licenses or the Apache v2.0 license, that explicitly include this limitation. It’s important to mention that the GitHub index notes that licenses without this type of statement probably do not grant any implicit trademark rights.
Comparing copyleft: GNU GPL family vs. Eclipse open source licenses
Both the Eclipse Open Source License (EPL), and the entire family of GNU GPL are considered copyleft, with each type being non-permissive to different degrees. The GNU GPL family of licenses has a strong copyleft clause that requires users to release their software’s full source code, regardless of the volume of GPL’ed code included.
On the other side of the non-permissive scale is the Eclipse license, considered to be a weak copyleft license. The EPL doesn’t require users to share their entire software project, just to open source any included modified EPL’ed components when distributing in the source code form, and make the source code available upon request when distributing in the object form.
Another difference between the two types of licenses is that the EPL requires users to disclose their source on source code, but not on binaries, while the strong copyleft GPL family requests that you reuse the same license in case of re-distribution of copies or derivatives on both source and binaries.
Comparing permissive: Apache license 2.0 vs. BSD open source license
The BSD license is a highly permissible license that allows users to modify and redistribute software licensed under the BSD license however they want. While earlier versions of the Apache License were identical to the BSD licenses, Apache License 2.0 placed a few key differences that now set the two licenses apart.
The first difference is the explicit grant of patent rights. Apache License 2.0 explicitly lays down the grant of patent rights while using, modifying or distributing Apache licensed software, and lists the circumstances when such grant gets withdrawn.
Another big difference between the two licenses is the clear definitions of the used concepts. Apache License 2.0 explicitly defines all the terms and concepts that it uses, leaving little scope for ambiguity.
The third notable difference is that the Apache License 2.0 is reusable without rewording. It can be easily used by other projects without having to reword anything in the license document itself, thus making it one of the most popular options for developers who want to avoid spending too much time on dealing with licensing issues.
Open source license comparison: Making sense of it all
Whether you’ve developed a software project and need to attach an open source license to it so that it’s available to share, or you want to make sure that the open source license attached to a software component that you are using is compatible with your own project and needs, it’s important to understand the different limitations, conditions, and permissions attached to each license.
While the distinctions may seem subtle, they often define the way an open source component can be used and distributed, not to mention the many conditions users are required to comply with along the way. As is always the case in legal matters, the details make all the difference. That’s why it’s a good idea to be familiar with them, or at least be aware that they exist so that you know to pass the questions on to the legal eagles in your organization.
The ins and outs of open source licenses is a tricky business, and a comprehensive open source license comparison quite a challenge. Having these basic touchstones to know what to compare can help discern which license is the right fit for your project, or at least make you look smart next time someone in the office mentions license compliance.
*Disclaimer: This post is not legal advice, it is for informational purposes only. If you need legal advice, you should consult with an attorney who has reviewed all relevant facts and applicable law.
