Software Licensing & Master Service Agreements : Chicago Software Licensing Lawyer & Attorney : Sam Conforti Law Firm : Master Service Agreements, Negotiations, Outsourcing : Cook County, Illinois

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.

• Email This
• Print
• Comments
• Trackbacks
• Share Link

I found a very good White Paper on Cloud Security entitled Cloud Security Myths and Strategies Uncovered. I think the best way to start off is with the opening quote from the White Paper itself:

“In today’s evolving information economy, cloud computing offers immense opportunity. Whether companies have started their cloud journey or not, security concerns remain the largest inhibitor to adoption. Concerns around control, data privacy, and security abound. However, the technology and expertise required to build a trusted cloud is closer than imagined. Progressive CSOs are embracing a new strategic role as a true business enabler in partnership with business leaders, to make sure that the trusted cloud becomes a reality and enterprises can capitalize on cloud technology.”

Security concerns still abound with Cloud Computing and a fair number of adopters still opt for a private cloud environment. However, there is a trend towards a more hybrid approach, allowing enterprises to take advantage of the cost saving a public cloud provides. A majority of IT professionals surveyed indicated that their top priority was managing access to the data in the cloud. The White Paper suggests that “Virtualization” provides better visibility than the older legacy systems.

The White Paper then lists the three major Myths about Cloud Computing and provides the answer that debunks each one:

1.       The Cloud simply cannot be secure - YES IT CAN.

2.       Cloud Security is a new challenge – NO IT’S NOT.

3.       Compliance equals security – not necessarily … it is only an “as of” date.

The authors state that a successful and secure Cloud is one that has “Trust” as its foundation. The Trust Equation is as follows:

Control + Visibility= Trust

Control

·         Availability: Ensure access to resources and recovery following interruption or failure.

·         Integrity: Guarantee only authorized persons can use specific information and applications.

·         Confidentiality/privacy: Protect how information and personal data is obtained and used.

Visibility

·         Compliance: Meet specific legal requirements and industry standards and rules.

·         Governance: Establish usage rights and enforce policies, procedures, and controls.

·         Risk management: Manage threats to business interruption or derived exposures.

The White Paper goes on to say that the key to obtaining the visibility needed to control the Cloud is Virtualization. “Virtualization consolidates multiple physical components into a logical view so they can be administered from one place. This alleviates the complexity of managing and monitoring multiple moving parts across internal and external infrastructure.”

When it comes to building a trusted cloud, Checklist for Your Trusted Cloud is as follows:

·         Use virtualization as your foundation.

·         Build control and visibility into your security framework.

·         Extend your security perimeter to include applications and endpoints.

·         Adopt the three-layer controls framework: controls enforcement, controls management, and security management.

·         Select a cloud vendor with offerings that can meet enterprise-class cloud security requirements across private and public clouds.

·         Ensure services are secured to a common standard, in a transparent and auditable fashion.

·         Tap prescriptive guidance from industry coalitions such as the Cloud Security Alliance (www.cloudsecurityalliance.org).

• Email This
• Print
• Comments
• Trackbacks
• Share Link

As I have discussed in several articles in this Blog, the concern over security has been a huge hurdle for most enterprises when considering whether to adopt Cloud Computing. There also is the simply reticence to change. David Needle discusses this in his article in ServerWatch entitled HP Pushes ‘Instant On’ Vision of Enterprise Cloud Services and explores an ingenious response to the resistance to change developed by HP. Perhaps the best way to describe this new development in Cloud Computing is to call it a hybrid approach. HP also offers the consulting services that will assist the enterprise to implement and manage these services. Needle’s article is peppered with quotes from Sandeep Johri, vice president of enterprise strategy and industry solutions at HP, and from a company spokesman. I think the fastest and most direct way to describe this approach and the services to implement it is to read exactly what they say about it. Here are some select quotes and you can make the determination if this could be the game-changer for the adoption of Cloud Computing:

“Part of our vision is about transforming old applications, not necessarily to the cloud, but to make them more available using new frameworks that can be accessed as a service.”

