About 20 years ago, we started to see a significant increase in awareness of potential due diligence risks related to open source software. Much of this stemmed from the watershed moment when Cisco bought Linksys in the very early 2000s, and there was a GPL compliance issue with the Linksys router.

The first generation of OSS license compliance tools was developed primarily for use in audits and professional services engagements. Organizations hired consultants to use these tools, produce a report, and then provide consulting services to help companies navigate open source due diligence.

The fact that early compliance tools were engineered primarily for audits had a significant impact on usability. For one, they skewed to false positives. When you’re doing an audit, you want to find every problem, and a properly designed audit tool emphasizes the identification of every possible problem, no matter how small. That was part of the design for the first generation of tools. Additionally, the first generation of tools was intended to be used by specialized consultants — not companies in the day-to-day of software development. Moreover, tool developers, eager to avoid the liability that might come with offering legal advice, were resistant to making qualitative judgments about the riskiness of problems they did identify.

In contrast, the current generation of tools is engineered for use on a day-to-day basis — not just one-off audits. Some of the original, first-generation tools have evolved over the years and are still used today, but their user interaction was developed later and tends to reflect the user interaction style of the pre-smartphone era. You can tell those tools weren’t initially developed for use in day-to-day compliance.

Another difference between the first and current generation of tools is that web development has become much more important, whereas the original tools were focused on lower-level development. Today, most development takes place in the environment of high-level scripting languages — from Javascript, to Rust, to Go. These languages execute in source code form, or something very close to it, and to the extent they don’t, are easily decompiled.

All this is important history and context for the topics I’ll cover in the remainder of this blog: what to prioritize when you evaluate new compliance tooling and strategies to get more value from existing tools.

This post is based on a webinar I recently conducted with FOSSA: The Lawyer’s Guide to OSS License Compliance Tools. If you’re interested in this topic, I’d also point you in the direction of the on-demand recording for a more in-depth discussion.

Editor’s Note: Heather Meeker is one of the world’s foremost legal experts on open source software licensing and compliance. She’s authored the go-to book on the topic, Open Source for Business, and is a General Partner at OSS Capital.

Watch On-Demand: The Lawyer's Guide to OSS License Compliance Tools

Features of Modern Compliance Tools

I mentioned earlier that one of the main differences between modern compliance tools and earlier generations is support for business processes. Let’s now take a deeper dive into how and why that is.

Structured Communication

Software development is a much more distributed activity than it used to be. Engineers are often not in the same place — they’re usually developing asynchronously, and they make extremely heavy use of networking-type tools like GitHub and Jira.

For those who may not be familiar with Jira, it’s an issue-tracking system where you can open issues and route them to the proper person to address. Jira creates a structured way of dealing with problems that come up during software development. This is in contrast to an unstructured approach, which often involves using spreadsheets, or comments, and emailing others about issues.

Modern compliance tools come with built-in integrations to developer-preferred tools like Jira to allow for more efficient and effective collaboration and issue resolution.

Customizable Rules and Policies

In open source license compliance, there is a big difference between use cases that involve distribution and those that don’t. Use cases that don’t involve distribution include testing and development tools and back-end server or infrastructure software. On the other hand, software in products is generally distributed. Open source users will have much greater risk sensitivity about the risk of compliance for software that they are distributing.

With modern compliance tools, you can set policies specific to use cases, so you don’t focus on low-risk issues. For example, some of my clients have decided that they will only flag AGPL and other network copyleft licenses for SaaS back-end software. They don’t even bother to diligence GPL and LGPL, because their conditions don’t apply to mere use. Developers can create and implement a back-end server-specific policy so they’re not constantly being presented with false positives that are distracting and time-consuming to analyze. And, they can create another policy that flags all copyleft licenses, not just AGPL, for distributed software. They can also set policies for embedded software, custom Linux development, or other use cases that require greater levels of control and diligence.

License Notices

An extremely helpful feature of modern compliance tools is the ability to create license notices for a product. License notices refer to documentation that describes the terms under which open source components have been made available to you and your product recipients – usually consisting of copies of licenses and certain meta-information. Notices usually require a distributor of open source software to include entire copies of applicable licenses, and some licenses also require delivery of acknowledgments of authors and contributors. People spend a lot of time creating license text files for products when they’re doing binary distribution, so tools that can automate the process are quite valuable.

For more information on this topic, I’d suggest viewing the on-demand recording of my webinar Demystifying License Notices with Automation.

How to Choose the Right Compliance Tool

There is no one-size-fits-all approach to choosing the right compliance tool for your organization. You may need different tools for different parts of your organization, or for different stages in your organization’s growth. The best fit depends on how you plan to use the tool — though there are a few specific capabilities that most companies do find useful.

Supports Your Primary Use Case

First of all, you need to determine whether you intend to use the tool for day-to-day compliance, or only audits.

