& Continuous Learning

During my career, I've worked at various organizations that had different stances toward open source frameworks and tools. Some of these organizations absolutely did not want  anything open source near their code base. Others had a small set of "blessed" open source frameworks we were allowed to use. Some of the better places I've encountered, had a process for approving and documenting the use of new open source libraries in the code base.

The reason for this is that organizations tend to recognize that using an open source library comes with a certain amount of risk. Their goal is to manage the amount of risk they are taking on while developing software. The risk of using an open source library usually stems from the license of the library.

The 6 Concerns

Let's consider the following scenario:

• I'm developing a software called Indigo
• A partner is paying for the development of Indigo
• Indigo will be used by the partner's customers
• I want Indigo to utilize an open source framework called Trendy

In this post, I want to focus on 6 concerns that I need to investigate before using an OSS (Open Source Software) like Trendy. Before I go into the concerns, where can I find Trendy's license? Usually, there would be a file called LICENSE.txt or LICENSE in the distribution of Trendy, on Trendy's website, and/or in Trendy's code repository. If an OSS does not have a license, then chances are that it's only copyrighted. This situation is called No License.

1. Modification

Does Trendy's license allow me to make modifications? Consider a situation where I found a bug in Trendy but Trendy is no longer maintained by its developers. Furthermore, let's say that my only option is to fix the bug myself.

So I go ahead and download the source code of Trendy, make the fix and build a new release of Trendy on my local machine. Now, I can use the fixed Trendy in my project. But hold on, am I even allowed to do that?

If Trendy's license does not allow modifications, I might be breaking the law because Trendy's license is a legal agreement between me and Trendy's owners. Any modification to Trendy's source code would be considered a violation of the license.

Hence, I prefer to use an OSS that allows modification.

2. Private Use

Let's assume that Trendy's license allows modifications, so I go ahead and make changes. My changes might give Indigo some competitive advantage over its competitors, or I don't want to share my work with the world.

Now the question is am I allowed to keep my changes private? In other words, I want to use my changes as a basis for creating a new edition of Trendy that Indigo alone uses. Can I do that?

This scenario is called private use and I need to make sure that Trendy's license allows that. Moreover, building Indigo itself and not releasing Indigo's source code could also be considered as private use.

3. Commercial Use

This is the most common scenario for partners who want to charge its customers for using Indigo. Whether it's via a subscription model or a one-time purchase of Indigo, this is considered a commercial use.

This concern has a bigger reach because I must check the license of every OSS that Indigo uses, and make sure they all allow commercial use.

If I'm using 10 OSS's, but one does not grant the right of commercial use, then I'm doomed. My partner cannot charge its customers for using Indigo. My only option at that point is to find a replacement for that one OSS, and that replacement needs to allow commercial use. Then go through all that code, and change it to use the new OSS.

4. Liability

If we find a major bug in Trendy that caused Indigo to leak sensitive customer information, can my partner hold Trendy's owners liable for that?

This should be an extremely rare occurrence, but with security becoming the number one headache for companies, we definitely don't want to take any chances. In most cases, Trendy will be a small framework with little impact. But if it's used in a critical functionality, we need to be extra careful.

Actually, most OSS licenses have a clause that will exempt owners from liability. Hence, if you really have to use Trendy in a security-sensitive functionality, you need to thoroughly vet Trendy, and make sure it has a solid track record with security.

5. Disclose Source

Am I required to disclose Indigo's source code if I'm using Trendy? If I've changed Trendy, am I required to disclose those changes? Disclosing the source means making the binary and the source code available to the public. This could be one of the biggest reasons as to why organizations fear General Public License (GPL) and Lesser General Public License (LPGL). If Trendy was distributed under GPL, then the whole source code of Indigo will need to be made public. If Trendy is under LGPL, then only modifications and enhancements to Trendy will need to be public.

6. State Changes

If I've forked Trendy and made significant changes to it, am I required to state what those changes were?

I think this one is very self explanatory. If the license says changes need to be declared, then I must state the changes.

Easy Guide

There is a large number of licenses out there in the wild. The Open Source Initiative list of licenses can give you a glimpse of that number. Luckily, there is a small number of very popular licenses that you're more likely to encounter like Apache License v2, GPL, LGPL, MIT License, etc.

The good people of Github have created the Choose a License website that tries to demystify licenses. They put together a comparison of 10 licenses with respect to certain issues and concerns that are most relevant. Even though the website is catered to developers wanting to release their own "Trendy" framework to the world, it is very handy to "Indigo" developers too.