“We think the cloud needs to be more than the standard definition of on-demand services.  An enterprise needs a level of security commitments and service quality commitments, among other attributes we believe are necessary.”

"The cloud can be something you use to augment other parts of your business.  For example, for some of our airline customers we do 'ticketing as a service.' Those companies get billed on a per passenger basis and they don't get billed for servers -- the backend infrastructure is all handled by HP.

"From an instant-on perspective, an airline might just want the ticketing aspect, which we let them get right away without buying new infrastructure, but they may also want to keep a lot of other IT functions in house, and this program lets them do that."

"We do medical claims processing for 20 states in the U.S. and we get paid on a per claim basis. We process over a $100 billion in claims every year," he said. "We don't call it software as a service, but that's effectively what it is.”

And on the hybrid delivery services that implement this approach:

"This offering provides clients with a patent-pending, model-driven framework to introduce hybrid delivery concepts into their existing environments.”

"The optimal architecture for the enterprise is a hybrid architecture, not everything is moving to the cloud or staying in-house.  At the end of the day, IT needs to deliver services and some of those are best delivered in-house in a traditional single-tenancy environment, some in the cloud and some outsourced. We believe HP can bring optimization across multiple dimensions.”

• Email This
• Print
• Comments
• Trackbacks
• Share Link

It has been a very busy 1^st quarter closing and I have not been able to post an article in a while. I cannot really explain the business activity other than to recognize that there is a “business cycle” and despite stimulus packages or not, our economy was going to emerge from the recession sooner or later. From the depths of the economic woes, it appears the economy is emerging later rather than sooner. There is a pent-up demand out there, for example durable items still have a tendency of wearing out and needing to be replaced. As far as software licensing and the consulting agreements needed to implement the software, procurement departments had been under a short leash, but projects are starting to come online.

In the interim, Houston Neal, Director of Marketing at Software Advice, has collected all the results of his survey on the ERP Implementation Strategies in use and presented them in an updated version of his article entitled ERP Implementation Strategies – A Guide to ERP Implementation Methodology (see my posting in this Blog immediately below). The results may be of interest and assist in your decision making process and which path to take. Neal has also inserted an interesting commentary section from the respondents claiming their implementation failed. Here is a quick glance at those results from the 45 respondents:

“Of those that answered “No,” we received the following comments:

“Logistics problem (visa issue delay, user delay for data collection, delay in top management support).” – Phased Rollout

“We are still under the progress of phased manner, only “Materials and Finance” is under parallel run and they’re facing some bugs/modifications.” – Parallel Adoption

“Still running both systems in parallel, 3 years later!” – Parallel Adoption

“1 year late, although all other success parameters achieved.” – Big Bang

“Concentrating on tools not architecture.” – Big Bang”

• Email This
• Print
• Comments
• Trackbacks
• Share Link

Houston Neal, Director of Marketing at Software Advice, is conducting a survey on ERP implementation strategies. Specifically, which implementation strategy (big bang, phased rollout, or parallel adoption) has the best success rate.

You can find the survey in his article entitled ERP Implementation Strategies – A Guide to ERP Implementation Methodology.

• Email This
• Print
• Comments
• Trackbacks
• Share Link

Last year, April 19, 2008, I posted an article entitled Is a Clickwrap Agreement Enforceable?. The article defined the terms and gave a general understanding of where we encounter these types of agreements. My editorial comment dealt with my “natural aversion” to the non-negotiability of such agreements. Based on the number of hits the article receives, it is easy to discern the interest in the topic and it seems appropriate at this time to augment the article with a “How To” approach. During the course of my research, a colleague of mine from my days at SAP, Patricia A. Dalki, discussed her views on the subject. Patricia has done the heavy lifting on researching the “How To” approach when drafting  such an agreement and has kindly shared her thoughts on the subject with me. Her research included an article by David L. Hayes of Fenwick & West LLP entitled, The Enforceability of Shrinkwrap License Agreements On-Line and Off-Line and she also cited an article I had included in my original posting mentioned above by Jason Haislmaier entitled, How Do I Build an Enforceable Online Agreement? – Not (Always) the Way SalesForce.com or Google Would.

