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.

 

Is Software Patentable

 

Recently, I was attending a get together of some old school friends from my youth. We try to see each other every once and a while. I was chatting with a friend of mine and invariably the question is raised “Well Sam, what is it that you actually do”. Having fielded this question before I said, as I have many times in the past, “I negotiate and draft contracts for the licensing of software and I also draft the consulting contracts to implement that software”. My friend, who is a software engineer and a very intelligent man, countered with “I thought you couldn’t get a patent for software”. He relayed his experience of 15 years hence writing code for software games and not being allowed to patent the algorithms. Well, he had me back on my heels and flat-footed. I wasn’t sure how to answer him. I relied on my experience as a Law Professor and being asked questions where I did not have the answers at my finger tips. The secret is to ask rhetorical questions in a sort of Socratic manner and get to the answer. I did not feel comfortable at first stating definitively that “Yes, of course software can be patented”. My discomfort came from the knowledge of asking this very question in the past and not getting a conclusive and authoritative response. So I began asking the questions and stating that when I draft a software license and I am representing the buyer I include indemnification language to protect my client similar in tone to the following:

“Seller shall indemnify Buyer against all claims, liabilities, and costs, including reasonable attorneys' fees, reasonably incurred in the defense of any claim brought against Buyer by third parties alleging that Buyer's Use of the Software infringes or misappropriates any United States patent; a copyright; or trade secret rights, provided that: such indemnity shall not apply if the alleged infringement results from Use of the Software in conjunction with any other software, an apparatus other than a designated apparatus, or unlicensed activities and so long as Buyer promptly notifies Seller in writing of any such claim and Seller is permitted to control fully the defense and any settlement of such claim as long as such settlement shall not include a financial obligation on Buyer.   Seller may settle any claim on a basis requiring Seller to substitute for the Software alternative substantially equivalent non-infringing programs.”

And when I am representing the Seller I include language in the license to protect my client that limits its liability for any claims of patent infringement with language similar in tone to the following:

“Buyer's sole and exclusive remedies for any damages or loss in any way connected with the Software furnished by Seller, whether due to Seller's negligence or breach of any other duty, shall be, at Seller's option: (i) to bring the performance of the Software into substantial compliance with the functional specifications; (ii) re-performance of services; or (iii) return of an appropriate portion of any payment made by Buyer with respect to the applicable portion of the software or services. Seller will not be responsible under this Agreement if the Software is not used in accordance with the documentation; or (ii) if the defect is caused by Buyer, a Modification, third-party software, or third party database. ANYTHING TO THE CONTRARY HEREIN NOTWITHSTANDING, EXCEPT FOR DAMAGES RESULTING FROM UNAUTHORIZED USE OR DISCLOSURE OF PROPRIETARY INFORMATION, UNDER NO CIRCUMSTANCES SHALL SELLER, OR BUYER BE LIABLE TO EACH OTHER OR ANY OTHER PERSON OR ENTITY FOR AN AMOUNT OF DAMAGES IN EXCESS OF THE PAID LICENSE FEES.”

So this little exercise helped me to raise my confidence level in order to respond to my friend that yes in the US software is patentable. But just why is there such an open question on this issue. There is no definition of software from the US patent office.   As of today in the US it is readily accepted that software embodied in a physical computer readable medium and aiding an innovative process or machine is considered patentable. If you seek such a patent you must “subtly claim the software as employing or performing certain functions or processes and as embodied in a computer readable medium”. Please see http://ezinearticles.com/?A-Soft-Introduction-to-Software-Patents&id=593392

“Software patents have a very recent history as the first software patent granted was in 1981, in the legal case of Diamond v. Diehr. The claimed invention is a heat treatment of rubber, wherein software code is employed to compute the optimum time duration for the treatment. In another case of State Street Bank & Trust v. Signature Financial Group, a software business method was granted a patent in the year 1998, redefining software patentability. Software patentability has been a topic of debate world over. The first question an inventor, who wishes to patent his invention, asks is "Is software patentable". The short answer is that the US patent office does grant software patents, and there has been a surge in software patenting in the US.” Id.

In my research I found some very interesting facts.

·         A classification of software patents is virtually nonexistent, although a majority of recent patents are software patents based on the above criteria and

·         There are about 1400 patents purely on computational software.

·         IBM possesses 31,995 US patents.

·         HP possesses 21,000 patents worldwide as on 2003.

·         Microsoft possesses 5000 US patents.

·         Siemens possesses more than 10,000 issued and pending US patents.

·         In the USPTO database there are about 25,123 claimed software patents and about 284,978 granted patents that disclose the use of software in their inventions.

For further reading on this subject please see several articles listed at the following URL http://ezinearticles.com/?expert=Ash_Tankha

Please note that the above discussion is on US patents only. In Europe this is still an open question. See European Patent Office quiet on whether software can have a patent. And in Asia and the rest of the world it is anybody’s guess.

 

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.