Have you ever stumbled upon a Github repository, looked at its license, and felt lost looking at the complex terminology surrounding the legalities of using and redistributing any of the code or the material on the repository?

Don't worry I've got you covered. Warning: This is a long article with lots of detail.

In this article, we will be breaking down a lot of the jargon and complex details about everything related to Open Source Licenses to decipher how exactly they affect your contributions as an open-source developer.

What does Open Source Licensing mean?

Open-source licensing is like a security contract attached to a piece of software created by you or a third-party company containing rules about how the piece of software can be used or distributed publicly. It acts as a protection for the creator or the company who created a piece of software and is analogous to copyright.

Now, let's deconstruct this in case what I said did not make any sense.

Open source licensing allows the creators of a novel software or a piece of content to have rights to it and establish rules to safeguard themselves from potential bad actors. They are specific instructions that pretty much allow you to be safe and give instructions to other people about how potential users would like to use, contribute back, or re-distribute a piece of content that has been created by you. It is just a way of establishing a secure policy to safeguard your intellectual property while allowing people to contribute and improve it at the same time.

The Hate Against Open Source Licensing

Now, before we forge ahead and cover all of the different complicated types of licenses available for your discretion, let's debunk why there has recently been a lot of hate mainly in the developer's community against open source licenses as a whole.

Before, we get into this complex topic, let's examine the source of this problem.

The Inception of Open Source Software

Open-source software has a rich history that began right after World War II, with the GNU project and the GPL playing pivotal roles in its development. The GPL, a copyleft license created by Richard Stallman, was designed to ensure that software remains free and its users can run, study, share, and modify it. This license has been a cornerstone of the open-source movement since its inception. Despite its historical significance, the open-source community in recent times has been facing significant challenges. Some of the key issues include:

Legal Battles and Changing Landscape

The open-source community has been embroiled in legal disputes, such as the high-profile case between Oracle and Google. Google claims that Oracle has been using its copyright code and is suing them for over $9 billion. These legal conflicts have raised concerns about the potential risks and complexities associated with open-source licenses. This is not the only company who have gotten into the mess related to the open source software, the companies TerraForm, Hashicorp and more have now switched to a SSPL or a BSL license making them pretty much like for-profit open source repositories.

Evolving License Models

Furthermore, the changing landscape of open-source licenses has sparked debate and uncertainty. For example, the decision by companies like HashiCorp and Elastic to transition to a Business Source License (BSL), a purely commercial license with strict usage rules, has raised questions about the traditional "free-to-use" notion of open source software.

Looking Ahead

While these challenges are significant, the open-source community needs to address them proactively. By getting together and brainstorming, exploring alternative license models that are potentially easier to work with, and enforcing greater clarity around legal and licensing issues that are undecipherable right now to the normal human without a lawyer, the community can work towards ensuring the continued growth and success of open-source software.

Types of Open Source Licenses

We will only be covering the most popular and the licenses that should fulfill most of your needs either for your products or the licenses you are most likely to encounter on Github for most repositories as there are over 1000 licenses that are available with over 100 of them being officially approved by the Open Source Initiative.

Permissive vs Copy Left licenses

Before we step ahead and find out about the different types of the most common types of open source licenses used, it is important to understand that open source licenses fall under 2 categories largely, copyleft and permissive. Before we dig into the different types of licenses and their names like MIT, Apache, and so on, and what they mean, we will be covering the 2 categories of open source licenses - Permissive License and CopyLeft License.

1. CopyLeft License :

A CopyLeft License as a license has a ton of licenses under it like the Apache 2.0 license and more which lays down a rule stating that if you use a product's source code or the product itself containing a CopyLeft License, you are "required" to release the product using the same license used by the source code repository without changing it. Some examples of popular licenses under this category are GPL, AGPL, MPL, and more.

1. Permissive License :

This is the type of licensing that allows you to create products without any form of attribution unless explicitly stated and is the most unrestrictive type of license that doesn't require any attribution or copyright mentions—for example: MIT, Apple Public Source License, and more.

Legal Protection For Developers

Open source licenses can help protect developers by allowing them to freely use, modify, and share software code while also granting other users the permission and rights to use or repurpose the code for new applications. These licenses ensure that open-source software developers are protected and that the conditions under which the software can be used are clearly defined. There are many different open-source licenses, but most can be grouped into two categories: permissive and copyleft. Permissive licenses, such as the MIT License and Apache 2.0, allow for more flexibility in how the software can be used and modified, while copyleft licenses, such as the GPL, require that any derivative works also be licensed under the same terms. Ultimately, open-source licenses help developers maintain control of their software and ensure that it is used in a way that aligns with their goals and values.

Types of Popular Open-Source Licenses

Now, we will be entering the main crux of the article and deconstructing exactly the most popular forms of licenses that you can use to determine which license is the best fit for your open-source product.

1. GPL

The GPL or the GNU General Public License is a copy-left license that requires the re-distribution of any IP that the software contains that is public. It has over 3 versions and the latest is the GPL V3 version. It has a few variants inside of it which we will now be discussing.

