You don’t need us to tell you that open source software is becoming a very significant percentage of commercial software codebases. Open source components are free, stable, and enable you to focus your resources on the innovative and differentiated aspects of your work. But as the use of open source components increases, compliance with open source licenses has become a complex project of growing importance. So how can you stay on top of compliance and what tools are out there to help?
If you’re completely new to managing open source license compliance, you have four major things to create for your company: a formal policy for the use of open source licensed code in your organization, an inventory of open source components currently in use, a plan to replace any open source code that isn’t meeting your policies, and an attribution document. It’s no small feat but it’s perfectly doable. Let’s get into each item in a bit more detail and then go over some tools to help you continuously manage open source licenses.
With millions of open source projects and over 200 open source licenses in use, open source compliance can seem like a herculean task. In practice it’s very manageable and it’s a task you shouldn’t put off. Just 8 licenses cover over 98 percent of all open source projects, which tremendously narrows your focus. Even so, it’s important to define a repeatable process to handle new open source packages coming into your projects. This is where your open source compliance policy comes in.
An open source license policy defines which open source licensed packages can and cannot be used and what the approval process will be for any code falling under other licenses or in special cases. Crafting this policy needs to involve both your engineering and legal teams, but it’s not a bad idea to get your security team in the mix as well so you can set policies for open source package vulnerabilities at the same time. If you’re only just getting started, however, just stick with open source licenses. We have put together some advice on creating your open source policy template to help you make sure your first draft covers all basic requirements.
At minimum, your open source policy will need to define:
1. An allow list of approved open source licenses that can always be used
2. A deny list of open source licenses that can never be used
3. An approval process for all other licenses
There are over 200 open source licenses out there but only a few more than 70 are approved by the Open Source Initiative (OSI), so start there and take into account that you will not be able to cover all licenses with your policy.
Remember: there are no inherently good or bad licenses, just ones that will or won’t work for your company, business model, and particular goals for a particular project. From the standpoint of proprietary software products, copyleft licenses like those in the GPL family are a big problem as they require companies to open source their entire code. On the other hand, if you’re simply creating software for internal use, as in code that will never be distributed to the public, most copyleft licenses are no problem at all. And don’t make the mistake of thinking anything that’s not copyleft is safe; even licenses that are considered permissive and business-friendly may have restrictions on patents or compatibility with other open source licenses that can cause trouble for your projects.
To gain more understanding on different open source licenses and requirements for adding copyrights and notices, we highly recommend you check out The Linux Foundation’s free online course: Open Source Licensing Basics for Software Developers.
This is part of an extensive series of guides about Compliance Management.
Now that you have an open source license compliance policy drafted and in place, it’s time to figure out which open source components (and the licenses they fall under) are already in your software.
You’ll need to figure out if a manual tracking process is worth your time (or is even possible) or if an automated solution would best suit your company’s needs. We’re a little biased, but here’s why we (and Forrester) believe that no software company with more than 20 developers can reasonably settle for a manual process.
Your end goal is to have an inventory of every open source component and their respective licenses. Whether you choose an automated tracking process or not, it’s vital that you are also able to produce an inventory report that includes all dependencies, as a dependency may fall under a different license than the parent library you are more directly using but you are still obligated to comply with that dependency’s license.
Once you’ve chosen your preferred method of tracking your open source usage, you will need to generate an open source inventory report to see which components fall under your allow list and are of no concern, and which fall under your denylist and require action. With this report you will also need to identify any open source components that do not actually have an open source license. It may sound strange but many projects that claim to be open source don’t carry any kind of license at all, which basically makes them not open source and therefore still protected by default copyright laws.
Now that you have a list of all open source packages licensed under your deny list, you can work with engineering and make a plan to replace all troublesome components. Then you can attend to the questionable licenses that are in neither your allowlist nor denylist and make a plan for those components as well.
How large or complicated the job of replacing all noncompliant components will be is dependent on your engineering team, your codebase, and what you uncover in your open source inventory report, but it is a fairly straightforward goal and a necessary one at that.
You’re almost there but don’t put your feet up just yet. Once you have taken inventory of all open source components and licenses in your software and processed everything based on your open source license compliance policy, you are likely to need to prepare an attribution document. Most open source licenses contain some kind of an attribution clause. Compliance with these clauses generally takes the form of an attribution document which includes a list of copyrights, notices, and licenses.
Now that you have a policy, an inventory, an attribution document, and your current codebase is compliant with all open source licenses involved, you need an approach for applying your policy to new components added to your software and how to manage your approval process. Below we’ve created a list of open source compliance tools that can help you and your team based on your preferred tracking method.
The most basic approach is to manually track your open source software components with spreadsheets or ticketing software. The attractiveness of this is that it takes practically no work to set up and requires no overhead or customizing of additional tools.
If you decide to use this method you will need to be diligent and have policies in place for how license information about new open source code will be added to your inventory list as your project grows and who is responsible for making sure that information is added.
If you are using a very small number of open source libraries then it’s probably sufficient for tracking your usage, but it won’t scale easily as your software and the open source code within it grows. Although still a popular approach, due to increased awareness of scaleable, affordable automated solutions, like Mend.io’s, many companies are moving away from this method.
A step above a spreadsheet, several open source tools exist to help to automate a part of the process of manually tracking. You can find a list of these tools here, but the best known and most advanced is FOSSology, a project started by Hewlett-Packard and now hosted by The Linux Foundation.
FOSSology scans the headers of files in your project and detects text from open source licenses. This offers significant automation over basic manual tracking and can find open source components that were not tracked by developers. The main drawback to using FOSSology is that it is likely to suffer from many false negatives – if a file doesn’t have a license referenced in the header file, that license or, just as importantly, lack of license, will not be detected.
The bulk of commercial open source management tools, including Black Duck Software, Palamida, OpenLogic, and Synopsis, fall into the category of periodical code scanners. These tools scan your entire codebase looking for snippets of open source code and determine what licenses they fall under. Given there are billions of open source components out there, the odds that two unrelated snippets of code may incidentally match are high, causing a large volume of false positives that you will need to sort through when using these types of tools. Another downside is that these code scanners are not agile. You will only know about your open source license vulnerabilities when you perform a scan of your entire codebase. Scans can take a significant amount of time and will need to be repeated as you add more open source code. Even those companies still using waterfall methods can find these scanners causing bottlenecks in their development pipeline.
Continuous integration scanners offer an automated solution to both tracking and managing the open source components in your software. These tools provide accurate and detailed information and remove the need for developers to manually take account of each newly added component. This is the approach provided by Mend.io. Our tool additionally automates tracking and managing security vulnerabilities, software bugs, versions, and more, but for now, let’s stay within the scope of this blog and focus on licenses.
As the name suggests, this type of scanner fits right into your continuous integration or build tools (such as Jenkins, Maven, or Ant) and automatically detects all open source components in your build every time you run them – likely multiple times per day. It works by calculating a unique identifier for each library you use and then cross references with its database to detect the open source libraries. With this approach you get constant feedback about your open source libraries and their licenses, without the false positives, giving you the information you need to react in an immediate and agile way when there is conflict with your open source policy. You can even set an automated policy that will approve, reject, or send a request for approval based on your rules – even breaking the build if a blacklist license is used.
This technology automates the entire process – from automatically enforcing your policy, to managing the approval process, all the way up to automatically creating the attribution document. Once you’ve set up a continuous integration scanner with your policy, much of the rest of your job is done for you, increasing your accuracy and releasing your developers from time consuming bureaucracy.
Different organizations have different needs and there are tools out there for everyone. To determine what’s right for you, you will need to take a good look at the size of your project, your development methodology, the liabilities for missed compliance, and the cost of swapping out an open source component if its license doesn’t match your open source policy.
For very small projects manual tracking can be sufficient. More complex projects, particularly those built inside of an agile organization and released on a frequent schedule, benefit from continuous detection of open source components.
The growing use of open source code in enterprise software shows that the benefits of using open source code clearly outweighs the cost of compliance. With the continuing development of modern tools for open source license management, it’s easier than ever to integrate smart and streamlined development processes and stay compliant.
Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of compliance management.
Authored by Stoke
Authored by Stoke