A brief guide to open-source licenses
Some open-source components may require you to make your source-code public. Understand what are open-source licenses and what comes free and what doesn’t to keep away from legal peril
The popular world of open-source licenses can be a confusing territory to venture into and there may be several misunderstandings clouding our understanding. If you are contributing to an open-source project or are consuming any open-source software or maintaining and building your own open-source project, it may be beneficial for you to know at least the basics of open-source licenses. In this short guide let me try to dispel some of the misconceptions and try to arm you with more information on open source licensing.
Consider a situation while you are using a certain software…
Are you aware of what’s in your software? If you have written all of the code including any frameworks or libraries, you may know it all. However if you fall in the majority, who’d write only a portion of the entire codebase, then you may not know it all. It is possible that up to 90% of the source code could be third party code. This brings me to ask you a question. Are you aware of the part that you didn’t code?
This may be somewhat difficult to answer. It is possible that the codebase could contain code from the library belonging to the open-source repository. While it may be free, using it may attract legal peril.
Some of the FOSS (Free and Open-Source Software) may let you use, edit and distribute the source code without any direct attributes. However, some other open-source licenses may not give you that independence. These restrictive kinds of open-source licenses may need you to make your proprietary project public and in tune with the similar licensing terms as the original FOSS.
Community uproar over open-source license…
Every once in a while we may come across instances of community uproar over some contentious open-source license of some popular products. This may grab the headline and send us off on a debating spree of what exactly are open-source licenses. Recently, the Apache Foundation’s ban of the components with Facebook’s React patent clause caused a major stir amidst the developer community. Also in the recent past, MongoDB and Redis Labs have made transformations in the open-source license of some of their popular open-source databases. This makes us more curious about what exactly are these open-source licenses?
What are open-source licenses?
Open-source licenses can be understood as binding and legal contracts between the creator and the user of particular software or component, specifying that the software may be used for commercial applications under certain terms and conditions. These licenses turn the source code into open-source components. Without any open-source license, the software component may be unusable by others even if being publicly posted on GitHub. An open-source license defines what the users can and cannot do with the source code.
Each of the open-source licenses specifies how the users can use, edit, distribute the source code and what are the obligations. This may sound straightforward at first read however there are over 200 open-source licenses varying in requirements and complexities. It is up to the enterprises to opt for the licenses that are most compatible with their policies to ensure that they are compliant.
Why do we need open-source licenses?
Let’s assume that you are creating a new business model that requires you to develop an application. Rather than writing your own code for app development, you may use the open-source code or some parts of it. Let’s say you may consider using OpenSSL. The recent licensing on OpenSSL is Apache styled which means that it is a free and permissive license style. Also at the same time, OpenSSL is a dual license. Hence you may need to read the library files carefully.
It's absolutely alright to use the open-source code however you may need to analyze it before deploying. You are expected to know what are the licenses of the components, if the files of the library are current or if there are any outstanding CVEs for the current version.
Open-source licenses also save up the multiple licensing requirements. Rather than having to give permission on every use case, open-source licenses make it easier for the developers to access the source code with certain t&cs in place. Here the need to seek explicit permission is eliminated. This license also provides protection to the original creator of the software or components. This restricts people from claiming the works of others as their own.
There is a misunderstanding: a code repository if, made public can automatically be classified as open-source…
This is not true. This is a misunderstanding. A lot of developers often come up with the question that ‘if I make my GitHub repository public it should be enough to make it open-sourced?’
Any code that is developed by an organization or an individual is under legal copyright by default. This implies that nobody is permitted to use it, edit it or distribute it without obtaining the permission of the creators. If the source code is accidentally or deliberately made public without any licensing information, then it is not considered open-source.
Hence consuming any code that’s available publicly without an explicit open-source license is not a good idea. Also if you are willing to open-source any of your code then ensure that you follow it up with a legal open-source license. This is the best way of letting the citizen developers use, alter or distribute it.
There are different types of open-source licenses
There are a number of open-source licenses in use today and a number of fresh ones are minted every day. It could be a daunting task to try to make sense of all of them and especially because most of them are written in hard legal words! However, there is nothing to fear as there are a handful of the licenses that are being used across a majority of open-source projects. Understanding some of them will get you going pro!
As per the Open Source Initiative(OSI), an official or approved open-source license is the one that remains compliant with the Open-Source Definition. However this could be one perspective, there are hundreds of other licenses that necessarily do not speak the language of the open-source definition. But to keep things simple it is recommended to stick with those licenses that are recognized by the OSI wherever possible.
There are mostly two categories in which open-source licenses can be divided into; Copyleft & Permissive. The division majorly supports the restriction and the obligations that the license can place on its users.
1. Restrictive/Copyleft Licenses
These licenses have the requirements for the derived work to use the same license as the original work. Copyright as a law puts restrictions on the use, modification and sharing of the creative original work without explicit permissions of the original creator. For example consider books, movies etc. that are the intellectual properties of the creator. When an author releases any creation under the copyleft license, they are claiming the copyright of their original work. The users may alter, share etc. the work as long as the reciprocity of the obligations remains maintained. If one is using a component with the open-source license then the individual or organization is also expected to make its code open-source.
Copyleft come with different kinds of licenses with varying scope. Some copyleft licenses permit you to release only the modified code. While other licenses may need you to release the whole of the application under the same base license.
The copyleft licenses have the primary purpose of ensuring that the open-source nature of the project remains preserved. It restricts an individual or an organization from taking the source code and using it in its proprietary software.
2. Permissive Licenses
Permissive licenses are less restrictive in nature. They come with the freedom to use, modify or distribute the source code. These licenses also permit proprietary derivative work. Permissive licenses are also fondly called the ‘Anything Goes’. They come with minimal restrictions on how others are able to use, modify or distribute the open-source code. They also come with minimal obligations or expectations of returns.
Other than these two licenses we can talk about a third one called the Public Domain. This model is considered to be the most permissive model allowing the users to consume and modify the software without any restrictions whatsoever. But with some years of wisdom I can say, even if a component comes free without any kind of legal obligations, one should be motivated to add it to own codebase only after ensuring that it is secure.
Let me throw some light on unlicensed code. ‘Unlicensed' doesn’t mean public domain. Even if the code that is released for the public does not come with an explicit license, there are still certain prevailing obligations to be obliged to make use of the source code. The copyright for the unlicensed code naturally belongs to the author of the code. We may treat the unlicensed code safely as proprietary i.e. open-source.
For our better understanding let us have a look at some of the differentiating factors of open-source licenses
We know there are many open-source licenses. The Open Source Initiative has approved about 80 of them already. Out of which some may be redundant while others may be more like the existing ones. Some licenses can be very unique as per the interests of the creator of the software, for example, the NASA license.
These differences are basic to the specific terms spelt out in the license when added to the fundamental open-source properties, giving them their unique nature. Based on the nature of these open-source licenses users are allowed or disallowed to use, modify or redistribute the source code.
Certain specified terms or additional conditions can be
· Type of copyleft license, with weak or strong attributes
· Type of permissive license being weak or strict
· The obligation to add the copyright notice in the user interface or in the source code.
· Granting automatic patent to the licenses
· Taking into consideration the licensees to be the users of the open-source software along with the authors of the software.
We may encounter a problem of mixing code with different sets of licenses
By now we know that there are a different set of licenses.
Some are permissive that let the users combine the code with different open-sourced license base codes. This may let the assimilation of open-source license software with the closed-source software. An example of this type of license is MIT License
Other licenses may be more restrictive, where the source code can be only combined with the source code whose licenses are similar to the previous one. The final result is required to be similar to the original license. General Public License(GPL) is an example of this kind of license.
Consider a situation where you’d want to bring together a code license with two different open-source licenses. With the open-source freedom to use the software as per your needs, you’d be able to do this. However, when you’d want to redistribute the final programme it may get somewhat difficult. This final programme needs to be distributed under two different licenses, which may be a problem.
An example of the situation could be the ZES fiasco. ZES was an innovative and progressive file system that was there in OpenSolaris in 2005. This is open-source software licensed under the t&c of the CDDL (Common Development & Distribution License) Although this one is open-source, it cannot be assimilated into the Linux kernel. This is because of the source code of Linux being distributed under the terms of General Public License. The binaries of the Linux kernel when compiled with ZES support couldn’t be redistributed because of the underlying license conflict.
These conflicts could only be resolved when the owners or authors of the open-source projects agree upon changing the open-source license or adding certain exceptional conditions to the license.
Let us look at some of the popular open-source licenses
Let us understand that there remain no good or bad licenses and that no one license can be compared to call better than the other one. Individuals or an organization is able to create an open-source license as per their requirements. This is one reason why we have so many of them around us. This could also put us in a situation wherein we’d find it difficult to opt for a license that could suit our requirements optimally. Especially for some of us who are not very well versed with the legal aspects of it. Here the OSI has been supportive of putting together a list of over 80 licenses. These are recognized by OSI. Of the many OSI approved list of open-source licenses, some are more popular than others. Let's have a look at some of them.
The Apache License:2.0
This license is an open-source license released by the Apache Software Foundation. This one is backed by a strong community of developers and is a popular and widely deployed license. It is a Permissive license; we can seamlessly use, modify and distribute the Apache-licensed products. Nevertheless, you are required to follow the terms and conditions underlined along with the license.
There have been certain edits in the license since its origin. In the year 2000, the advertising clause originally inserted was removed. Now if any advertising material is created for derivative work they need not include the attribution to the Apache License -however, such attributions need to be there in the documentation. In the year 2004, another update made the patent rights available to the license.
The MIT License
The MIT License was created by the Massachusetts Institute of Technology. This was back in the late ‘80s. MIT license is one of the most permissive free software licenses. Everyone is free to use the licensed code for whatever needs as long as the copyright message is kept intact. The license comes without any kind of warranty. This license grants all the end-user rights like using, merging, distributing, modifying etc. It also allows the copy owner's name in promotional content. It doesn’t include especially an advertising clause.
This license is quite popular and used by a number of popular projects that we know of today like Ruby on Rails, X Window System, jQuery or Node.js etc.
Berkely Software Distribution License (BSD)
BSD licenses and their two variants – The modified BSD License (3 clauses) and the Simplified BSD License or Free License (2 -Clause) are permissive software licenses.
Each of the BSD licenses grants permission to change or distribute the software code, binary or source. However, the user is expected to retain a copy of the terms and conditions, copyright notice and the disclaimer as the original.
The original BSD licenses came with 4 clauses inclusive of advertisement and non-endorsement clauses also. The modified 3 clause license doesn’t entail the advertising clause. The simplified 2 clause license has done away with the non-endorsement clause.
GNU General Public License (GPL)
The GPL is the most popular open-source license, WordPress themes and plugins use this license. It is a strong copyleft license, so any of the components or software that uses the GPL license need to be open-source even if only very little code is in the modified section. Any software using the license is needed to release the whole source code along with all the rights to edit or use the software. This license mandates that all the license notices and copyright needs to be preserved along with all the modifications that need to be documented.
There are two versions of the license in use - an updated version 3.0 and also the older version – 2.0. One of the key differences between them is that v3.0 comes with an express granting of patent rights while v2.0 doesn’t.
Opting for an open-source license should be your priority
A lot of the users are seemingly publishing their code on platforms such as GitHub without having any written license. It is advisable to not use such code. This is because we really have no idea about the permission we have to use that license. Using such a code may have legal implications.
Don’t be one of them! If you are uploading your code on GitHub or other similar sites do give explicit rights to the users to consume it and enhance it. You can consider the following if you are just beginning with the process.
- If you prefer to keep the license simple and permissive letting others do whatever they want to do with your code: edit it, use it or share it along with providing attributions back to you then you may use the MIT license. In this way, they’ll not hold you liable.
- If you’d prefer the developers and others to do what they prefer with the code but would enumerate the rights under the copyright law and grant of those rights, Apache license may be well suited. Here you can also provide explicit patent rights from the contributors to users.
- If you are concerned about sharing the modifications and are not keen on your source code being used in close development projects, you can use the GPL V3 license.
Licenses are important without which you’d not have the rights to use, modify or share any code.
This naturally brings us to the question of how to go about opting for an open-source license?
Taking a call on what open-source license to use for your project could be a challenging task. Other than the above-mentioned recommendations we can gain more clarity by looking at what answers do we have for the below-mentioned questions
1. Do you intend to bring your code to the wider open-source infrastructure?
Many of the popular communities have their favourite license. You may consider selecting the license that has been accepted and vetted by the community of your choice.
2. What kinds of rights do you want to give to your users to consume your project?
Are you intending on creating an open-source library that others will be using to build their software? You can opt for either permissive or copyleft licenses as per your requirements. Most of these software licenses dictate how can or cannot the software be used in commercial applications. You can give rights or not give rights to individuals and companies to use your library in commercial applications along with the restrictions and obligations under which they can be used.
3. Who are your target users?
A lot depends on this question. A multi-enterprise organization with multiple intellectual properties in its applications may not prefer using your library if it implies that they may not be able to keep their code hidden. Or they may even shy away from using your software if it comes with open distribution clauses.
Tooljet is an open-source platform for creating and deploying react-based internal applications. We are AGPL-V3 license certified. Under the current licensing framework you'd be able to deploy Tooljet:
- Within your organization without making any changes
- Use Tooljet with modifications
- Fork Tooljet & create derivative work that is AGPL licensed
Ending Note:
Opting for an open-source license for your software or product may not be as simple as you may have thought, however, it isn’t as difficult either. If you are least bothered about who does what with your code, you may opt for super flexible permissive licenses like the MIT license. You may also consult an expert who may guide you in the right direction. Knowing the basics beforehand, especially the jargon, meanings and intentions - may get you started in the right direction. We hope the guide has been helpful in this regard.
DISCLAIMER: This guide is written with reference purposes only and it is in no way a guide with legal mandates.