Editor: Please tell us about your practice.
Nash: I’m a partner here at Norris McLaughlin. My practice consists mostly of corporate transactional work, and in the last few years, I’ve developed a specialty in technology contracting, including software licensing transactions. I represent clients on the licensor side, including software companies dealing in the health information and data management fields, which are two particularly hot areas. On the licensee side, I assist the firm’s general corporate clients in connection with their software licensing transactions and other technology-related matters.
Editor: How are software license transactions different from typical business contracts?
Nash: Often, lawyers with great transactional experience will negotiate a software license agreement as if it were a typical service contract, and focus on all of the typical pushback points. This is a good starting point, but software and technology contracting is highly technical and requires an additional level of analysis. The reviewing attorney must bear in mind that the software performs a function within the company, so effective contracting must integrate a technical understanding of how the software functions, how the company functions and how the two interrelate.
The software license agreement negotiation process involves areas of the client company in which the attorney may not have deep knowledge or experience. It reaches into the identification of risk factors based on the technical aspects of how the software functions and the licensee’s IT environment generally. A good grasp of these risk factors will play a critical role during negotiations in indentifying issues, creating work-arounds and resolving impasses. So from both an issue-spotting and a problem-solving perspective, counsel really needs to get into the nitty-gritty of how the relevant technology functions. Further, this knowledge must be applied to the implementation, support and service aspects of the software deal.
Unlike other contracts, software transactions require knowledge of a very specialized language and of a landscape that is constantly expanding as to the scope of software capabilities and the related services being offered. For example, cloud computing and software as a service (SaaS) were virtually unknown a few years ago, but now they are all the rage. In this constantly changing landscape, a lawyer will need to be able to speak (or at least understand) the jargon and have a general understanding of the state of the software industry. Even the most skilled general counsel may not have this specialized technology-licensing transactional experience, which can lead to a focus on non-issues and the misuse of leverage.
Editor: What are the typical pricing components in a software licensing transaction?
Nash: Generally, a license agreement will impose a license fee, implementation fees and support fees. These pricing components should be segregated, and the license agreement should be clear as to what each fee covers, when each fee accrues, and what variables and unknowns might impact each. When the licensee is buying a basic service package, the license agreement should be clear and precise as to what is included and what is considered “a la carte.” Also, the licensee should ensure that the vendor cannot charge extra fees for providing services already within the basic, pre-purchased service package. For instance, keeping the product performance in line with specifications is a fundamental aspect of the deal, not the basis for the imposition of additional service fees.
Typically, the IT or business people will negotiate the deal and then seek counsel’s help in negotiating the contract on the basis of the business terms agreed upon. The contract negotiation and drafting processes should include a dialogue among legal, business and technical folks to understand the fees and ensure there are no gaps or overlaps in the license agreement’s pricing components. Once counsel understands how the pricing works, he or she can push back where appropriate.
Editor: Let’s talk about cloud-based service offerings. What are they, and what are the key risk factors in transactions that involve them?
Nash: The term “cloud-based service” is really jargon for a computing concept that involves a large number of connected computers and data sources. Stated simply, cloud services generally consist of the hosting of information on the web, and companies have developed various services and product offerings based on this technology. Cloud services have become a major economic piece of the overall technology landscape, which in turn has led to the emergence of a specialized bevy of issues that the cloud service agreement must address.
The licensee’s counsel must be very familiar with the service itself, how it interrelates with the company’s overall operations, and all security and other risk factors. Data backups and disaster recovery are key components to any cloud-based service because company information typically does not reside on the licensee’s systems but is stored elsewhere. That information is likely critical to the company’s operations, and any loss would be catastrophic. Among other concerns, there could be a regulatory overlay, and mishandling or loss of information may lead to civil or criminal liability. So data security is critical, and there are certification bodies and auditing processes, for instance, that can mitigate risk and ensure that the encryption and data-security protocols meet current, defined standards. Naturally, it’s important to know those standards and be aware of when each might apply and the appropriate questions to ask in each context. It may be necessary for the licensee to insist on compliance auditing or other security standard monitoring.
It’s also crucial that the cloud service agreement clearly define performance levels and the scope of the service being offered. In a developing field like this, these concepts are somewhat malleable and difficult to nail down, and counsel doesn’t want his or her licensee clients to be disappointed when they compare the expected scope of the service against what is actually articulated in the agreement.
Editor: How does a licensee ensure that it receives appropriate levels of service and support?
Nash: The most important point here is for reviewing counsel to develop a full understanding of how the software functions and interrelates with the client’s business operations. The more essential the software function is to the licensee’s business, the greater the need to secure adequate support levels and response times. Key questions to ask include: what is the business and operational impact if the software becomes nonoperational, what are licensee’s commitments to its clients and customers, how long can the licensee live with the system down, and how quickly is a response required? These questions should be discussed with licensee’s technical staff to determine exactly what will work, and the contract should follow through on these discussions. Among other contract features that may be appropriate are response and resolution timelines, minimum performance standards and uptime guarantees.
Editor: Please discuss some of the typical licensor warranties.
Nash: To set the table on the issue of warranties, software licensors like to treat their software as the proverbial widget. They want to shift the product risk onto the licensee, essentially providing the software “as is” and disclaiming common-law warranties, such as merchantability and fitness for a particular purpose. On the other hand, licensees view the transaction as relating to the procurement of a particular functionality; they want to know what the software does and then negotiate for language that promises this functionality without condition or qualification. Right off the bat, you have a divergence as to the way each party is looking at the transaction.
As a top priority, licensees will want a firm warranty from the vendor that the software will perform in accordance with the documentation and specifications provided, free of material or frequent defects and with no undocumented features. Also important is a general quality-of-services warranty, which pertains to software performance that is in accordance with standard industry practices and in compliance with the applicable security policies and relevant law.
Another key warranty that is typically offered and generally worth insisting upon is a warranty that the licensed product does not infringe on any third-party IP and, further, that the holder is indemnified against liability arising from any such infringement. In appropriate circumstances, a licensor may also push for a warranty as to no viruses, no data destruction and no improper data alteration. Finally, the licensee agreement must provide a remedy in the case of a breach on any of these warranties. Licensee should ensure that any liability cap and waiver of certain types of damages are reasonable and appropriate under the circumstances.
The key is to understand which warranties are typically offered for the type of software at issue, how they work within the product or service being offered, and what the fine points of those warranties are likely to be. When you see a lot of these contracts, you start to develop pattern recognition as to what it is appropriate to ask for; if you’re asking for out-of-market warranties, then you’re wasting leverage.
Editor: Tell us about “planned obsolescence.” What does it mean, and how can a licensee protect against it?
Nash: Planned obsolescence is an approach to software development where the software vendor intentionally gives a software product a limited useful life. This has potential benefits for a software developer because to obtain continuing use of the product’s functionality, the licensee is under pressure to license again and again. One way this typically plays out is that a software vendor may refuse to support more than the few most recent versions of its software. Meanwhile, the software licensee might be perfectly happy with its now obsolete software, but may have to repurchase to maintain support. This creates a tension that should be carefully thought through and addressed in the contract. An equitable resolution of this tension will vary from case to case.
Editor: Where do you see the software licensing process heading?
Nash: It’s not really prescient of me to say that software is going to be integral to a company’s operation because this has been the case for some time. What you’re going to see is a continued expansion and constant innovation of software-related services offered over the cloud and through other similar platforms. One of the hottest areas is software-related data management, which allows companies to better aggregate, authenticate and utilize their data. Software is going to continue to be critical in the operations side of a typical company, but it’s also going to be increasingly important in the typical company’s business decision making process. These developments will not be without their challenges. Critical areas of concern include data security, the use and manipulation of data and the clear articulation of increasing and ever-changing software functionality and related services. These are all very dynamic and developing fields, and the typical transactional lawyer is well served in having a working knowledge of the basic concepts of software license contracting.
Published June 25, 2013.