1.1. LGPL - The Lesser General Public License also known as the LGPL license is a weak-copyleft license. It is mainly used for libraries and doesn't have as many stringent rules in place. The users using this license, need to include a copy of the full license text, make the source code fully available for download, and in general offer the benefits of both permissive and copy-left licenses in general due to their weak copy-left nature.

Some of the software using this license are ARToolKit, Nix package manager, and more.

1.2. AGPL - The Affero GPL or the AGPL License is very similar to the original license except for the fact that the AGPL License considers the network usage as a form of distribution aka the running of an AGPL product inside of a cloud instance on the network and this will require you to comply with the rule of the license which states that your code needs to be openly available for download and include any information about the installation software required to run your product.

Some software using this license are GIT, Notepad++, and more.

1.3. MPL - The MPL License or the Mozilla Public License is a form of copy-left license managed by the Mozilla Foundation that allows you to keep your work as a closed source or in a proprietary form as long as your files being used in the product are separate and these files are re-distributed along with your software.

Some examples of software using this license are ThunderBird, LibreOffice, and more.

1.4. EPL - The EPL or the Eclipse Public license is commonly used for businesses. It is also a weak copy-left license being maintained by the Eclipse Foundation. You are allowed to modify and re-distribute any of the source code of software using this license provided you are willing to make the code available to the user when requested and share the method used for re-distribution. It also requires the end user who uses a product using any EPL code to use the EPL License.

Some examples of software that use this license are Eclipse, Jetty, and more.

1. MIT License [Massachusetts Institute of Technology]

The MIT License is extremely flexible and doesn't have any rules that prevent you from using it. It is a permissive license that does not require any attribution of the software or the source code that is in use whatsoever. It is one of the most popular open source licenses due to its flexibility and permissionless nature that lets you use it as much as possible without any restrictions but you are required to include the MIT license in your product and make it available under it as well.

Some software using this license are all of the popular frameworks the Javascript programming language like React, Angular, Vue, NodeJS, and more.

1. Apache License

The Apache License in general tends to lie in the middle of the GPL and MIT license in terms of its rules of re-distribution and usage. It allows users to download, modify, and re-distribute any software products that were created with this license provided the license is included in the product. This license is not a copy-left license but, it will require your software product to be licensed under the Apache License strictly and there is a requirement of sufficiently attributing any form of code / IP used in your product individually to the source inside of the product and the latest version of this license is the Apache License 2.0 which includes patent rights for users and more. Finally, this license provides protection mainly to users of the software against claims of their patent.

Some examples of Apache license software are Apache Kafka, Kubernetes, and more.

1. BSD License

The BSD License or the Berkeley Software Distribution License [BSD] is a permissive license. These licenses in general place very low restrictions on how users can use and re-distribute software built on it and is a permissive license. And, compared to the MIT license, it pretty much is similar to it except for the fact that you cannot promote your product by mentioning that it uses the "BSD" license. The BSD license doesn't need any attribution for any form of code changes / IP as compared to the Apache license and it works well with the other licenses in general.

The BSD License has a lot of types under it and the original BSD License is known as the 4-clause License which includes some restrictions around attributing the authors and an advertisement clause for endorsements.

Over time, this license has evolved and given rise to the 3-clause License, or the New BSD License, and the 2-clause, or the Simplified BSD License.

The modified BSD License or the 3-clause license is the same as the 2-clause license but with an additional clause that prohibits the usage of the names of the authors for any form of endorsement purposes but the 2-clause license or the Simplified BSD License is the simplest form of the BSD License which can be used to copy and distribute modified source or binary forms of the licensed program and does not impose any redistribution of the code and has also removed the non-endorsement clause and is finally fully free to use and highly permissive.

Some examples of software built on the BSD License include Google Bionic, Toybox, and more.

1. Creative Commons License [CC]

The Creative Commons License is used for more forms of open content other than code like artwork, photographs, books, and also documentation. This license allows people to use your copywritten work without your contact and lets others re-build, change, and re-distribute your work in a commercial form as well. There are 6 types of ways this license defines how you can re-distribute and use the work that has been attributed with this license which are,

5.1. CC BY [Attribution]: This gives users the permission to distribute, re-iterate, and build on the material that has been initially created with this type of license at a commercial scale provided the original user is given attribution.

5.2. CC BY-SA [Attribution-ShareALike]: This license allows users to remix, adapt, and build upon your work even for commercial purposes as long as the new work is licensed under identical terms and the due credit is given to the creator of the IP.

5.3. CC BY-NC [Attribution-NonCommerical]: This license allows users to distribute and build upon the source only for "non-commercial" purposes and is required to provide enough credit to the original user.

5.4. CC BY-ND [Attribution-NoDerivatives]: This license allows the end user to re-distribute your content both commercial and non-commercially as long as it is not edited or modified in any manner with enough due credit to the original creator.

5.5. CC BY-NC-SA [Attribution-NonCommerical-ShareAlike]: This license allows others to readapt and distribute your work non-commercially as long as they provide enough credits to the original creator and license their new work under identical terms in a non-commercial manner.

