Open Source licenses in the spotlight

Open Source software (OSS) is the foundation of many software development projects. This is advantageous as it speeds up development through reuse and increases the quality of the entire product, since OSS components are widely used and tested. Yet, it is essential to check and monitor all utilized OSS components and their license as part of a project-wide OSS Governance.

— written with Jonas Ebel as co-author.

Despite all its advantages, OSS carries the risk of a license violation, which in the worst-case scenario leads to expensive or even existence-threatening lawsuits against your company. At the very least, a license violation leads to a loss of reputation in the OSS community, which can affect the attractivity of your software development department for future employees or customers. The webpage https://gpl-violations.org/news/ lists such issues regularly.

In software development projects, OSS components are often integrated as so-called third-party libraries. One must carefully check that all licensing requirements are met when using third-party libraries. As a first step, we recommend our customers create an overview of all third-party OSS libraries in use and their respective licenses. This process should be automated (e.g. as part of the continuous integration environment) so that the OSS governance can monitor and control the inventory of open source libraries at all times.

Let’s briefly touch on the general topic of OSS governance: The integration of open-source software has several advantages (accelerated development, community support, huge ecosystem etc.). However, since incorporating such software is relatively easy, governance is required to keep an eye on the final product’s quality. The monitoring of licenses of the integrated libraries is one responsibility of OSS governance. Still, there exist further aspects that require OSS governance, such as the monitoring of security vulnerabilities or managing own OSS contributions. Our focus in this post is on monitoring the OSS licenses themselves: If the integrated licenses in the project are not checked, the development teams (accidentally or unknowingly) may include libraries that are subject to problematic license conditions (e.g. the Affero GPL, which requires a download option for the OSS source code of the integrated library on servers, see https://www.gnu.org/licenses/agpl-3.0.en.html). We want to detect such scenarios and be able to react in such situations.

Back on how to automatically generate license overview lists and install regular monitoring: We have visualized the process below and will iterate through the process in the following.

For example, in a Java environment, these lists can be generated using the “License Maven Plugin” (see http://www.mojohaus.org/license-maven-plugin/), but many other valid approaches exist. The license checks can be visualized with a convenient web interface, e.g. using the Black Duck Hub (https://www.blackducksoftware.com). The automation must include not only directly used OSS components but also includes their transitive dependencies. These must also be monitored since their application must follow the license requirements, too.

The compiled overview lists must be compared against a set of authorized/approved licenses by the OSS governance (within the context of CI automation). If this automation reports irregular licenses, the respective case must be double-checked. There are two possible outcomes:

a) The inspection shows that the license may be used in the specific context but has been missing (or hasn’t been needed yet) in the list of approved licenses. In such a case, the license receives a comment and is added to the positive list.

b) The examination concludes that the license cannot be used in that particular context. Next, the development team must decide whether the respective OSS component can be removed or replaced or the usage context must be adjusted. For example, the operating model can be adjusted for components under the GPL — a well-known “Copyleft” license. An alternative approach is to redesign the interfaces to the OSS components.

On top of this process, such lists of OSS components serve as a basis for reporting, e.g. as part of the product documentation that lists the utilized OSS components and their license requirements.

To summarize, we recommend everyone spotlight the used third-party OSS libraries in their IT department and automatically compile a list of these libraries and their transitive dependencies. The list should also include all applying OSS licenses for further evaluation and, in the best case, further automatic checks.

Unfortunately, in practice, this type of OSS governance is rarely implemented. Therefore, we are happy to support our customers in setting up and maintaining such governance.

This step is also a basis for a broader OSS portfolio governance during development and operations.