For transactions lawyers, negotiating intellectual property infringement indemnities is an unfortunate and often painful fact of life. Allocation of risk terms are notoriously difficult to resolve, and often are the last issues in a deal to be agreed. Business persons consider them abstruse “lawyer work,” and lawyers consider them business issues that get short shrift in deal memos. But for transactional lawyers, negotiating indemnities is part of the life we have chosen.
As open source software has become integral to technology development, negotiating allocation of risk terms for IP infringement has become even more challenging. Open source software does not fit well into the traditional paradigm for allocating IP infringement risk, so a difficult negotiation topic has become even more difficult.
Clients, often frustrated with this process, always ask two questions: What is “market”? And what is reasonable? The answers are anecdotal at best, and usually not the same for both questions.
Clients repeatedly ask two questions: What is “market”? And what is reasonable?
This analysis is intended to help lawyers and business people understand how to analyze allocation of risk terms for third party open source software in commercial transactions. I refer to this issue as the “IP Question.” This analysis posits a negotiation between a vendor of a technology product that contains third party open source software, and a potential customer.
But the principles of the IP Question can also be applied to indemnities in other kinds of transactions, such as investments, acquisitions or joint development deals. My thesis is that vendors today are regularly asked to bear an unreasonable amount of liability due to a misunderstanding of the IP Question. While that may seem on face like a windfall to customers, it leads to unsustainable business agreements for vendors and customers alike.
Beyond Good and Evil
One of the hurdles in negotiating the IP Question is that negotiating parties tend to view it as a moral issue. In the moral conflict, the vendor views an indemnity against third party open source infringement as an unfair cost. The customer wants the vendor to be morally responsible for any harm that may befall the customer as a result of using the product. Regardless of which view you take, it is clear that reducing the IP Question to a moral question makes it a zero-sum game, and those are always difficult to resolve. While the moral view may be tempting, it is not very useful to get deals done.
The IP Question manifests when, at some point in the negotiation, the customer utters the phrase, “You need to stand up for your product!” And once this gauntlet has been thrown, and the IP Question has thus been reduced to a moral dilemma, the vendor and customer have no choice but to ham-handedly exercise their relative bargaining power tor resolve it, without either side engaging in the burden of critical thought. If the vendor is small and the customer is big, the customer wins. If the vendor is big and the customer is small, the vendor wins. But if you are an intrepid soul willing to engage in a more thoughtful approach, this analysis will help you “think outside the box” about the IP Question.
Indemnities are Costly
In fact, indemnities are not moral choices, but economic mechanisms to share risk. An infringement indemnity reduced to its purest form is an insurance contract. If I get hurt, you pay me. No one makes the mistake of thinking that insurance is free of charge, or a moral dilemma. But customers often expect vendors to bear broad indemnities for their products at no additional price.
Suppose that a third party insurer were willing to write a policy to indemnify the customer against third party open source intellectual property infringement. What would happen?
- There would be a money premium for the insurance
- The policy would contain limitations on coverage, and the premium would be priced accordingly
Unfortunately, in negotiations between vendors and customers on the IP Question, infringement indemnities are not negotiated in this way. If they were, the result would be simple:
- The customer would choose whether or not to pay extra to get the indemnity.
- The price of the indemnity would be calculated based on the type and amount of coverage the customer chose.
- The vendor and the customer could, if they chose, share the cost of the premium by negotiating a discount.
Indemnities are difficult to negotiate because they are never reduced to a priced deal point in this way. But why not, when doing this is so obviously sensible? Mainly because third party insurance for such risks is generally not available, making most vendors self-insured. Also, when parties negotiate the terms of contracts, they treat indemnities as undisclosed “legal” terms rather than essential deal terms — meaning they have merely kicked the can down the road for the lawyers to argue over.
But it does no good to lament this phenomenon. If the vendor and customer will not view the IP Question as a pure economic decision, then how do they actually come to agreement?
What is Not Relevant
First, let’s understand what the IP Question is not. There are two similar issues that arise when negotiating IT procurement deals, that should not be conflated with the IP Question.
Vendor Compliance. The first of these is the vendor’s open source license compliance. Because open source compliance claims are usually cast as copyright infringement claims, non-compliance is potentially an IP risk, but not a risk arising from third party actions. A vendor who supplies a customer with third party open source software must follow the license terms that facially apply to that software. That duty does not arise from the customer contract; it arises from the open source licenses. The customer contract may require the vendor to pay legal fees to defend a compliance claim against a customer, if that claim arises from a failure of the vendor to comply with the open source license terms when it delivers the product to the customer. But few vendors attempt to avoid responsibility for their own compliance. The IP Question, instead, is about third party open source software that is infringing of third party IP rights, even when the vendor has complied with the facially applied license. In other words, it is a risk the vendor cannot control.
For example, suppose a project is on GITHUB and bears an Apache 2.0 license, but the project contains code that was improperly contributed by a person without the right to make the contribution, or a cut-and-paste of third party code under GPL. That could result in copyright or trade secret claims against re-distributors or users of the project. It is one cause of the IP Question. Alternatively, a project may, unbeknownst to the project’s maintainers, infringe third party patent rights. That can result in claims of patent infringement against users of the code. But neither of these arise from malfeasance by the vendor, or by the customer.
Performance Warranties. The second is warranties or indemnities arising from the performance, or non-performance, of software. These are commercial warranties, and vendors often undertake them for third party open source elements, because the vendors are engaging in quality control, maintenance and support for their products that happen to include the third party open source elements. These are not IP claims at all, and they are not part of the IP Question.
Two Theories: Control and Internal Pricing
Now that we know the boundaries of the IP Question, and accepting the dismaying premise that we cannot simply price it out as insurance, we consider other ways to rationally allocate the risk it represents. In contracts, there are a couple of common theories as to why one party or another should bear risk: control and economic efficiency.
Control. Most lawyers focus on the control theory, under which the party who is best able to control the risk bears the liability. The cost of bearing that risk will tend to change the bearer’s behavior toward reducing the risk. This approach works well for risks like products liability. If a vendor manufactures a light switch, the vendor can make sure the light switch is properly built, will not short circuit and injure the user, and is properly tested for compatibility with local electrical standards. Moreover, the vendor can easily insure against products liability risk. So, it makes sense for the vendor to undertake that risk, because of its relatively high level of control.
The difference with the IP Question, of course, is that the vendor has almost no control over whether third party open source software infringes IP rights. So, if a vendor sells a smart light switch, it may include open source software that interfaces with a mobile app to set automatic on and off cycles via Bluetooth. The vendor probably gets that software from a third party open source project.
Customers will argue that the vendor can make a build-or-buy decision to address this risk. For example, instead of getting the Bluetooth control software from an open source project, the vendor could write its own software. Obviously, that would raise the development cost for the light switch, perhaps substantially, and the vendor would pass that cost on to the customer. And a sophisticated vendor will also point out that home-grown software is unlikely to be as reliable or secure as existing open source software. Moreover, if the light switch is intended to conform to a larger specification for IoT, like a Google Home or Apple Home system, writing home-grown routines will tend to make the device incompatible, or require the vendor to reinvent the wheel to figure out how to make it compatible. In such cases, if the vendor exercises control over developing the software, it will actually make the product worse. For these reasons, control is not a very useful theory to resolve the IP Question.
The flip side of the control argument is that risks better addressed by the customer should be borne by the customer. For example, if a customer elects to use the vendor’s product in high risk activities or in ways that violate the agreement between them, the customer would usually bear liability for those uses, because the customer can best control those decisions. While indemnities from customers to vendors are not as common as vice-versa, these allocations of risk sometimes take the form of express terms limiting the vendor’s liability in the contract, rather than allocating them to the customer. Risks that are not expressly allocated in contracts will fall to the parties in accordance with background law.
The control theory is also significantly out of alignment with the way open source infringement problems are solved in practice. If there is an IP problem with an open source project, particularly a project that is widely used, that problem is not solved by one vendor. If there were an IP problem with Linux, or Hadoop, or Firefox, that problem would be solved by the maintainers of the project — probably with plenty of help from the community. For a single vendor using that project to try to resolve it would be inefficient and counterproductive. At a minimum, it would cause the vendor to have to fork the code to engineer around the problem, defeating many of the benefits of including open source software in the product. In fact, licenses, like GPL3 actually limit the possibility of doing so, by requiring licensees to clear patent rights for everyone if they clear it for themselves via a license. So in sum, the vendor has no reasonable way to either prevent IP problems, or resolve them.
Allocation of Internal Risk Premium. The other theory or risk allocation is based on economic efficiency, and under this theory the vendor essentially loses the argument. In any deal, one party is usually paying and the other is getting paid. The party making the profit from the transaction can therefore more easily bear the cost of the indemnity, and take a reasonable reserve against its profits as self-insurance. The problem with this approach, of course, is that the vendor is likely to build this reserve into the product cost, thereby raising the product price. So, while a customer may always win this argument, it may be a Pyrrhic victory, and it places a high burden on the vendor to amortize an unknown risk.
These two approaches once worked fairly well for products developed by a single vendor — the cathedral rather than the bazaar. But in today’s landscape of heavy use of open source, this analysis is broken.
What is the Product?
Now, finally, we can find a path through the IP Question, but only if we leave the old ways behind. Contemporary IT systems are increasingly vertically dis-integrated. Once upon a time, you may have bought a computer and all of its software in one transaction from one vendor, but those days are ancient history. Yet vendors and customers are still negotiating the IP Question as if IT systems are monolithic technology of the 1980s. When the customer utters the battle cry, “Stand up for your product!”, the next question is: what exactly is the product?
Vendors in today’s computing world are, more than ever, systems integrators of layered technology solutions that largely consist of third party open source software and IP. Taking an extreme example, a company like Red Hat, which sells subscriptions to Linux distributions, is mostly selling quality control. The software is free, but the QC has a price. Most IT products today, of course, are not so starkly reliant on third party open source software, but even the most “proprietary” products today are not developed in a vertically integrated manner. That’s a good thing; it means that because of the wealth of open source software in existence today, vendors no longer need to reinvent the wheel. The job of vendors today is to select and integrate open source components with their own technology,add their own value in the form of unique product functionality, and provide quality control.
So, it makes sense to develop a more nuanced notion of what constitutes a vendor product. In the old, monolithic model, it is everything that the vendor delivers to the customer. But in the more nuanced model, the vendor delivers a substantial amount of third party software as a courtesy to the customer — much of which is not reasonably considered part of the vendor’s product.
Consider, for example, a software vendor contract in which the vendor, FOOBAR, Inc., delivers its application, FOOBAR for Linux. Once upon a time, that product would have been delivered on a diskette for the customer to install on its own Linux system. In those circumstances, the vendor would be asked to indemnify for IP infringement arising from the FOOBAR application, but not the Linux operating system. This business expectation is by no means unique to open source; if the product were FOOBAR for the Windows operating system, no customer would expect the vendor to indemnify for IP infringement arising from Windows.
The Product of Today
Today, FOOBAR will just as likely be delivered as part of a virtualized image or container that includes FOOBAR and Linux. It’s the same product, but packaged differently. It would, of course, be possible for the customer to get Linux on its own, free of charge. But that would only cause technical problems, because the vendor can better ensure that it is delivering compatible versions of Linux and FOOBAR. The delivery of the operating system is a convenience for both parties, but it doesn’t mean the operating system is part of the vendor’s product. This approach to delivery is possible only because the operating system is open source, so the vendor has the right to distribute it free of charge.
Why, then, does this result in a customer demanding infringement indemnities for the entire package? It is because the parties have failed to correctly define the vendor’s product in light of contemporary delivery practices. To correct this, those negotiating IT deals need to understand the difference between software and the environment in which it runs. Here is a very simple version of the difference:
The above is the “birds and bees” version of the modern software landscape. It is a very simple abstraction using only two computing layers — the application and the operating system, but it gets the point across. It’s no wonder the parties have trouble understanding the scope of the product. It is quite possible that that vendor will make a warranty about the performance of the entire container, including both the FOOBAR application and the operating system, when it is the vendor’s job to deliver a quality, integration solution. But this should not drive the definition of the product for the purpose of the IP Question.
The problem of defining the product is more stark when one considers a more realistic version of what vendors today actually deliver.
Any application sold today now rests on a formidable stack of open source software that makes it faster, and more fault-resistant, flexible, and powerful. This is the breakthrough in software that allow companies to run thousands or millions of applications in parallel, and maintain consistent data bases across them. That stack of software is sometimes referred to as the “LAMP stack” (Linux, Apache, MySQL and Python) but today, even LAMP is an oversimplified view, so let’s just call it the computing landscape.
If we want to think rationally about the IP Question, we need this more nuanced view of the technology landscape. And it isn’t hard to understand. Suppose you want to buy a boat. A boat dealer sells you the boat. You cannot sail the boat without an ocean. Is the boat dealer responsible for the ocean? Of course not. Today, the open source stack is like the ocean. It is the basis on which software products are developed. But it is not the vendor’s product.
That open source landscape now represents the backbone of the world’s information technology. So, when a customer demands that the vendor indemnify against IP infringement for this “product,” the customer is essentially making one vendor take responsibility for the entire technology landscape of the world.
Moreover, the customer probably already has all this software within its organization. It gets the open source stack from each of its vendors, as well as its own internal IT activity. The use of a product of one vendor rarely contributes more than a fraction of the marginal risk arising from the use of that software.
The UCC Gets this Right
There is a long-standing precedent for this view in the Uniform Commercial Code.
Unless otherwise agreed a seller who is a merchant regularly dealing in goods of the kind warrants that the goods shall be delivered free of the rightful claim of any third person by way of infringement or the like but a buyer who furnishes specifications to the seller must hold the seller harmless against any such claim which arises out of compliance with the specifications.
UCC Section 2-312(3)
Moreover, although the UCC does not expressly provide for this, it has long been market practice in technology contracts to absolve the vendor of liability for products that infringe only because they meet enunciated industry standards that both parties elect to use. This makes sense in light of the UCC. A customer would usually specify that it wanted to buy products that meet industry standards, and vendors will conform to industry standards because their customers demand it.
If we view the open source landscape as part of the customer’s specifications, and not the vendor’s build-or-buy decision, then it makes more sense for the vendor to avoid liability for the landscape. Alternatively, we can view the software landscape as an industry standard, for which neither the vendor nor the customer should undertake liability on its own.
But even if we can agree that the vendor should not be responsible for the software landscape, that doesn’t release us from the IP Question entirely, because we still need to understand where the vendor product ends and the landscape begins.
The Build or Buy Decision
For negotiating parties to solve the IP Question, they need to separate the definition of the vendor product from the software landscape stack. Of course, if the parties have settled on the exact stack to be delivered, the product and the stack can be listed ad hoc in their agreement. But for those seeking a more general approach, one useful point of reference might be the definition of “Linux” promulgated by the Open Invention Network (OIN). OIN is a patent pool covering Linux, but its definition of Linux is broader than merely the Linux kernel, and includes many of the major components in the landscape stack. https://www.openinventionnetwork.com/joining-oin/linux-system/
Even after the parties make that distinction, there will be some third party open source embedded into in the vendor’s product that is not part of the landscape. Examples might include small routines to do generic calculations, or libraries that are included in the vendor product executable. The vendor should be far more likely to accept liability for this software, given it has made more granular decisions to use these elements in its products.
Some Provisions for Your Toolkit
Below are some suggested contract provisions to help differentiate the vendor product from its open source landscape.
“Open Source Computing Stack” means any open source software created by third parties that is so referenced in the specifications for the computing environment of the Product in the applicable purchase order, which software may include operating systems such as Linux, web server software such as the Apache web server, language engines such as Java, PHP, Python or PERL, and database software such as MySQL. The Open Source Computing Stack includes without limitation all software included in the definition of a Linux System promulgated by the Open Invention Network.
Vendor will have no liability under [reference indemnity provision] for infringement of third party intellectual property rights by the use of the Open Source Computing Stack; provided, however, that the foregoing sentence will not limit Vendor’s liability for compliance by Vendor with the terms and conditions of the open source licenses applicable to the Open Source Computing Stack.
Alternatively, focusing on open source software already in use by the customer — which is likely to include much of the open source computing stack:
Vendor will have no liability under [reference indemnity provision] for infringement of third party intellectual property rights by the use of any open source software made generally available by third parties that is in use by Customer prior to the delivery of the Vendor Product hereunder ; provided, however, that the foregoing sentence will not limit Vendor’s liability for compliance by Vendor with the terms and conditions of the open source licenses applicable to such open source software.
