“By focusing on compliance and preventing risks against future compliance, litigation can be treated as a last resort for open source software conflicts. However, litigation around OSS does occur.”
Today’s software is built like a Lego model. Instead of a singularly developed string of code, multiple building blocks of existing code are used to create a codebase. Some of those building blocks are developed in-house by the software vendor. Others are developed by third-party commercial software providers. And a lot of them come from open-source projects.
When you’re a company that puts that codebase into your final product, you must take precautions to minimize the risks that each type of code presents to you and to your customers. This is what is meant by protecting your software supply chain. It’s also how you maximize the value of the code for you and your customers. Each type of code has its own set of benefits and risks that need to be understood and managed. This article addresses just one type of those building blocks: open source software (OSS).
The benefits of using OSS are great; it can speed up development cycles, it allows for specialization in key areas, and it harnesses the knowledge of a wider variety of individuals. Like all code, using OSS does come with some risks. The one you’ve probably heard about the most is security, like Log4J or Spring4Shell. Those headlines should be enough for every user of OSS to sit up and take notice, but those aren’t the only sources of risk. Let’s take a look at a few more risks, even if they aren’t likely (thankfully) to generate any headlines.
- Commercial risks: M&A diligence requests; contractual warranties; limits on go-to market models.
- Business, development, and operational risks: dependence on code from a competitor or hostile party or from an orphaned/dead project; lack of ultimate responsibility for code quality; poor support; version-to-version breakage; version-to-version changes in license rights.
- Licensing and compliance risks: use of OSS beyond scope of license; breach of license leading to copyright infringement; viral infection of proprietary code; patent-related risks; combination of components under incompatible licenses; notice and attribution non-compliance; failure to comply with licenses for “fourth party” components.
- Remediation risks: code remediation (removing, rewriting, or replacing code); legal remediation; risk mitigation/allocation.
Despite this long list of risks, the good news is that a simple set of best practices can help you manage and mitigate them all. These practices are generally referred to as an OSS license management program.
Know Your Code and Obligations
The first step to securing your code is identifying what code you’re currently using. This may sound daunting, but with the various software composition analysis (SCA) tools on the market, your hardest job is actually just picking the one that works best for you. And depending on your specific needs, you may end up using more than one tool. The process you run is less important than the output you get. Your output should ideally include three components:
- First is a software bill of materials (SBOM). An SBOM provides an itemized inventory of the software components you use. The SBOM identifies components, versions, and associated licenses, centralizing information required for managing your OSS building blocks. An SBOM allows software suppliers to respond to requests for itemization of what’s in your software, whether required by customers at the time of making a product sale or by prospective buyers in an M&A event. SBOMs are also essential for compliance with the Biden Administration’s Executive Order on Improving the Nation’s Cybersecurity. The creation and maintenance of SBOMs can be automated through a comprehensive SCA program, which supports component, license, and vulnerability management.
- Once you have your SBOM, you can move on to create your notice or attribution files. This is one of the primary requirements of any OSS license. It lets downstream users know where you obtained the OSS by identifying and giving attribution credit to the individuals who developed the OSS.
- After the notice/attribution file, you can start to track which license types apply to which elements of the OSS in your solution. This enables you to begin confirming that you’ve complied with all of the aspects of the OSS license, to understand what they have and where they’re exposed.
After developing the SBOM, developing the notice/attribution file, and understanding the various license types associated with the OSS that you use, the final step is to make sure your hard work doesn’t need to be repeated. To do that, you must establish and enforce an easy policy for your engineers to follow when additional OSS is under consideration for being added to your products.
Make an Open Source Policy and Keep it Brief
Your organization must have a clear policy on the use of open source software, with the goals of defining what may be used and how. In essence, it specifies risks that are and aren’t acceptable. This policy becomes a fundamental guide for the developers who are doing the work. The policy must therefore be brief, manageable, and available early in the development process.
Expand Business Opportunity, While Minimizing Legal Risk
Addressing each of these risks costs time and money. The investment can be minimized, and business can be supported, with effective preventive measures.
Getting organizational buy-in for legal initiatives is often challenging. But if you approach the chief technology officer (CTO), chief financial officer (CFO), or your engineering department early with a comprehensive explanation of how minimizing legal risk can expand business opportunity, you may find a more effective opening for conversations and for budget.
With the right policies and scanning tools in place, developers have a better and safer way to develop products. Being well-informed about third-party license obligations and developing software accordingly the first time is far better than having to invest time and money in remediation and re-engineering. The payoff is twofold: creating value for the organization while simultaneously guarding against security and compliance risks. This approach can help turn risks into opportunities.
By focusing on compliance and preventing risks against future compliance, litigation can be treated as a last resort for open source software conflicts. However, litigation around OSS does occur. It actually happens more than one may assume, but in most instances it’s settled behind closed doors. When it’s been tested publicly, the GNU General Public License (GPL) has been determined to be an enforceable license. High profile cases filed to enforce open source licenses have varied significantly. For example, Patrick McHardy, formerly of the Netfilter project, identified interpretations of the GPL that were often not accepted, but from which a compliance claim could be made in order to threaten enforcement; his actions were seen as “profiteering.” In a very different case, one that may set precedent for open source copyright and contract issues more broadly, the Software Freedom Conservancy has filed a right-to-repair lawsuit against Vizio regarding the GPL copyleft license in the manufacturer’s TV products. The lawsuit seeks to require Vizio to share the source code with all users. Progress with this case, as reported in ZDNet, “makes it the first case to show individual consumers have rights to the source code as third-party beneficiaries of the GPL.”
Embrace the Opportunity
Open source software is a tool that, when used properly, can provide enormous value. As the legal landscape around it shifts, a proactive and streamlined approach to managing OSS can help support success.