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 make the licensee distribute its own product under the open source model, thanks to copyleft software contributed by the vendor? No court has actually ordered “specific performance” of a copyleft license, so we don’t know if it’s possible. But if so, a replacement or refund won’t compensate the licensee. The losses could be vast if open source doesn’t fit the licensee’s business model.
An open source warranty with limited remedies, then, should worry the licensee. The solution is language saying any limit on warranty remedies does not apply to copyleft claims. For instance, the licensee might insert the following after a warranty/remedies clause: “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 turns the licensee’s own product into OSS, the loss may count as consequential damages. And you can bet that loss will exceed the dollar cap. So the licensee wants language like this: “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.”
Of course, vendors don’t like exceptions to their limits of liability. As a compromise, you could remove the limit on consequential damages but keep the dollar cap, though with a higher figure.
© 2018 by Tech Contracts Academy, LLC. All rights reserved.