Tips and Tools for Open Source Compliance

Agree on an Open Source Compliance Policy

With millions of open source projects and over 200 different open source licenses, open source compliance might seem like a daunting project. The situation in practice is much more simple –the vast majority of open source projects only use one of a handful of licenses. Still, it’s very important to define a repeatable process for handling new open source components in your project. This is where your open source policy comes in.

An open source license compliance policy is an agreement within your organization about which open source licenses your company can and cannot use and what is the approval process for special cases. It involves your engineering and legal team, it can also include your security team in case you’d like to set a policy for vulnerable open source libraries. If you are just getting started, you better stick to licenses only. You can create your open source policy template for your first draft to ensure you are covering all the required aspects.

When it comes to compliance, your open source policy will need to define at least 3 basic definitions: a whitelist of approved licenses, a blacklist of open source licenses that cannot be used and an approval process for all other licenses. Since there are over 200 open source licenses out there, only 70 plus are approved by the OSI, you should take into account you cannot cover all licenses.

Remember, there are no good or bad open source licenses. it is merely a question of what suits your company and your business model. The most problematic open source licenses for commercial software products are the copyleft ones, like the GPL family, as it requires companies to open source their entire code. But you should be aware that other open source licenses, which are considered permissive and business-friendly, may have some problematic restrictions on patents or compatibility with other open source licenses.

This is part of an extensive series of guides about Compliance Management

Track Your Open Source Usage

Once you have your open source license compliance policy in place, it’s time to figure out what open source components are in your software.

The first question you should ask yourself is whether you can settle for a manual tracking process, or does your company need an automated solution. We might be biased, but here’s why we (and Forrester) believe that no software company with more than 20 developers can settle for a manual process.

Your end goal will be to have an inventory list of all your open source components and their respective licenses. It is vital to include all dependencies in your open source inventory report since a dependency may have a different license than the actual library you are using, but you are still obligated to comply with the dependency license.

After choosing your preferred method of tracking your open source usage, you will need to generate an open source inventory report. Once you have your open source inventory report, you will need to identify all open source components without an open source license. It may sound weird at first, but many open source projects actually don’t carry any kind of a license, which basically makes them not open source and therefore still protected by copyright laws. Your next step will be to identify all licenses in your blacklist and get engineering to work on a plan to replace all problematic components and then attend the questionable licenses (neither in your whitelist nor your blacklist).

Once you have identified all open source components and licenses in your software, and processed it all based on your open source license compliance policy, you will most likely need to prepare an attribution document. Most open source licenses contain an attribution clause. Compliance with the attribution clause of these licenses generally takes the form of an attribution document, which includes a list of copyrights, notices and a list of licenses.

Now, you will need to decide how to apply your policy on new components added to your software and how to manage the approval process. Below you can find a list of open source compliance tools that can help your team, based on your preferred tracking method. I strongly recommend you check out Linux foundation’s new online free course: Compliance Basic for Developers if you feel you’d like to gain more understanding on the different open source licenses, copyrights and notices requirements.

List of open source compliance tools to help you manage your licenses

#1 The Basic – Spreadsheets & Emails

Manual tracking is usually done with spreadsheets or ticketing software and it is the most basic approach. It is also probably what the majority of companies do, although it is quickly changing due to increased awareness of the importance and the rising of new affordable, automated solutions, like Mend’s.

The attractiveness of this approach is that it takes practically no work to set up, and if you are using a very small number of open source libraries, then it’s sufficient for tracking your usage. It also requires no overhead or customizing of additional tools, but be aware of hidden costs.

#2 FOSSology

Several open source tools exist to help out with manual tracking and to automate a part of this process. You can find a list of these tools here, but the best known and most advanced of them is FOSSology, a project initially started by Hewlett-Packard and now hosted by the Linux Foundation.

FOSSology scans the headers of files in your project and uses a variety of heuristics to detect text from open source licenses. FOSSology offers significant automation over simple manual tracking, and can find open source components that were not tracked by developers. However, it is likely to suffer from many false negatives — if a file doesn’t have a license referenced in the header file, it won’t be detected.

#3 Continuous Integration Scanners

These tools provide an automated solution to tracking and managing the open source components in your software. It provides the most accurate and detailed information and saves your developers from the need to manually account of each new component added. This is the approach provided by Mend. Our tool automates tracking & managing security vulnerabilities, software bugs, versions and more, but for now, let’s focus on licenses.

As the name suggests, it integrates into your continuous integration or builds tools, such as Jenkins, Maven, or Ant. It automatically detects all open source components in your build, every time you run it — probably multiple times a day. It does that by calculating a unique identifier for each library and then cross reference with its database to detect the open source libraries. This way, you get constant feedback about your open source libraries and their licenses and can react in an immediate and agile way in case there is a conflict with your open source policy. You can even set an automated policy that will approve, reject, or send a request to approval based on your rules. You can even break the build, if a blacklist license is used.

This technology ensures there are no false positives and therefore, does not require any training or additional work post generating the reports. It also automates the entire process, from automatically enforcing your policy, to managing the approval process and up to automatically creating the attribution document. This will increase your accuracy and will release your developers from labor intensive bureaucracy.

#4 Code Scanners

Finally, we have the known method of open source management – the periodical code scanning. The bulk of commercial open source management tools, such as Black Duck Software, Palamida, Open Logic (now RagueWave), and Protecode (Now Synopsis) fall into this category. There are a few unique characteristics to periodical code scanning that separate it from both manual testing and from continuous automation. This technology does not suits agile software development teams, but waterfall methods.

Which approach is right for you?

Different approaches to open source compliance can be suitable for different organizations or even for different projects within an organization. You will need to 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 small projects, manual tracking might be sufficient. On the other hand, more complex projects, particularly those built inside of an agile organization and released on a frequent schedule, will benefit from continuous detection of open source components.

In any case, as the growing use of open source code in enterprise software shows, the benefits of using open source code clearly outweigh the cost of compliance. And with the continuing development of modern tools for open source management, the issue of open source compliance is becoming even easier to integrate into a smart and streamlined development process.

See Our Additional Guides on Key Compliance management Topics

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

Technical Due Diligence

• M&A Due Diligence: Open Source Report and License Analysis
• Top Tips for Technical Due Diligence Process
• When’s the Right Time for an Open Source Audit?

Employee Classification

Authored by Stoke

• Worker Classification: The How-To Playbook
• FLSA Classification: Who is Exempt and Why Do You Need to Know?
• Employee Misclassification 101: What You Need to Know

AB5

Authored by Stoke

• AB5 Updates: Where Does the Original Legislation Stand Now?
• AB2257: Another Significant Update to California’s AB5
• Proposition 22: What Is It and What Are Its Ramifications?