David Tollen is one of the industry’s leading authorities on software licensing and cloud computing agreements. He’s the author of The Tech Contracts Handbook, a best-selling manual on the subject from ABA Publishing. And he’s the founder of Sycamore Legal, P.C., an IP and IT boutique law firm in San Francisco. David also runs Tech Contracts Academy™, offering a variety of services and tools to help businesspeople and lawyers understand, negotiate, and draft tech contracts. David has a wealth of experience in the IT agreement space and is works to help individuals better understand what a technology contract is and isn’t and the differences between types of tech contracts.
What first got you interested in technology agreements?
I started out in litigation at Morrison & Foerster, doing IP cases. I found I really liked negotiating the settlements. That didn’t instantly lead me to doing transactions instead of litigation, though. That came about when I worked on a very large matter involving both litigators and transactional lawyers. The transactional partners eventually invited me to joint their group, and I accepted. I guess I’d found litigation a poor fit. I loved appearing in court, but those opportunities were few and far between. Mostly, my work involved research and writing, and I wanted more action. Negotiating deals gave me that action.
As for landing in technology itself, that was really a coincidence. When I started at Morrison, that was the department that needed help. I’ve often said I’d be a real estate lawyer if I’d arrived on a different day. But technology was a great fit for me. I had always been pretty computer-savvy, and I immediately found my client’s work fascinating. That’s why I’ve stuck with IT for all these years.
Many states now have ethical requirements that lawyers be somewhat tech-savvy. What is your view of such requirements?
Lawyers do need to be tech-savvy. The key tools of our trade include e-mail programs, Microsoft Word, and document and data management systems. We need to use them well both to do our jobs and to protect client confidentiality. In fact, in the training programs I teach through Tech Contracts Academy, I advise students to become masters of MS Word, particularly at redlining. You can’t negotiate a long written contract without redlining expertise—without the skills to see exactly what changes the other side has proposed, without confusion and mistakes generated by versioning issues.
I actually co-authored a paper on technology and legal ethics, with a great professional responsibility attorney named Phil Brown. You can view it on the website for my training business: Is Technology a Threat to Attorney-Client Privilege?, https://techcontracts.com/2017/04/20/technology-threat-attorney-client-privilege/.
What is the number one tip that you can share for lawyers negotiating a technology agreement?
Put aside your lawyer hat for a little while and learn the business and technology issues at stake behind each clause. You have to understand the business advantages and disadvantages of the language you’re negotiating, or you’re just spinning your wheels. In other words, you don’t negotiate for a warranty that software will work because contracts should have warranties. You argue for it because it provides a useful remedy for a potential business or technical problem. And if the problem doesn’t concern your client/company, or the remedy won’t help much, the warranty is low priority.
To negotiate that way, you have to understand the business: what the software will do, how failure would impact operations, how remedies would help (or not), what other business objectives shape the deal, etc. Too many lawyers focus on “legal” issues and simply try to eliminate risk, without understanding that a practical business and technology consideration lies behind all those issues and risks. This sort of practical negotiating is one of the key skills I teach in my trainings.
Second place probably goes to knowledge of indemnities: learn how indemnities work. In my experience, indemnities are the most contentious terms in IT contracts, usually because the parties misunderstand what they’re negotiating.
A lot of lawyers, even highly experienced ones, seem to confuse or conflate a software license agreement with a software as a service (SaaS) agreement. Why do you think that is the case?
You’re right, and I’ve written about that too. (Don’t Use License Agreements for Software-as-a-Service, https://techcontracts.com/2018/06/01/dont-use-licenses-saas-contracts/.) People hear the word “software” and think “license.” Yet SaaS agreements don’t call for a license, since the customer doesn’t get a copy of the software. Rather, they get a right to access and use the software—neither of which calls for a copyright license. In fact, it’s a mistake for vendors to grant licenses to their SaaS systems, since they may grant the customer broader rights than they intended—more than just access to the software.
Behind the error lies a misunderstanding of technology. People work off of a traditional on-premise software licensing “script,” without realizing they need a new script since the technology works in a different way. On-premise software deals resemble SaaS deals in many ways, but you’ve got to understand the differences to do a good job.
How have technology agreements changed since you first started writing/speaking about them and training lawyers in how to draft and/or negotiate them?
When I began in the mid-90’s, most of the clients were tech companies, and most of the software was on-premise: the vendor gave the customer a copy to run on its own computers. Both have changed. While there’s still lots of great work representing tech vendors, software has become so central to the economy that any large company buys it regularly—and lawyers doing tech deals may serve customer clients just as often as vendor clients. At my firm, Sycamore Legal, about half our work is for customers, while half is for vendors.
Also, cloud computing has come to compete with on-premise software, and that’s led to a rise in concerns about data security and privacy. Those topics play small (or smaller) roles where the customer runs the software on its own computers and keeps the data there too. But in a cloud deal, the customer’s data sits on vendor computers. So, we’ve all had to become data and privacy lawyers.