5.6. CC BY-NC-ND [Attribution-NonCommerical-NoDerivs]: This is the most restrictive out of the 6 types of the Creative Commons license that allows others to distribute and share your work as long as your work gets credited enough but, the end users are required to not modify your original piece of content and use it in a non-commercial way.

Examples of pieces of software using the CC License are InkScape, AssaultCube, and more.

1. BSL License [The cause for HashiCorp's controversy]

The BSL License or the Business Source License is a non-open source license that in general provides a middle ground between open source and proprietary license. It is designed to mainly help companies to get paid for developing software that is open source by allowing them to continue creating their products with a commercial license for a limited time which is a window allowing the open source company to collect revenue after which they will be making the work open source. This license offers a way for developers to continue delivering usable features and products while gaining revenue.

This license is extremely controversial and it is mainly seen as a fix to the problem of open-source products in general not making any kind of revenue.

Some software products using this license are MariaDB, Hashicorp, CockroachDB, and more.

1. SSPL License [The cause for Elastic Search's controversy]

The SSPL License, first released by MongoDB also known as the Server-Side Public License is designed to mainly address a "loophole" in the traditional open-source licensing model where cloud providers can offer managed services that are based on open-source software without contributing anything back to the community [looking at you AWS].

This license requires companies to also open-source their code if they are using a piece of software that is listed under this license and is in general very restrictive and is a copy-left license.

In the case of Elastic Search and MongoDB [who introduced this], this license mainly heavily restricts you from forking and using their products for profit and also has a lot of legalities around contributing to their products.

Some software products built on this license are MongoDB, Elastic Search, and more.

Best Practices of Working with Open-Source Software

It is crucial for both developers and users who work and create derivatives of open-source products to follow the licensing guidelines before they start contributing/creating from/profiting from the software that is out there in an open-source form.

This is necessary to ensure that you aren't faced with any legal/compliance problems that can potentially cause a cease-and-desist in the worst case against you or have your name tarnished in the open source community.

Here are some of the steps that you can take -

1. View and Understand the License : Every open source repository for the most part has a license that contains all of the terms and conditions required to be followed for any form of re-distribution or reproduction of the IP.

2. Provide Due Credit : Some types of open source licenses like the Apache 2.0 license for example require users or developers to provide credit for any IP that includes code, content, and more which is to be strictly followed along with re-distributing your software if required.

3. OpenSourcing your Changes : A lot of copy-left licenses require you to make your derivative code changes and product changes to be open source under the same license as well which is to be adhered to like the GPL license.

4. Infringement of Trademarks : Most open-source software does not allow you to perform any form of trademark/copyright infringement which is strictly against the rules and this is to be followed very strictly as it can lead to things like copyright infringement and more which is a serious crime.

5. Iterate on the Compliance : Regularly, make sure to review the existing compliance requirements to be followed by the source open source software which is subject to change. Some tools that can help follow the compliance guidelines are SenerNow, AD Audit Plus, and more.

6. Establishing Solid Open Source Policies : It proves to be beneficiary for both individual companies and businesses to establish extremely clear guidelines and rules about the usage of your own intellectual property or products created for the end users instead of leaving them in the dark and having to deal with a lot of issues related to legalities.

Choosing an Open-source License

Now, we will be discussing some of the best practices for choosing the correct open-source license which this article has mentioned about already for your software product.

At this point, you get to decide how exactly you want your software to be used by users. If you do not care how they use it and do not require them to attribute it, you will be better off publishing it under a permissive license like MIT or a permissive license with a few restrictions like Apache 2.0 and more. However, if you want any attribution for any form of your content, if it is like an image or a piece of content which often is not code, you will be better off publishing it under the Creative Commons License or if you want to restrict its usage and give you enough credits, you can use any of the copy-left licenses like the GPL License and more.

Now, many of you will be wondering why even bother to set a license for your code repository, but, it is crucial to have a license in place for your coding products or any form of content you have with guidelines enforced based on your requirements to prevent IP theft and copyright infringement. And, setting up a license safeguards your users as well from potential takedowns / cease-and-desists and more, read more about this here. Therefore, you are doing your users and yourself a favor by adding a license to your Intellectual Property and clarifying any terms or rules that are to be followed when contributing to or productizing your IP.

You can also find a lot more about choosing the right open-source license using Snyk, Choose A License, FOSSA, SPDX, Revenera, and more.

Conclusion

Open source licensing is one area that is legally very important and can provide a lot of protection to both the end users and creators of intellectual property that can include sophisticated content like code, videos, books, or simple content like books.

Understanding open-source licenses will take you one step closer to being a much more responsible member of the open-source community and I hope that this article has given you enough details about how Open source licensing works.

Good Reads after this article

1. https://www.infoworld.com/article/3703768/the-open-source-licensing-war-is-over.html

2. https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license

3. https://www.mongodb.com/legal/licensing/server-side-public-license/faq

4. https://www.elastic.co/blog/elastic-and-amazon-reach-agreement-on-trademark-infringement-lawsuit

5. https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc.#:~:text=verdict%20was%20proper.-,Decision,Breyer%20wrote%20the%20majority%20opinion.

6. https://snyk.io/learn/open-source-licenses/

7. https://opensource.org/