By guest blogger Joanna Lee, Technology and Intellectual Property attorney, Partner at Gesmer Updegrove LLP
When you incorporate open source (OSS) code into larger programs, it is risky to assume that the official license for the project is the only license you need to comply with. This is true even if the only OSS code your company consumes comes from software projects with permissive rather than copyleft licenses. (For an explanation of the difference between copyleft and permissive OSS licenses, and why copyleft-licensed code cannot be used in proprietary applications, please see this blog post about OSS license types). Any OSS component could be subject to a myriad of OSS licenses that you might be unable to identify without performing a source code audit and scan. This is why regular use of source code scanning tools (a.k.a. software composition analysis software) is essential to any open source compliance program.
Why the Official Project or License Is Rarely the Only License
Most open source projects have an overarching license that applies to the project as a whole. However, this project license doesn’t necessarily apply to each individual file within the project, or even to each line code within a single file. This is because OSS projects evolve as a result of hundreds or thousands of contributions over time from many different sources. Many projects will accept contributions under OSS licenses that are different from the project license, either because the project does not vet licenses of incoming contributions at all, or because the project’s leadership has decided to allow contributions under different but compatible licenses to enable sharing and collaboration with other OSS projects. Thus, the overarching project license might not apply to the particular piece of code that you incorporate into your own programs.
Open Source Projects and Contributors Sometimes Make Licensing Mistakes
Even for projects that require all inbound contributions to be licensed under the same overarching project license, there is still a risk that a contributor might make a well-intentioned mistake and contribute incompatibly licensed code that could end up in your company’s downstream work with disastrous consequences.
For example, I previously worked with a software project that discovered that its permissively licensed program had, for several release cycles, included a file licensed under the GNU GPL v.3 (GPL), a copyleft license. A developer had taken a copyleft-licensed component from another OSS project, modified it, added a permissive license header, and contributed it to my client’s OSS project. Project leadership accepted the contribution, relying on its permissive source file header. Because the GPL applied to the original file and all downstream works, its inclusion resulted in my client’s entire OSS program becoming subject to the GPL’s copyleft license terms. Many corporate adopters had already combined this OSS program, which they had believed was permissively licensed, with their own proprietary code and distributed it outside their organizations. Due to inclusion of the GPL-licensed file, these corporate users now had an obligation, under the terms of the GPL, to make the source code of their downstream works available under the terms of the GPL. As you can imagine, this was potentially disastrous for companies whose business and monetization strategies depended on their ability to distribute downstream works on a proprietary closed source basis.
How Source Code Scanning Tools Help You Manage This Risk
Source code scanning tools prevent these types of nightmare scenarios by comparing your program’s source code to code in publicly available repositories, identifying potential matches, and notifying you of what license terms apply to these matches. In other words, scanning tools alert you when incompatibly licensed OSS code slips through your other compliance checkpoints undetected.
You can perform scans periodically (e.g., on a quarterly or monthly basis) or at certain compliance checkpoints (e.g., each time prior to release of a new update). Alternatively, if you use a tool such as FOSSA, it will automatically scan new code as you build, integrating compliance into your development processes.
There are many scanning tools and vendors to choose from. For example, Black Duck, WhiteSource, and FOSSA are well-known vendors that offer scanning tools on a subscription basis. FOSSology is an open source scanning tool maintained by the Linux Foundation, but it doesn’t come with a pre-populated library of open source code or software repository, which you would need to build on your own. Most vendor tools require you to initiate a scan as an event. One of the advantages of a tool such as FOSSA is that it automatically scans new code as you build, and alerts you to potential non-compliance issues in real-time, so issues can be identified early in the development lifecycle without needing to manually initiate a scanning event.
For more tips on how to evaluate which scanning tool is best for your company, see Chapter 12 of The Linux Foundation’s Open Source Compliance in the Enterprise, available here.
This article is adapted from a blog post originally published at http://www.consortiuminfo.org/standardsblog/ on February 25, 2020 and is reproduced with the author’s permission.
You can see more relevant content in the FOSSA resource library.