With the kind permission of my friend and colleague, Patricia A. Dalki, here are some tips how to create an enforceable on-line agreement:

 1.  Record Evidence of User Acceptance

• Record evidence of user acceptance and the formation of each on-line agreement using a consistent, auditable process.
• By procedure – maintain evidence that the only way to access the service or product being offered is to scroll through terms and click “I accept” – user must have accepted.
• To the extent possible, keep records of time, date, and source of acceptance.

2.  Require Acceptance Before Delivery of Services or Payment

• Require acceptance before payment or delivery of the services.

3.  Make Rejection Clear and Simple

• Provide a clear, simple method for customers to reject the contract.
• Allow users to exit the process at any time.
• Do not require the customer to take additional steps or expend effort/money to reject the product or service.

4.  Make Assent Unambiguous

• Secure an affirmative, unambiguous manifestation of assent to the agreement from the customer.
• The more the customer has to do, the better.
• Examples include:

a.         Mouse click “I accept” or “I agree” button;
b.        Type “I agree” and submit (speed-bump for users, but more deliberate);
c.        “I accept” checkbox next to each provision, especially with an unusual or onerous provision; and
d.        Offer alternative “I don’t agree” option with an explanation that the user cannot use or access the product or service.

5.  Condition Use on Acceptance (covered in the introductory paragraph)

• Expressly state the user’s access to or use of the product or service is subject to these terms.
• Expressly state that you will not provide the product or service except pursuant to these terms.

6.  Provide Notice of All Terms

•  Draw attention to the on-line agreement.
•  Make sure the customer sees it, e.g. no “below the fold,” small print, or hidden text.
•  Place the “Accept” option at the end of all terms.
•  Require the user to scroll though all terms before making the acceptance action.
•  Consider requiring the user to check an “ I accept” box for each provision, especially for an unusual or onerous provision.
• No link to terms or scroll boxes
• Advise user to print and keep a copy of the agreement.

• Email This
• Print
• Comments (1)
• Trackbacks
• Share Link

Software vendors can increase their revenues during this prolonged recession.  How do these vendors make lemonade out of this lemon of a global economy?  They must look to their installed customer base.  Mike Smerklo, President & CEO of ServiceSource, has written an OpEd piece for SandHill entitled Delivering Predictable Revenue Streams.  ServiceSource is in the Service Performance Management business which aims to increase their clients’ service revenues by increasing the number of customers on maintenance and increasing the dollars spent on maintenance.

In economic downturns, such as we are now experiencing, customers defer new product purchases.  Although this is not a positive for software sales, it does increase the value that can be placed on enhanced maintenance and support services.  Software companies must continue to invest for the next generation of products, but enhanced maintenance today can drive revenue and provide the reliability that customers need.

Smerklo cites a Gartner study that the potential market for maintenance and support is over $180 billion annually and that only $150 billion is spent on maintenance every year.  It is easy to see that there is another $30 billion in potential maintenance and support not being tapped.  He increases our lexicon from the more familiar term “market share” to a new term he labels “service share”.  This is the total maintenance revenues available from the installed base.  And he lays out for us a complete 4 part service management strategy as follows:

1.     Technology Platform:  The vendor’s CRM must measure transaction data on the maintenance side down to the granular level.

2.     Business intelligence:  The analytical capabilities of the vendor must be able to show what the customers are buying and why some are saying no.

3.     Customer contact:  Must have the ability to help the customer extract the most out of their solutions.  This will enhance the relationship and could pay dividends down the road on renewals and purchases of new product.

4.     Benchmark against the competition:  Need to know your specific service metrics in comparison to the industry overall.

The Service Performance Management alternatives are as follows:

1.     Do Nothing:  All focus on product revenue and market share can come back to bite you especially on renewals.

2.     Build your own service management platform:  This could be costly.

3.     Partner with a Service Management Performance provider:  They have the expertise and the capabilities to manage on a global basis.

• Email This
• Print
• Comments
• Trackbacks
• Share Link

