The Synopsys Software Integrity Group is now Black Duck®. Learn More

close search bar

Sorry, not available in this language yet

close language selection

OSS warranties and indemnities in technology transactions

Black Duck Editorial Staff

Nov 06, 2016 / 5 min read

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.

Summary

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.

Continue Reading

Explore Topics