Open Source License Management Tools: Challenges, Opportunities, and What to Look Out For
Table of Contents
The scale of the challenge for open source license management
More and more companies are using more and more open source. The stats I’ve seen say seventy to seventy-five percent of all applications use open source or have some type of open source associated with them. I think that number is actually higher. Of all the companies that I’ve worked for, just about every single application has some type of open source associated with it. And the more you use, the more this multiplies because each piece of open source has components and these components have dependencies.
The proliferation gathers pace as it progresses. For instance, you may take two or three open source libraries and apply them to your application. But underneath the covers, you may have multiple open source libraries associated with them. If you’re doing something like a simple file upload, you may only have one or two sub-dependencies, but if you’re doing something more complex, such as with languages like Angular, you could easily have thirty or forty, and the thing that you have to contend with is not only whether your direct dependencies are using indirect dependencies, but whether there could be indirect dependencies in other tools. So, it could grow to hundreds in certain circumstances.
Plus, when you’re looking for an open source library to plug into your application, it’s not necessarily clear what all the licensing models are that are associated with it. A library might follow the MIT model, and you think you’re safe, but a transitive dependency could be hidden beneath the surface that’s A GPL, which has a different set of challenges that need to be managed. It can therefore be quite a drill-down for a license management tool to cover everything.
Challenges and opportunities of open source licensing
There’s a push-pull dynamic between developers and their companies’ needs. Developers use open source code and the capabilities it brings to build new applications. Understandably they’re enthusiastic about this, and about the principle of open-sourcing their own applications.
However, companies realize that they need to protect some of their output. They don’t necessarily want total permissiveness within their environment because they don’t want to have to open source their systems completely. But licensing restrictions discourage sharing and adaptation of developers’ libraries, however amazing they are, so they seek to use less restrictive licenses like MIT, BSD, or Apache. That’s where the multi-license model comes in, to try and reconcile the differing terms and conditions of various licenses. Consequently, more companies have become aware of the need to follow multiple licenses and the multi-license model.
Developers’ priority has always been productivity rather than licensing and compliance. In my thirty years of running teams writing software, licensing wasn’t our concern beyond knowing we didn’t want to use anything super-restrictive. I’ve been through numerous mergers and acquisitions, and it was amazing to see the kind of freedom that developers had. When they found a library they needed, they simply took it and used it.
Even when performing due diligence, the focus was traditionally on security rather than licensing. Teams wanted to know if they were creating a risk by deploying applications and if there are any vulnerabilities that could expose the company to threats. Licensing was an issue for the legal department.
What happens when you don’t take care of your licensing? The Linksys router story
The following story is a great example of why companies must take care of licensing. Back in the 1990s, Linksys produced an effective, inexpensive, and hugely popular router, the WRT54G. By 2003, Andrew Miklas, a contributor to the Linux kernel email list, noticed that the router’s firmware used software based on Linux. Under the terms of use, Linksys — now owned by Cisco — had to release the firmware’s source code.
An unforeseen result of making the source code available was that people could modify the firmware themselves and change the router’s capacity and usage in ways that the company hadn’t anticipated. Cisco found itself selling cheap hardware with capabilities that far outstripped its price point. It released an “upgrade” with its own proprietary firmware, limited RAM and storage, which would make it difficult to replace the firmware with third-party versions, but unsurprisingly, users weren’t happy, and eventually, it re-released a Linux version of the router, with the original specifications.
Do some industries take licensing more seriously than others?
Corporations that handle obviously sensitive information, such as patients’ electronic health record systems or financial records, take licensing issues very seriously. Also, any government organizations and those that provide critical infrastructure, like the power grid. But I think there’s increasing awareness across the board.
That’s because if you open-source your software, you’re potentially giving everybody the keys to the kingdom, your source code. Hackers realize that they can inject malicious code, recompile it, make it look like the original, and work like the original, and nobody’s going to know. And with access to source code, they can manipulate your environment, the administration, the privileges, and the access you have set up, so they can infiltrate and cause havoc at the source. The risks manifest themselves primarily in vulnerabilities that enable hackers to disable, steal or manipulate data, money, assets, and more.
The toughest challenge for open source license management
With this in mind, it’s critical to know what you have in your open source libraries and ensure they aren’t exposed. Know what you have in production and understand what your risks are. Technically, what’s in development and not yet in production, doesn’t need such strict due diligence. However, once you put it out there for people to use, it’ll become obvious what libraries are being used, and whether you followed the terms of usage. Furthermore, and perhaps even tougher, is not only knowing what licenses are in your environment, but also anticipating what the impact of those licenses might be.
How to address this challenge?
You need a license management tool that gives you comprehensive visibility. For example, a tool like Mend will tell you that you have a GPLv3 component in your codebase. You can go into the tool and see the usage details in the form of the actual license text. A screen tells you what the copyright risk score is, and the details around it, so you have an idea of the impact of your redistribution of this component. It tells you if there are patent or royalty risks assigned to some of your open source libraries, which require payments and which are royalty-free, for instance, and we give you the copyleft detail. Risk is shown in an easy-to-understand traffic light system, so you can tell at a glance what might be problematic and what to avoid to prevent legal problems.
Which types of licenses present the most serious risks?
Risks differ based on the context in which software is used and how it’s intended to be used. So, it’s hard to say what are generally the worst licenses. Mend helps by showing the licenses you should avoid in red, directly on the dashboard.
If I were to advise avoiding one particular license, it would be GPL. That’s because it’s copyleft, you have to disclose your source every time, you have to provide your license and copyright notices, and in some of the licensing models out there, you have to disclose what libraries you’re using. Sometimes you even have to acknowledge your application in a file publicly, to show that you’re following the licensing model precisely.
That’s very transparent, but it also can leave you exposed.
What should you look for in an open source license management tool?
Your open source license management tool should be:
Comprehensive. Does it tell you exactly which licenses are being used when you’re creating an application? It’s important to have a system that tells what are both your direct and transitive dependencies because you need to know the entire scope of your licensing and vulnerabilities.
Clear. Your tool should clearly report all the details about your code base. Mend’s risk report shows you precisely what licenses are attached to a project. It tells you what your risk is at a glance, and it shows you exactly what license conditions you must comply with.
Fast and seamless. Developers must ensure that FOSS (free and open source software) goes through the QA process before plugging it into their application. If a tool gives you all the details about the libraries you’re using in a report, you can simply give it to the approving team, so they can make decisions more quickly about which licenses you can use.
Easy to use and understand. It sounds obvious but an open source licensing tool can only be effective if most or all of its potential users within an organization actually use it. So, it should be easy to use, and its UI and UX should be easy to understand. A good tool distills all the licensing information into compliance reports that are very simple so you can easily make sound judgments about risks like copyright, patents, and royalties. Mend’s tool does this. It generates visually impactful dashboards and screens so that this complex information can be understood at a glance.
Highlighting and implementing updates. A good tool not only hits the licensing issue but also provides great vulnerability data. This enables you to identify and upgrade to new versions of components and dependencies at the click of a button. Your tool should show you the versions you’re running and the available upgrades and recommend what to switch to. This means you continue to comply with licensing criteria while simultaneously reinforcing security by implementing the newest versions that are likely to be less vulnerable.
Setting up policies and alerts. Your tool can make license management easier by setting policies, and when they are breached, alerting users so that they can address the issues quickly. Ideally, your tool should even prevent building with non-compliant components to ensure you don’t introduce any risk to your applications. Mend’s tool can set policies at both the product and organizational levels and can automatically reject components that don’t comply with your policies.
Best practices for choosing an open source license management tool?
Perhaps the most important thing is to allow your developers to find the license management tool that fits them best. Then it’s a case of ensuring that it’s thorough so that developers get all the information they need to do in-depth due diligence.
If your developers want to introduce a new license, they must provide a risk report to the senior tech review, because they are the guys that need to know if something new has been introduced to your code base, so they can check it. They will be the ones to confirm whether the license of what has been introduced is compliant. Your tool must be able to facilitate this process.
The next question is whether a license is company-approved. That means passing it by your legal team to check whether a new library is on its approved list. You need to ensure that your tool enables you to submit libraries for review, so you can examine the licenses associated with each library.
You should be able to view and assess any dependencies — direct or indirect — so that you can see whether you risk introducing threats to your application by taking a particular library. And you need to see what the vulnerabilities are that are associated with each library.
What’s next for open source license management?
I think that open source license management is going to get more challenging. You’ll see more of the push/pull effect between permissiveness and protectiveness. Companies are more willing to use open source software, and a lot of newer licensing models are emerging that bring more freedom than a GPL. But companies still want to be able to protect themselves and their intellectual property. Therefore, there’s a persistent tension between everybody using open source licenses, and users wanting to make them more restrictive over time if they prefer.
A good example of this is Java. Java’s runtime engine used to be free, and they decided at one point that they wanted to monetize it by charging for use. But when they started charging for licenses, almost nobody used the new version. Everybody downloaded the old versions. Java realized that this could kill its product, so it suddenly changed its tactics. It still gave away its tool for free, with a few more strings attached, but still permissive enough for everybody to use further forthcoming versions.
This is the type of story you’re going to see repeatedly. Now, more companies release new open source features, libraries, and tools because they know it’s beneficial to themselves and their industries. Nevertheless, they want to ensure they have some control over them, so they can maintain their points of difference from their competitors. It’s a balancing act that will continue to exercise those of us concerned with open source license management.
Stay up to date on open source licenses
About the author
