How-To

The ABCs of open-source license compliance

Consider compliance from the start — no one thinks they’ll be asked for the bill of material for their software until lawyers step in.

July 12, 2019
image

With open source software ubiquitous and irreplaceable, setting up a license compliance and procurement strategy for your business is indispensable. No software engineer I know wants to voluntarily talk about open source compliance, but avoiding those conversations can lead to a lot of pain. Remember the litigation for GPL-violations with D-Link, TomTom and many more in the early 2000s?

It’s better to keep in mind open-source license compliance from the early stages of development when creating a product: you want to know where all its parts are coming from and if they’re any good. Nobody thinks they will be asked for the bill of material for their software product until they are.

“Open source compliance is the process by which users, integrators and developers of open source software observe copyright notices and satisfy license obligations for their open source software components” — The Linux Foundation

Objectives for open source software (OSS) compliance in companies:

  • Protect proprietary IP
  • Facilitate the effective use of open source software
  • Comply with open source licensing
  • Comply with the third-party software supplier/customer obligations

What’s a software license, anyway?

Put very simply, a software license is a document that states what users are permitted to do with a piece of software. Open source software (OSS) licenses are licenses that the Open Source Initiative (OSI) has reviewed for respecting the Open Source Definition.  There are approximately 80 open source licenses (OSI maintains a list and so does the Free Software Foundation although these are called “free software” licenses), split between two larger families:

  • So-called “copyleft” licenses (GPLv2 and GPLv3) designed to guarantee users long-term freedoms, make it harder to lock the code in proprietary/non-free applications. The most important clause in these is that if you want to modify the software under copyleft license you have to share the modifications under a compatible license.
  • Permissive/BSD-like open source licenses guarantee freedom of using the source code, modifying it and redistribute, including as a proprietary product. (for example MIT, Apache.)

Despite the variety of licenses, companies sometimes invent new ones, modify them with new clauses and apply them to their products. This creates even more confusion among engineers. If your company’s looking to use open source software, tracking and complying with every open source license and hybrids can be a nightmare.

Establish an open-source license compliance policy

The goal is to have a full inventory of all the open source components in use and their  dependencies. It should be clear that there are no conflicts between licenses, all clauses are met and necessary attributions to the authors are made.

Whether you have an open source project using other open source components, or a proprietary project using open source components, it is important to establish a clear policy regarding OSS compliance. You want to create a solid, repeatable policy to outline what licenses are acceptable for your specific project.

Ways to execute OSS compliance

Manual

A surprising number of companies are still using this approach.  Basically, you create a spreadsheet and manually fill it out with components, versions, licenses and analyze it against your policy.

This works out well for smaller projects if they established a compliance policy (list of licenses or clauses acceptable in the company) from the beginning to spare themselves trouble in the future. In this scenario, every developer must review and log a software’s license before introducing the open source component.

The downside of this approach is that as the quantity of OSS components in the project grows, it becomes more difficult to keep track of relationships between licenses (if they all work together or there are conflicts). It is vital to list them as the dependency might have a different license than the actual library you are using.

Semi-automated

This is a more reliable approach and is becoming more popular, as the importance of open source compliance practices grows along with the risks associated with ignoring these practices. There are many tools available, in a way that it makes the prospect of automating overwhelming. Why semi-automated? Because there are always false positives if the license is not explicitly referenced in the header and you still have to read through some of them to discover special terms or conditions.

Of the tools I’ve seen, there are four main approaches:

  1. File scanners – usually involve all sorts of heuristics to detect licenses or components that usually would be missed by developers. Usually, these tools offer different formats for the output.
  2. Code scanners – exactly what it sounds like. You can use them periodically to check for new open- source components.
  3. Continuous integration (CI) scanners – these tools work with continuous integration or build tools. This will automatically detect all open-source components in the code every time you run a build. The idea is to create a unique identifier for each open-source component in the build and reference it against a database of existing components. You can also set policies to break the build if a blacklisted license is found.
  4. Component identification tools – these tools can help you produce a software bill-of-material (SBOM), the list of OSS components in your product.

A good place to start? The tools highlighted by the Open Compliance Program, a Linux Foundation initiative.

Conclusions

For smaller projects, fully manual tracking might be sufficient to achieve license compliance. For more complex projects, especially the ones built in an agile style with regular releases, automation is better. Whichever way you choose to handle OSS compliance, don’t ignore it for the sake of your project and sustaining the open-source community.

Dasha Gurova is the technical community manager at Scality, where a version of this post first appeared in the forum.

Superuser is always interested in open infrastructure community content, get in touch: editorATopenstack.org

Photo // CC BY NC

Tags:

Superuser
Latest posts by Superuser (see all)