This article is meant only to posit the question above in relation solely to an existing Master Service Agreement (“MSA”).  For a very good discussion of the Parol Evidence Rule please see Scott Unger’s article What Is The Parol Evidence Rule?  Unger covers all the bases in his article.  He provides the pertinent citations where the court explains the purpose behind the rule and he also cites case law discussing the policy concerns supporting the rule. 

"The Parol Evidence Rule is a substantive rule which states that whenever contractual intent is sought to be ascertained from among several expressions of agreement by the parties, an earlier tentative agreement will be rejected in favor of a later expression that is final."

Or more succinctly

"the final agreement made by the parties supersedes any terms discussed in earlier negotiations"

Unger also points out that a good draftsman should always include a “merger clause” in the contract.  This is usually a clause found near the end of a contract, probably in a miscellaneous section, simply stating that the agreement is the final and complete expression of the parties to the agreement.  It is there to aid the court.  What should also be found in that merger clause is a statement allowing for modifications to the contract.  The language should read something similar to the following:

“This Agreement may be modified only by a writing signed by both parties.”

Let’s now consider the question above in the title of this posting.  When asked to make an adjustment to the MSA, one automatically thinks of an amendment or perhaps a Statement of Work (“SOW”) if that is how changes are contemplated.  A change can also be easily accomplished through a Project Change Request (“PCR”) form if such a form was contemplated in the initial MSA and suits the desired change.  These are all standard ways to change the original MSA.  However there are times when your client requests a change be accomplished through a Side Letter.  And so the question we must ask is, “Why?”  This is of course a red flag to the attorney.

First you must assure yourself that there is no fraud involved.  At the slightest hint of any fraud the attorney must stop at once.  The next steps are quite involved and I direct you to the Model Code of Professional Responsibility.  I am not an expert in this area, however I did come across a very interesting article by Boris Feldman entitled WHAT TO DO WHEN YOU FIND THE SIDE LETTER: GUIDELINES FOR CEO’S, CFO’S, AND AUDIT COMMITTEE MEMBERS IN INVESTIGATING ACCOUNTING FRAUD.  Feldman lays out a step-by-step approach which could be very helpful.

So absent fraud, the question remains “Why a Side Letter”.  I do not think there is a definitive answer to this question.  In my experience it could be that business people are more comfortable with a side letter.  It could be the “that is the way we do business” mentality.  There could be a distrust of lawyers and contracts.  Also the lawyers are usually seen as placing roadblocks in front of the deal and so for expediency sake the business folks prefer a letter.  In their minds it is quicker and easier.  Of course there is the ever popular notion that the cost would be prohibitive.  A more formalized document just looks more costly.

One’s knee jerk response might be that the Parol Evidence Rule prevents the introduction of such a Side Letter in the event that a dispute regarding the Side Letter finds itself in the courts.  But as Unger correctly points out, the exclusion of all evidence of discussions or agreements purporting to change the existing agreement pertains to prior writings and expressions.  I also have seen that the exclusion applies to all prior and contemporaneous writings.  In the question I posit above I state that the MSA is an existing agreement; and therefore, the Side Letter contemplated is a subsequent writing.  The mere fact that the date of the letter is later than the effective date of the MSA should be sufficient to allow the Side Letter into evidence to prove the modification.  However may I suggest the following:

• First and foremost assure yourself that no fraud is involved in the request.

• Absent fraud, then insert an “incorporation by reference” clause into the contract. This should allow the multitude of protections existing in the MSA to be applicable to the matter discussed in the Side Letter. It could be as simple as “This letter is hereby annexed to and made a part of the Agreement specified above.”

• Insert an Acknowledgement at the end of the letter after the signature block. I usually use the following language, “Please acknowledge your acceptance of the above terms by signing and dating this letter in the spaces provided below and returning a signed original to me at the address as provided above.” This helps us meet the “…may be modified only by a writing signed by both parties” language that should be found in the merger clause.

I’d like to know what you think. Have you encountered this type of request? Does the incorporation by reference and the use on an acknowledgement suffice? Is there more that needs to be inserted into the Side Letter? Should we simply say “no” to any Side Letter?
 

• Email This
• Print
• Comments
• Trackbacks
• Share Link