Many tools can support a one-off audit. But if you are looking for a tool that enables continuous compliance, you’ll want to find one that automates your business processes. For example:

  1. You set policies to determine which licenses are acceptable for which use cases. You should be able to implement policies within the tool that account for 99-plus percent of licenses. If the tool detects a license that isn’t allowed by your policy, it should trigger a review.
  2. That review should feed into a trouble-ticketing system like Jira, so it will remind the right person to do the review. And, you should be able to set up business logic so that when that person approves, the issue gets cleared and doesn’t get raised on every product release. Or, if more information is needed, a request should get routed to the engineering team. This sort of tight integration with developer-preferred tools is crucial and can save a lot of time and effort – not to mention frustration.
  3. The tool should also maintain an auto-updating SBOM — you should be able to produce an accurate, up-to-date inventory of your open source usage at any time, in just a few clicks.

Another consideration is what your development actually looks like. There’s a big difference between building custom Linux systems for IoT devices and building websites — the languages, development environment, and the approach to development are different.

If you’re doing custom Linux, you’ll want tooling that takes a much more granular approach to compliance. This is because you’re much more likely to have what we call cut-and-paste errors, which can occur when people cut and paste code into the development code base without copying the license terms. Also, importantly, that kind of coding tends to be in traditional, compiled languages like C++, which are not so easy to decompile and are often deployed in binary form only.

On the other hand, web development tends to involve gluing together a lot of different packages without much modification and using code that executes without a separate binary form. For this kind of code, separate source code offers or build instructions may not be necessary. So, you need to look at what the tools do, how they work, and how quickly they work on different kinds of software.

Makes it Easy for Engineering

One of the more painful and frustrating experiences for legal teams is when you set up a compliance program, and engineering doesn’t participate in it. The best way to avoid this outcome is to select tooling that is as easy as possible for your developers to use. I can’t emphasize enough that the more you work within existing development workflows, the more compliance you’re going to get from engineers.

You don’t want to ask engineering to learn an entirely new system to do compliance — you want to make it as easy as possible for them.

Has Out-of-Box Policies

I strongly recommend looking for tools with out-of-box policies. An out-of-box policy will come with a long list of licenses — and either “approve” or “deny” for each one (based on a typical risk tolerance and use case). It will also flag outliers that may require manual resolution, but if you get the policy right, most of the work should be automated.

For example, let’s suppose we’re doing a policy for a mobile app. A typical mobile app policy would say no GPL or LGPL code because it’s difficult to comply with those licenses in the mobile app environment. In this case, we’ll probably approve permissive and certain weak copyleft licenses (Mozilla Public License 2.0, Eclipse Public License) because we can comply with them in a mobile app context.

In contrast, you may be doing a custom Linux system, where all code needs to be GPL v2 or GPL v2 compatible.  That’s a completely different set of rules.

Ultimately, it’s helpful if the tool has a few canned policies that you can start with. Now, you may want to tweak them, so it’s important that the out-of-box options are easy to modify. But you want something pre-built as a starting point because it will save you a lot of time and trouble.

You also want the tool to give you some meta information so you can find the code in your development environment if you identify a problem. This includes context like project name, where the project is on the web, and the type of linking that might be applicable (particularly for LGPL).

Moreover, if you are buying a sophisticated tool, you should not expect to pay expensive professional services fees to set up your license policies. These should be mostly out of the box.

Getting More Value from Existing Compliance Tools

Enterprises of all types are moving toward standardization for license compliance. Already, a lot of my clients find that if they don’t have proper compliance policies in place, they can’t make sales, or the sales process slows down. Fortunately, certain modern compliance tools have features that allow for standardization.

Fulfilling OpenChain Requirements

Modern compliance tools can help you meet OpenChain requirements, the ISO standard for software compliance. (And, as an aside, I would encourage anybody who’s selling software products to consider OpenChain — it’s a good guideline to make sure you have your internal processes in order.) If you have professional tooling, it should provide a lot of what’s necessary to support OpenChain compliance certification.

Creating License Notices

Modern compliance tooling will at least handle the majority of the work that goes into creating license notices. This saves you a lot of time — creating a license notice file by hand really is no fun for anybody.

Generating SBOMs in SDPX

SPDX is an XML format with information like what you’d be accustomed to seeing in a software bill of materials: version of the package, where it comes from, what license it’s under, and so forth. This is the kind of information you usually need to make a disclosure about open source.

If you’ve gone through any financing or M&A deal, you’ve probably been asked to make a disclosure about open source. And, if you’re using SPDX or a tool that generates SPDX, it’s very easy to produce that information. It’s like the flip of a switch. Whereas if you don’t have that, it is an extraordinary amount of work to create a proper SBOM.

Another benefit of SPDX is that it is explicitly mentioned in the Biden Administration's Cybersecurity Executive Order as an approved SBOM export format. Over time, the legal and business requirements for accurate SBOMs are going to increase, not decrease. If you can’t produce an accurate SBOM, your sales function is living on borrowed time.

Additional Resources: OSS License Compliance

As I mentioned at the beginning of this blog post, I recently conducted a webinar with FOSSA: “The Lawyer’s Guide to OSS License Compliance Tools.” You can view the on-demand recording at this link.

Additionally, here are a few more license compliance-related resources that may be of interest.

Editor’s Note: FOSSA developed our out-of-box policy templates with input from experts like Heather. Please reach out to our team if you’d like more details on implementing policies in FOSSA.