Complex open source software (OSS) issues can arise in the context of any software licensing transaction, including licensing-in software components for computer software or IT product development, acquiring code as part of a merger or acquisition, or obtaining software from a contractor under a work-for-hire arrangement. The presence of OSS in each case should be presumed, and all such transactions should include properly drafted warranties and indemnities related to the code being acquired. This article will address OSS warranties and indemnity provisions generally, and how to think about them in the context of the overall intellectual property (IP) and OSS environment, as such terms relate to OSS in the development of products or services.
OSS related warranties have evolved over the years. Ten years ago, it was common for software license agreements to require the licensor to warrant that their product contained no OSS. As OSS use has exploded, those terms evolved into warranties that state if OSS is used, it is used in a manner that complies with all applicable OSS licenses, and that the use of any applicable OSS code will not cause the licensee’s products to be subject to a Copyleft license. Some licensing attorneys go further, and require licensors to list, via an exhibit to the agreement, all OSS components, and require the licensor to warrant that the list is accurate and inclusive. The list allows the developer’s open source counsel to review the applicable licenses for compatibility with the code’s intended use, and allows the attorney to compile the requisite documentation necessary to comply with the identified OSS licenses. Tying the licensor’s indemnity obligations to a breach of such warranties can provide the licensee some protection, and it puts the licensor on notice that the licensee cares about OSS compliance, and that the licensor may be held liable for breach of the warranties. In such a case, it is a red flag if a licensor refuses to grant the warranties.
Even the “list-and-warrant” approach may not be adequate. If your client does not know what OSS code is in its product build before shipping, there is no way to confirm it has complied with the obligations and conditions of the applicable OSS licenses. Even the most permissive OSS licenses may have conditions, such as including copyright attributions in the shipping product’s documentation, which if not met could lead to unlicensed use and infringement claims. Compliance starts with knowing what’s in the code. The following are just a few of the reasons why relying on warranties from licensors may not be enough:
In the end, the appropriate approach to compliance depends on many factors, including the product developer’s risk tolerance, its ability to identify OSS in its products, and other factors. If mitigating risk is important to a product developer, it can determine its baseline risk profile by confirming the composition of its code. For example, some developers routinely audit their own code before product launch, and others scan code acquired during a license-in transaction as a matter of policy. In the end, absent a quality source control mechanism, and contract management system capable of generating an accurate third-party component report, scanning the code may be the only option. Trust-but-Verify includes getting the appropriate warranties and indemnities up front, but also verifying what’s in the code, and verifying compliance with licenses, before shipping the product or service.
When your client is unsure of the composition of its product codebase, an analysis of the software using a code scanning service may be a critical step in OSS compliance and risk mitigation. Once the developer has determined the composition of its codebase, either from a scan or from an internally generated report, the next phase of OSS license compliance is just as important. After understanding the composition of the code, a skilled open source legal professional should determine if all the components are licensed under compatible licenses that permit the intended use, or whether some components need to be replaced by substitutes with compatible licensing. Once the compatibility of the code has been confirmed, the expert should compile the necessary attributions or other requirements of the licenses, and determine how best to comply with any source code distribution requirements. Shipping a product or service offering without complying with applicable conditions, such as providing the proper documentation or source code on distribution, can lead to litigation, even if the components are licensed under compatible OSS licenses.
Take the next step toward establishing a complete profile of your codebase. Schedule a consult with the experts in the Black Duck Audits group.