OSS warranties and indemnities in technology transactions

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 warranties

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:

• Who will be the target of a lawsuit? When product development is complete, and your client is ready to bring its product or service to market, all eyes will be on the company and its products. The more successful a product launch is, the more scrutiny it may receive. It is unlikely that the originating OSS project will be sued, because they license the code “AS-IS” with no warranties, and your licensors will likely be unknown. It will be the product or service provider, or its customers, that will be the target of any lawsuit related to non-compliance with OSS licenses. (See Versata Software, Inc. v. Ameriprise Financial, Inc.)

• How valuable are your warranties and indemnities? Some software developers who license software solutions to other developers of commercial products provide high-quality code, and robust warranties and indemnities, and have the resources to stand behind their obligations. However, much code licensed during product development, even by large organizations, may come from small shops or contractors. In the case of startups, contractors, or other undercapitalized licensors, even strong warranties and indemnification provisions may not be worth the contracts they are written on.

• Compliance is the product developer’s responsibility. Ultimately, the responsibility for compliance with the licenses that are applicable to code contained in a product or service offering is the responsibility of the company developing the product or service. A company developing products or services should consider if and when it should delegate responsibility for license compliance to a licensor. Technology product or service companies expect and demand their customers to respect their intellectual property (IP), and to comply with their commercial terms and conditions, and it is just as important that such companies comply with the terms and conditions associated with the third-party code they use in developing those products and services. In that respect, getting robust warranties and indemnity terms may not be adequate. The Welte v. Fantec GmbH case is illustrative here. In Fantec the German Court found Fantec in violation of the GPLv2 license, applicable to code it distributed in its product. The Court explained that Fantec was negligent for relying on its Chinese supplier’s guarantee that the source code relating to the product was complete. The Court went further and provided that a distributor of GPLv2 software must carry out its own assessment of compliance, or commission experts to do so, even if such assessment required additional costs. See more. Technology innovators of all sizes must consider their responsibility to respect third-party IP, and the quality of their third-party licensors and partners, when deciding whether or not to rely strictly on warranties and indemnities.

Trust-but-verify

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.