So You Want to Negotiate A High-Tech Deal

 

I have been practicing law for approximately 25 years and concentrating my practice in the area of negotiating and drafting contracts for the purchase or sale of High Technology for the last 13 years. I recently came across Mark Grossman’s guest blog posting in IP In Brief entitled, “A How-To Guide for Negotiating Tech Deals”. This is a must read. If you are considering making any high-tech purchase, I highly recommend that you take the time to read this article in order to gain an insight and perspective that is little discussed but impacts your deal greatly. As a practitioner in this area, I found myself one early Saturday morning sitting in my office reading Grossman’s article and shouting “Yes, Yes, Yes”. I was fist-pumping and if anyone was near to me they would have gotten a high-five. His approach is straight-forward and no nonsense.

Andrew Berger’s introduction sets the stage and reveals to the reader for the first time the concepts of “unwritten industry norms” and “choreographing your concessions around areas where you’re not likely to win the battle anyway”. Grossman starts his analysis by pointing out the obvious (i.e. the first drafts of the agreements are poorly written). I think this was my first “Yes” that I heard myself say out loud while reading in my office all alone. I can’t tell you how many times I’ve received new templates or first drafts of proposed new agreements which were simply a mishmash of cuts and pastes from older useless documents. My second “Yes” and my first fist-pump was Grossman’s admission that the sales teams are in charge of the deal. I freely admit, and in the spirit of full disclosure I happily accept that the sales team is the entity that brings the deal to me. Without them I would be out of work. However, Grossman points out, without actually stating it, that the sales team views the attorney as an obstacle that must be overcome. Perhaps it was the way he explained the process of requesting a revision to some contract language to more accurately describe the issue and then commented,

“All the while, I can feel the sales team seething at me because of my absurd requirement that the contract accurately state the deal”.

That comment garnered fist pump number two and a loud chuckle. I would have enjoyed it if Grossman had discussed the mirror image on the buy side. I have represented both Buyers and Sellers. By the time the deal comes to me from the buy side (i.e. the Project Team), there is what is commonly called a “love affair” with the functionality of the proposed software package. In essence the Project Team “has been sold” and they know that they cannot live without having this software in their repertoire.   As an attorney, I get that same glare from the Buyers when revisions for clarity are requested.

Grossman has a very salient section on the “Norms in the Industry”. To put it simply, why waste your time arguing points that will not be changed. These “Norms” need to be understood simply due to their peculiarity. He has an excellent section explaining Warranties in the industry and how they differ from what would be expected. Limitations on Liability is another section worth reading because it goes against what a Buyer expects and readily requires from its vendors. I must confess it was good for me to read these sections simply because I have been so inculcated with these industry “Norms” that I needed a refresher on why outsiders would consider these absurd.

He concludes his article by stressing the practical side of mutuality. A software vendor can and usually does readily accept revisions to sections to make the obligations mutual. One must remember that the parties are usually starting from paper that was first drafted by the vendor and so the natural urge to make the language one-sided must be addressed and overcome where possible.

 

Checklist for your Software License Agreement

 

Once again I have been the beneficiary of an excellent lead due to my membership in LinkedIn and the group Software Licensing ProfessionalsJennifer Junitz Keenan was kind enough to share a link to an article written by Steve Mullins in which he reported on a white paper by Budd Larner of the The Technology Executives Club. The article is entitled Top Ten License Negotiation Concerns, and oddly enough Mullins points out at the outset that the Budd Larner white paper actually contains twelve (12) points. This article is directly on point to one of the stated goals of this blog “… to discuss software licensing and … the legal nuances involved in the contract negotiation process …” I thought it an excellent idea to share the link with my readers and also to provide a brief synopsis on the salient points as follows:

1.       Clearly define the Licensee: The article does not discuss in-depth the importance of this first point, but allow me to point out the need to consider Affiliates and Subsidiaries and providing use rights to such entities.

2.       Use Rights for necessary third parties: Larner points out that “Scope of Use” is the most important part of any license. I suggest that you not rely on the licensor’s blanket representation that other necessary third parties may have access, but rather call out specifically those that are known to you such as lawyers, accountants, banks, and other financial investors without limiting your right to add others as they become apparent.

3.       The use of Addenda to revise the base agreement: Here Larner presents both agreements on whether to use addenda or not. I have seen both methods either an almost complete re-write of the base license agreement or the addition of amendments, riders, schedules, and other forms of addenda. A good lawyer should be able to function in both worlds. Realize that the license will be revised. Discuss the revising process with the licensor upfront and proceed accordingly.

4.       Include Representations and Warranties: Develop procedures to track your warranties.

5.       Include Maintenance & Support Obligations: Often these result in a separate agreement. Whatever the form, make sure all obligations are clearly defined.

6.       Have an Indemnification provision broad enough to cover any patent infringement: Also include language to cover any liability caused by use of the software.

7.       Insert Carve-Outs to any Limitation of Liability clause: Except out breaches of confidentiality and indemnification.

8.       Have an Internal Dispute Resolution clause: Such a clause clearly defines the process and procedure to notify the other party of a discrepancy and how it will be resolved. The procedure usually has stages and time limits for varying degrees of executives within each organization. I find this more apropos in MSA’s (i.e. consulting agreements and their accompanying SOW’s) rather than in a software license agreement.

9.       How to Terminate and is the License Perpetual: How does this affect maintenance and note any language on renewals and the necessary notice provisions. Who carries that burden?

10.   Definitions: Define ALL key terms. Not sure about the placement of this section. I am more comfortable with it being placed in the front, but I have seen it placed in a section in the back and/or a separate schedule. This is a matter of drafting preference.

11.   Is the Audit provision reasonable: Make sure it is done in a non-disruptive manner and limit the times it may be conducted and sufficient notice must be provided the Licensee.

12.   Number of Instances allowed and effects of partitioning and dual processing: This is the point that I call in the “techies” and they tell me exactly what they want and what they know to be fair and standard in the industry.

Obviously this is not an inclusive checklist, but I think it will get you started and act as a valuable aid in your negotiations.