The basis of open source risk lies in the fundamentals of how software is built these days. Many of the code bases Black Duck audited this year comprised more than half open source. Combine that with the fact that most companies don’t track or manage it very well, and you have a concerning basis for a range of risks. Black Duck educational materials often connect the dots to the implications for software development and M&A due diligence, but open source risks are an issue worthy of attention in any contract negotiation involving software.
In a recent Black Duck webinar, David Tollen delved into this topic. David is a California attorney who trains a lot of other lawyers and literally wrote the book on the topic of technology contracts. His Tech Contracts Handbook is the top selling ABA Intellectual Property publication. It was awesome to get his perspective on how to think through the implications of open source in software in a contract negotiation.
David’s approach was very practical. He stepped through the standard, general clauses you’ll find tech transaction agreements using template language. He outlined how they apply to open source risk and how the language may need to be tweaked in places to more specifically address open source. His narrative unfolded a bit like a story. He started talking about IP indemnity and how even general language should cover copyleft lawsuits. With the question, “but what if the licensor loses the suit?” he introduced the need for an IP Warranty and then extrapolated to warranty remedies, and so on.
The focus for this webinar was mostly on IP, however, David also spent a good time discussion language around security and data protection (huge topics in the wake of Equifax and with the advent of GDPR). And, while the focus was a little more tilted towards buyers, he always counter-pointed from the vendor’s perspective, suggesting where middle ground might be reached.
Much of contracts are, of course, about risk allocation. And risk stems from the unknown, so contract negotiations are most contentious when, as is too often the case these days, no one really knows what open source is in the code. Both parties can have a more grounded discussion if the seller has an accurate open source bill of materials to which it can represent. If everyone is confident there are no copyleft-licensed components in the code, for example, there is much less tension around the IP discussion.
Vendors with proper open source management policies, procedures and tools should tout that aspect of their “whole product.” Absent that, a code audit can get everyone on the same page with respect to open source risk.