When you don’t pay attention to licenses, open source code can entangle your company into a costly lawsuit or make you rewrite the whole product. However, you shouldn't be afraid of licenses but understand how they work and how to comply with each of them. Check if the open sources you use pose a threat to your business and find out what to do today to secure your company for years.
A QUICK SUMMARY – FOR THE BUSY ONES
You don't need to be scared of the restrictive licenses. You just have to be aware that some of the licenses can be an issue and have a basic understanding of how they work. That will allow you to comply accordingly.
The clue of managing licenses is understanding. By that, you manage — and reduce — the risk.
With the growth of a product the number of licenses to follow and pay attention to becomes an issue. What can help you to track licenses inside your code, is the License Auditor tool, which sends notifications after spotting a potential problem.
TABLE OF CONTENTS
This visualization presents about 1600 dependencies that occur every time you set up a new React app.
Each one of them can have a different license.
Tracking them manually is virtually impossible. Not tracking them at all could have legal consequences.
So how can you ensure license compliance and avoid legal risks painlessly?
Grasp the essence and intent of license types and choose a tool to help you manage them.
We explain it below. Let’s dive in.
Let’s start with the fact that every piece of code is licensed. And a license basically means you can use the code if you follow its terms. It defines the responsibilities for those who use and distribute the code.
Most licenses respond to a particular problem and were created because there was a loophole in a system of law.
And your code is full of them. The deeper you go, the more licenses appear.
For example, you install Electron and have to add 87 packages — that means 87 license dependencies. Every single package is likely to have its own dependencies, and therefore, another license you need to comply with.
As you can see, in most cases, license management can’t be done manually and when done incorrectly can create a technical debt.
It’s no different with open source code. It’s a common misunderstanding that it is free to use, but most often the packages are under a specific license. And, of course, you need to avoid breaching it. Otherwise, license litigation may end up with a very costly court suit, or you may need to release your code under the same license as the package dependency you used.
Open source software (OSS) licenses allow developers to share their code with others for free, as open source. They are common for components or libraries.
But every open source license has terms and conditions that tell users what they can or cannot do. A user may be required to publish specific license text when distributing the code. Each piece of software online is licensed, and that means you can’t just copy-paste it into your code base.
The problem with open source software is that there are many contributors and it’s risky to assume the main license is the only one you need to comply with.
A component’s license doesn’t necessarily apply to each file and even each line of code. By that, any component may be dependent on lots of licenses and you won’t be able to identify it without an in-depth investigation. Plus, each type of license means different obligations.
<span class="colorbox1" fs-test-element="box1"><p><strong>Tip:</strong></p><p>If you’re developing a React app and are looking for help, check our list of top React development companies — it’s safe to say those vendors understand the license issues. And here you can find tips on setting up a software development partnership.</p></span>
When someone wants to buy your company or buy your SaaS software, they will look at your license agreement to make sure everything works. After spotting problems during the license audit, the buyer may fall back.
Other potential problems include:
Imagine it happening in a sensitive industry like fintech — that’s why it’s key to work with reliable development partners that understand both the industry and risk, and know how to mitigate it. (Check out our comparison of the best fintech development vendors, if that sounds like your cup of tea.)
In general, the later you discover the problematic dependency, the more costly it will be to resolve this issue.
It’s important to have processes and tooling in place to manage all the dependencies and licenses in your code and to be aware of how various types of licenses work.
<span class="colorbox1" fs-test-element="box1"><p>Tip:<p></p>Prevent the business risk of using open-source licenses easily with the License Auditor – a free tool that tracks and validates licenses in your code.</p></span>
Proprietary licenses – users are provided with operational code and cannot alter the software freely. It’s illegal to copy, modify, or distribute the software. This is the most restrictive license type.
Copyleft licenses – also referred to as reciprocal licenses or viral licenses. They require you to release any code you make under the same copyleft license terms to be able to distribute and modify the code.
Lesser general public licenses – you need to link an LGPL-licensed library with your own code to be able to release your software under any license.
Semi-permissive licenses – these licenses require you to make the code modifications available under the terms of the given license.
Permissive licenses – these licenses have some requirements for distributing and modifying the software, preserving license notices, copyrights or trademarks. The restrictions are minimal.
Public domain – anyone can use, modify or incorporate code from this software into an application. Companies should be careful about the code quality and security standards.
GNU General Public License (GPL) 2.0 – to be able to copy, distribute and modify the software, you need to track changes and dates in source files. Any modifications must be made available under GPL-licensed code.
GNU General Public License (GPL) 3.0 – to be able to copy, distribute and modify the software, you need to track changes and dates in source files. Any modifications must be made available under GPL-licensed code.
GNU Affero General Public License 3.0 or later – you can distribute modified versions if you track the changes and the date when you made them. Like with other GNU licenses, derivatives need to be licensed under AGPL.
GNU Lesser General Public License (LGPL) 2.1 – you may copy, distribute and modify the software if you license the modifications under LGPL-2.1. Anything statically linked to the library can only be redistributed under LGPL. Applications that use the library don’t have to be.
GNU Lesser General Public License (LGPL) 3.0 – you may copy, distribute and modify the software if you license the modifications under LGPL. Modifications or anything statically linked to the library can only be redistributed under LGPL. Applications that use the library don’t have to be.
GNU General Public License (GPL) and and GNU Affero General Public License (AGPL) are the most restrictive open-source licenses.
You need to be careful about a few restrictive licenses, like GPL 3.0 or AGPL. In the worst-case scenario, you may be required to release your software under the same license, royalty-free.
However, we shouldn't say these licenses are bad. They cause a legal risk or can make you rewrite the whole product, but only if you don't follow the rules associated with them.
The key in managing licenses is to understand how they work, follow their rules, and ideally use software that helps to track the licenses in your product, so as not to break the law or cause problems to your product through inattention.
Semi-permissive licenses most often require you to make the code modifications available under the terms of the given license.
Artistic License 2.0 – it allows you to distribute or sell modified versions as long as you maintain access to the original version and publish modifications.
Common Development and Distribution License – you can distribute binaries under a proprietary license, as long as original and modified source code under CDDL is made available.
Microsoft Public License – you need to link the license and existing copyrights to use the software freely. This license can be used only with compatible licenses.
Mozilla Public License (MPL) 1.1 – you need to include a notice in each source file. This license is incompatible with GPL.
Permissive licenses most often require you to keep the copyright notice in place.
Apache License 2.0 – it’s a permissive license that allows you to do what you like with the software, and all you need to do is include required notices.
BSD License 2.0 – you need to include the BSD copyright notice to be able to copy, distribute and modify the code.
Code Project Open License 1.02 – no software can be used for “illegal, immoral or improper purposes”.
ISC License – you need to include the original copyright to be able to use the code freely.
MIT License – that’s one of the most permissive open source licenses. All you need to do is to make sure that you add a copy of the original MIT license and copyright notice to it.
OSS compliance is the process when your team observes copyright notices to meet the requirements of the licenses for every component of their software. To comply, you need to know what open source components are in the codebase.
What to do when you see that you didn’t comply with the license? Most often, you have three options. First one is to simply comply with it (in the case of many licenses it just means you need to add the license file). The second is to eliminate your reliance on this licensed code. And the third is to pay and get an alternate commercial license.
<blockquote><p>There are 300+ OSS licenses, and growing. However, the good news is that around 20 licenses account for 80% of the OSS commonly used in enterprises. So a black/whitelist of these licenses together with a scanning tool already provides a very good starting point in managing them.</p><p>— Debmalya Biswas, Director, Data Analytics & AI at Wipro</p></blockquote>
If you didn’t pay much attention to licenses before, start by focusing your efforts on spotting the most restrictive licenses.
Then it will be crucial to educate your development team – they need to be aware of the risk and the intentions that stand behind licenses. While preparing your process, it’s a good practice to create a white-list and a black-list of licenses.
Since your code is most likely full of deep-hidden licenses, you may want to start using a software license tracking tool to spot the potential problems automatically.
<blockquote><p>License usage seems to be moving to projects shifting to preferring more permissive licenses. However with recent events — like those around Faker (where the author corrupted his own library) and Log4Shell (wide-spread security issue) — I believe we will see either folks going toward more control (like their own corporate OSS licenses, think Amazon and their ElasticSearch fork) or we’ll maybe collectively just have a very hard learning experience. Given that most open source is also exploited and under-paid (if paid at all) we might even see changes to the operating models around how OSS is created in the first place.</p><p>— Mikael Vesavuori, Cloud Software Architect and Technical Standards Lead at Polestar</p></blockquote>
Our developers created a License Auditor tool to help you track and validate licenses inside your project. It helps teams to comply with open-source licenses by sending notifications about potential problems.
You can find the License Auditor here on GitHub.
<blockquote><p>I’ve seen the “headless chicken dance” when companies either are caught with non-compliance or start thinking about it and go bananas, trying to inventory everything without tooling and go locking down usage by misguided opinion or fear.<p></p>Instead, you should help to create oversight with tools and processes to assist in the work and then to automate that in (developer-facing) tooling—where it matters on a day-to-day basis. Also encourage awareness either through training or through exposure, such as having in-house open source projects, something that will help making the license question into a less theoretical issue.</p><p>— Mikael Vesavuori, Cloud Software Architect and Technical Standards Lead at Polestar</p></blockquote>
Open source license compliance may seem intimidating at first, but ultimately all you need to do is to raise awareness and manage the risk.
Start with understanding the intentions behind licenses, and use a software license tracking tool that sends notifications after noticing problems.
Our promise
Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by openly sharing our insights based on practical software engineering experience.
Authors
Software Engineer & Solutions Architect with 15 years of professional experience. Head of Engineering at Brainhub, providing technical leadership to the engineering team.
Software development enthusiast with 6 years of professional experience in the tech industry.
Read next
Popular this month
Get smarter in engineering and leadership in less than 60 seconds.
Join 300+ founders and engineering leaders, and get a weekly newsletter that takes our CEO 5-6 hours to prepare.
previous article in this collection
It's the first one.