I have stated in an earlier article, Checklist Before Outsourcing Your IT, the high value I place on the use of a checklist before drafting an agreement. It is also obvious that a tool such as a checklist can provide invaluable assistance to the IT Project Manager when preparing for the implementation of a newly purchased software suite. In my research I have found a very interesting article in Wisconsin Technology Network News, WTN News, by Richard Marcus entitled Six things to consider before a major software implementation. Marcus presents a very useful list in his March 2006 article. Admittedly this article is over 2 years old and in this fast-paced high-tech environment the concept of what is “new” and what is “old” takes on different meanings from our traditional understanding of the terms. However, I believe his advice stands the test of time regarding this subject matter.

Marcus begins his article by cautioning the buyer on the critical nature of the purchase and that concentrating solely on the pricing could be a perilous mistake. He then provides his six points that the purchaser should take into account before forging ahead with the implementation. A brief synopsis of these six crucial points is as follows:

• The Software Vendor and the Customer are partners in this undertaking. Both parties must bring their knowledge and skills together in a committed relationship. Success depends on having sufficient resources. The Vendor should already have their team ready and the customer should have a comparable team prepared to spend the estimated time needed for the project. See also the February 15, 2008 post to this Blog, The IT Worker Shortage: Practical Considerations for Tech Buyers. 

• Communication is key. Insist that the Vendor set the correct expectations. Talking is not the only art form in this communication process. Listening is essential. Ask questions and let those answers lead you to more questions. Strive to learn not only what the software can do, but also what it cannot do. In the past, I was a consultant for a large software vendor. As a newbie on one of my first implementations, I learned the catchphrase consultants were often overheard to say to the customer when discussing the software’s capabilities, “The salesman said it could do what?” Make sure your requirements are well known and can be met.

• Pricing. Marcus’ admonition above is still valid. Price is not the only factor, but it is still a factor nonetheless. Negotiate a payment schedule that is tied to clearly defined and identifiable milestones that are realistic. Holdbacks dependent on successful acceptance test results should be discussed and inserted into the contract. Too much money upfront surrenders too much influence to the vendor. I was interested to read that Marcus warns the reader not to be swayed by the software vendor’s pleas and worries about revenue recognition. In my career I have discussed this many times, but only in a software license agreement negotiation. A Master Service Agreement is usually a time and materials agreement and hence revenue can only be recognized as it is earned. A Fixed Fee arrangement is a totally different case and will be a topic for a separate post to this Blog.

• A separate Master Service Agreement should be drafted. Marcus points out that it is common for the license agreement itself to contain sections pertaining to services such as ongoing support and maintenance. However, these services are not directly related to the implementation. I have come across license agreements that purport to contain the implementation services section within the license. This should be avoided. His article deals with a major implementation and so most major software developers and vendors already have their contract model set up to have a separate license agreement and a separate Master Service Agreement. This is the preferred approach. An implementation section contained within a license agreement may not address all the salient points of an implementation and also may not be clear and unambiguous on other necessary elements.

• The Master Service Agreement should contain Service Levels. This is a very important item and one that should not be overlooked. A service level agreement (“SLA”) can take the form of a separate schedule attached to the license agreement. Alternatively and depending on the complexity of the requirements of the customer, a separate SLA may be more appropriate. In the SLA the customer should make certain that all of its requirements that were fleshed out during its communications with the software vendor (see point 2 above) are memorialized for future reference.

• Know the use limitations in the license and plan accordingly. Many software licenses are User based pricing. Many vendors are willing to provide some form of price protection for future purchases of users. The Customer should verify that no further implementation work will be needed if more Users are added. However, if the Customer is faced with product based pricing and is not purchasing the entire software suite of products, then further implementation work will be needed if more products are added. This possibility should be fully explored and the consequences understood in the event of future growth.
  

Marcus concludes his article by stressing that the Customer must do their due diligence on the front-end. With proper planning the Customer can avoid mission-creep and other costly mistakes. Once a major implementation is set in motion it becomes cost prohibitive to put a complete stop to it or redirect your efforts towards another project.

• Email This
• Print
• Comments
• Trackbacks
• Share Link