This is the third in a series of five posts on Open Source in Software Procurement. Click here for the prior post, and click here for the intro, which lists all five topics.
Fear of open source software leads licensees to draft terms like this: “Vendor warrants that the Licensed Software does not include open source software.” In most cases, that’s just silly. Excluding OSS altogether is (a) sometimes impossible, (b) often a bad idea, since it means developers have to write more code from scratch, and (c) usually unnecessary. This post looks at better ways to draft an open source warranty. It focuses on the licensee’s IP worries: the copyleft issue described above. (The fifth post in this series — coming soon — looks at the licensee’s security worries.)
Open Source Warranties
For a licensee planning to redistribute its vendor’s software, the best protection is an open source warranty that specifically addresses copyleft. Here’s the language suggested in The Tech Contracts Handbook: “Vendor represents and warrants that the Licensed Program does not include software subject to any legal requirement that would restrict Licensee’s right to distribute or otherwise provide the Licensed Program, or any modification thereof: (a) for a fee, (b) with or without source code or source code rights, or (c) with such restrictions as Licensee sees fit to place on its customers’ modification or distribution rights.” That addresses copyleft head-on.
But don’t panic if you’ve already executed licenses without that language. Typical IP warranties arguably forbid copyleft software too, even without copyleft-specific terms. For instance, here’s the generic IP warranty from The Tech Contracts Handbook: “Vendor represents and warrants … that it has and will maintain the full power and authority to grant the intellectual property and other rights granted in this Agreement without the further consent of any third party.” How does that address copyleft? If the contract grants the right to redistribute the vendor’s software — without the open source model — then by including copyleft software in its product, the vendor breaches that warranty. That’s because the vendor would not then have authority to grant the full IP rights listed in the contract. The typical IP warranty isn’t as clear as the copyleft-specific version above, but in many cases, it should do the trick.
An open source warranty, however, is only the first hurdle. The licensee also needs to think through its remedies.
Open Source Warranty Remedies
For breach of an IP warranty, the vendor usually promises (1) to replace the infringing software, (2) to get a license so the licensee can keep using/distributing it, or (3) to refund the licensee’s money (“replace, license, or refund”). In most cases, the licensee gets no other remedies. But if a copyleft problem really blows up in the licensee’s face, those remedies might not be enough. What if a court orders the licensee to stop distributing its own product until it removes the copyleft code? What if removing that code requires massive re-engineering? The loss of business and engineering costs could be staggering.
An open source warranty with limited remedies, then, should worry the licensee. In many cases, there is no solution except extra caution: trying hard to choose careful and responsible vendors. But some vendors will agree to contract terms addressing the problem: language saying any limit on warranty remedies does not apply to copyleft claims. For instance: “The remedies listed in the preceding sentence are not exclusive of others Licensee may have at law or in equity for a breach of warranty that has the effect of restricting Licensee’s right to distribute its own software products without source code or without the right to modify or distribute.”
Open Source Warranties and the Limit of Liability
The licensee’s real obstacle, however, is not restricted remedies but rather the limit of liability. Limits of liability generally (1) impose a dollar maximum on the vendor’s liability and (2) rule out “consequential damages.” If breach of the copyleft warranty forces the licensee to stop distributing its own software product or forces it to write the copyleft code out of its product, the loss may count as consequential damages. And the damage could easily exceed the dollar cap. Again, there may be no contractual solution, since few vendors will waive their limits of liability. But where the vendor is flexible or the licensee has a lot of leverage, a narrow exception can address the problem. For instance: “The provisions of Section 12 (Limit of Liability) do not apply to any breach of warranty that has the effect of restricting Licensee’s right to distribute its own software products without source code or without the right to modify or distribute.”
If the vendor won’t go for that, the licensee can try a compromise: remove the limit on consequential damages but keep the dollar cap, though with a higher figure.
Click here for the next post in this series.
[minti_divider style=”1″ icon=”” margin=”60px 0px 60px 0px”]
David Tollen is the author of The Tech Contracts Handbook, the American Bar Association’s bestseller on IT agreements. He is an attorney and the founder of Sycamore Legal, P.C., a boutique IT, IP, and privacy law firm in San Francisco. His practice focuses on software licenses, cloud computing agreements, and privacy. And he serves as an expert witness in litigation about those same topics. Finally, David is the founder of Tech Contracts Academy and our primary trainer.
© 2018 by Tech Contracts Academy, LLC. All rights reserved.