This is the fifth 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.
Many licensees worry about the security of open source software. Does OSS in vendor products have vulnerabilities hackers can easily discover? After all, the source code is public. As discussed earlier (in the second post of this series), not everyone accepts this security concern. But that’s outside my bailiwick. The question here is, assuming OSS security worries you, what can you do in your contracts?
Standard Data Security Clause
As with copyleft concerns, a well-drafted tech contract should already protect the licensee. In other words, a good data management and security clause applies just as much to OSS vulnerabilities as to any other security flaw. That’s because data clauses generally cover all software provided by the vendor, including OSS. So all the normal promises should apply — covering encryption, audits, breach response, monitoring, etc. (See, for instance, the sample clauses in Part II-H of our Clauses library.)
Of course, a typical clause won’t help much if the vendor specifically excludes OSS from it promises. But I haven’t seen many vendors completely disclaim responsibility for OSS in their products. (The licensee’s response might be, “Is it your software or not?”) More often, the vendor excludes OSS that is not part of its product but rather runs alongside it. That’s particularly common if the vendor and customer chose the OSS together. “The requirements of Section _ (Data Management & Security) do not apply to any OSS that interfaces with the System, and Licensee recognizes and agrees that Vendor is not the provider of any such OSS and is not responsible or liable for its performance.” The vendor’s argument is that the OSS in question is not the vendor’s product, so it shouldn’t be responsible for it. That isn’t necessarily unreasonable.
OSS-Specific Terms re Data Security
Even if the licensee has typical data security terms, it can improve protection through OSS-specific precautions. For instance, a licensee can ask its vendor to declare any OSS included in its product. If you’re the licensee and you do that, you give your security team the information they need to assess the risk before you buy. You could also back up the request with contract language: “Vendor represents and warrants that it has disclosed all open source software included in the System as of the Effective Date. Vendor shall inform Licensee within 60 days if it adds open source software to the System.”
The licensee can also ask the Vendor to monitor OSS security. “Vendor shall exercise reasonable efforts to monitor news and online discussions related to the security of OSS included in the System. Vendor shall promptly address any security concerns revealed in such monitoring, pursuant to the standards in Section __ (Security Remediation).” Obviously, the vendor will wonder how much monitoring this sort of language requires and may want more specific and limited obligations.
OSS Security Indemnity
Licensees can also address OSS security concerns through an indemnity, of course. An indemnity would govern third party lawsuits triggered by a breach, rather than the breach itself. “Vendor shall defend and indemnify Licensee against any third party claim, suit, or proceeding arising out of, related to, or alleging disclosure or exposure of personally identifiable information or other sensitive information as a result of an unauthorized intrusion exploiting OSS included in the System.” With a clause like that, the licensee at least knows the vendor will defend third party claims triggered by an OSS data security flaw.
Data security indemnities, however, create a lot of problems. Vendors complain that the licensee could easily cause a security breach, even if the vendor holds the licensee’s data (e.g., in a SaaS relationship). What if the licensee leaks passwords or fails to protect computers accessing the vendor’s product? The vendor argues that it shouldn’t have to defend the claim. Some SaaS vendors, in fact, require that the licensee provide a data security indemnity protecting the vendor.
Unfortunately, there is no easy solution foir disputes about responsibility for data breach lawsuits. (The Tech Contracts Handbook discusses the problem in Chapter II.J.2.) So while a data breach indemnity might address your OSS security worries, don’t be surprised if you can’t get it done.
* * *
All in all, licensees should not view open source software as a threat. Focus instead on copyleft OSS — if you redistribute the software or provide it as a cloud offering. And even there, don’t view copyleft as a threat but rather as a limit on your freedom to commercialize software: a limit that might or might not cause problems. Focus also on data security — if you accept that concern. In most cases, I think licensees should view OSS as a potentially valuable part of their vendors’ product and address any concerns thoughtfully, without blanket rules forbidding open source.
[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.