open source licenseNow and then, there comes an outpouring of community uproar over a controversial popular product that uses open source licensing. When such a product comes around, it brings with it a groundswell of debate as to what open-source licenses are really for. One such recent incident took place last year when the Apache Foundation put a ban on some components of the Facebook React’s patent clause. This contentious patent clause caused quite a stir and had developers buzzing on the message boards. 

Even more recently, MongoDB and Redis Labs have decided to make some changes to the open-source licenses in some of their most popular open-source databases. These changes have left many scratching their heads, while others are calling for an explanation of open-source licenses that everyone can understand. 

What is an Open Source License?

In the simplest sense, an open-source license is a legal and binding contract between the author of a software component and the user of that same component. This agreement declares that the software is available for use in most commercial applications as long as its use meets certain conditions. 

The license is the process that turns lines of code into an open-source component. If the software lacks an open-source license, the component is not usable (legally) by others. This applies even if the software has been posted on an open community such as GitHub. Without a license, the software is unusable. 

Each individual open source license will state what the user is allowed to do with the software. It will also specify any obligation and what is not acceptable under the terms and conditions of the license. This may sound relatively straightforward so far; however, there are over 200 different open source licenses available. It becomes quite tricky when you start to delve into all of the various options. 

Each license will vary in its requirements and complexity. It is the job of the publishing organization to choose the license that is most compatible with their software policies, which will ensure that they stay compliant. 

Copyleft and Permissive Licenses

The two most commonly used open-source licenses can be somewhat in-depth and require their explanation. Generally speaking, an open-source license can be divided into two different categories: copyleft licenses and permissive licenses (such as MIT License). The division takes place due to the requirements and limitations that the license serves to place on its users. 

The fundamental copyright law will restrict the right to use, share, or modify and creative works without the express permission of the copyright holder. This copyright restriction usually serves to protect movies and music as the intellectual property of the one who created them. When a creator releases a software program to the general public using a copyright license, they are making a claim to the same restrictions. 

They are making a statement that other parties can share, use, or modify their work under the restriction that the reciprocity of obligation is upheld. This means that if they are utilizing a competent under the open-source license, they must make their projects available to the public under the same license. 

On the other hand, a permissive license is a type of non-copyleft open-source license that provides users with the freedom to redistribute, use, or modify the source and also allows any proprietary derivative creations. These permissive licenses are often referred to as the “anything goes” license due to the lack of restrictions that it places on the source components and their ability to be reused. 

The permissive license gives users a great degree of freedom to redistribute, use, or modify the code. It does not require any additional obligations or reciprocity in the future.

Default Licenses 

In many jurisdictions, any content or code is copyrighted automatically when the author creates it. This means that unless otherwise stated, all rights remain reserved by the author. Of course, it is always a good practice to declare the author and copyright date in the header of the document or code. Still, it is also implied in most cases. Failing to provide the header copyright does not void any of their author’s inherent rights. 

If an author chooses to make their code or content available on a Github repository or their website, they can do so with or without a stated license. They will maintain both usage rights and distribution rights for that content, even though it is something very basic or available for download. 

If you were to execute that code on your computer, then you would be going against the author’s implied usage rights. If so desired, that author has the ability to bring a civil lawsuit against that user, since they never granted them the right to use their authored code.

In the same fashion, if you were to make a copy of that same code and sell it, post it online, or even give it to a friend, you will also be going against the author’s distribution right and could potentially face a civil suit. 

OSI-approved Licenses

The Open Source Initiative or OSI is an organization that has created and maintains a lengthy list of all of the open-source licenses available. All of the licenses on this list comply with OSI’s accepted definition of “open source.” Their definition is a license that allows the software to be shared, modified, or used freely, without any repercussions. 

Many licenses tend to overlap with each other and many confusing licenses that probably should have never been created in the first place. However, any licenses that are on this list have become popular or used frequently enough to go through the OSI approval process and make the list. 

Trying to navigate the waters of open source licenses can be quite confusing, if not entirely frustrating. If you are looking to license your code or content, a great place to start would be to browse the list of OSI approved licenses. From there, you can narrow your search and eventually choose the license that is best for your project.