Have You Been Following License Compliance Guidelines?

Most of our tasks as software developers are centered on the technical aspects of the job. We code. We test for bugs and security vulnerabilities. We ensure the most efficient CI/CD workflow.

However, we must also be conscious of our legal responsibilities when coding. 

Using Open Source Code #


Photo by Nate Grant on Unsplash

One of the luxuries presented to us nowadays is having open source packages. These packages allow us to abstract features for our apps that we may consider trivial relative to what we want to build. For example, if we were building an application that allows patients to book appointments with therapists, we wouldn’t concern ourselves too much about building our own calendar feature. We’d simply search for calendar packages in open-source hubs such as npm.

We just type a command in the terminal or include a reference to such packages in our project’s module files (such as a Gemfile or package.json file). Magically, we get the functionality someone else created into our project.

Such convenience is often taken for granted. While we probably have more consciousness of vulnerabilities, we never really look into license-related matters for these open source packages.

We assume that since it’s open-source, we’re free from any legal responsibility. After all, open-source means free, right?

Different Types Of Open Source Licenses #

There are two general categories of open source licenses.

Copyleft #

Very simply, if a software has a copyleft license, you are free to use, modify and redistribute it. However, the condition for such is that any modified or redistributed versions should have the same permissions. You can think of copyleft in the context of copyright. With a copyright, the creator requires attribution should somebody else use the product and may require compensation for reproduction and modification.

Permissive #

Permissive license, on the other hand, is very different from copyleft. You are free to use, modify or redistribute the software with this license without anything required of you.

With these two categories in mind, let us now understand the different kinds of licenses for open-source packages we will often encounter as developers.

There is actually a third category: the Public Domain, which, for the lack of a better term, is license-free. It doesn’t mean it doesn’t have any license. But essentially, users of such software under the Public Domain can do anything they want with it without any major legal repercussions.

GNU General Public License (GPL) #

One of the most well-known copyleft licenses, GPL, was designed by Richard Stallman to ensure that any software with this license will never be proprietary. Any software that uses open source packages with a GPL is required to have its complete source code released along with permissions to modify and redistribute it.

Apache License #

This license was created by the Apache Software Foundation (ASF). It is a permissive type of license where the user can use, modify, reproduce and redistribute any Apache software without any required attribution or compensation to the foundation. While it’s meant explicitly for ASF projects, it’s also been used for non-ASF ones.

Microsoft Public Licenses #

The Ms-PL license is another permissive type of license. Any user can use, reproduce, modify or redistribute any software with this license. The only requirement? You may not include the originator’s name or trademarks in the reproduced/modified/redistributed version.

Berkeley Software Distribution (BSD) #

BSD licenses allow anybody to use, modify, reproduce, and redistribute the software’s source code as long as such a user will retain the original copyright statement and disclaimer. Another requirement is that the reproduced/redistributed version doesn’t mention the name of the software. This is to free the original creator of any liability arising from the modified version.

Common Development and Distribution License #

The company Sun Microsystems created the CDDL based on the Mozilla Public License (MPL). Like the BSD, you can use, reproduce, modify and redistribute any software with this license, but you need to retain the original copyright and disclaimer notices. The difference with the BSD is that with the CDDL, you need to include any attribution to the software’s original creator.

Eclipse Public License #

The EPL, created by the Eclipse Foundation, is a copyleft license. As such, there are several requirements to users of any software licensed under it. Any reproduced/modified/redistributed version or any derived software using an EPL-licensed open-source package is required to disclose its source code and explicitly inform its own users that the source code is available and how to obtain such source code.

MIT License #

The MIT License perhaps is the simplest among the list. Any use of software under this license can use, modify, reproduce or redistribute it provided the original copyright is included. Perhaps this is what you will mostly encounter with any open-source package you use for your projects.

Why We Need To Care About Licenses #

We don’t need to be attorneys or have legal consultants whenever we try to use third-party packages. However, understanding what license such a third-party package falls under will help us include any documentation into our projects. For instance, in our project’s Github repository, we can consist of the required copyright and disclaimer notices if we use an Apache Licensed open-source code.

It’s that simple.

Now, why do we even need to bother? What if we fail to follow any guideline required by the license an open-source code we used stated? If you can remember, back in 2017, Facebook changed its license for React from a combination of BSD plus some patents into a plain MIT one. Imagine if Facebook hadn’t done that. React is a widely-used library, and if you ever had used it in such a time when it was under a more restrictive license, you’d have to lawyer up should Facebook claim any economic compensation from your project.

Such a scenario is not usual for open source code (Facebook faced some severe backlash for such a very restrictive license). However, we always want to be compliant with anything we do. We don’t want to be negligent and then worry about the consequences later. Technical debt is something we minimize. Why don’t we also do the same for legal debt?

How Can We Ensure Proper Compliance? #

The best possible way to ensure compliance with any open-source licenses is for you to be aware of precisely what you’re using in your codebase. If you’re working on a project by yourself, this may be tedious but doable. But if you’re collaborating with others (say, you open-sourced your project), then this may be a bit trickier to do.

Regardless of how you are building your project, you may use a Software Composition Analysis tool, which automatically does the tedious part for you.

There are already a few in the market that we can use, like Snyk or Fossology. I prefer WhiteSource Bolt because it is a free tool that scans your codebase during the build process to ensure your project is free from vulnerabilities, bugs, and of course if it’s license compliant. It has access to a comprehensive database of open-source packages. This then allows you to feel safe that your codebase fulfills any licensure requirement.

In Conclusion #

I hope you now have a better understanding of open source licenses and how you can be compliant. What’s great for us is we have tools such as WhiteSource Bolt, which helps us with this. This, however, doesn’t excuse us for being ignorant of what we should include in our application source code.

 
2
Kudos
 
2
Kudos

Now read this

Should I Automate This Test Case?

Photo by Christina Morillo on Pexels. Introduction # Software testing is a process of checking whether a program fulfills requirements. It ensures and checks if there are errors, gaps, or missing conditions compared to actual conditions.... Continue →