Posts in agreements
10 Common Pitfalls in Software License Agreements

Nearly every business will enter into software license agreements on occasion. A sophisticated, growing business may execute many such license agreements each month but a small manufacturer may do so only a handful of times each year. Many agreements for commercial, off-the-shelf software such as the Microsoft Office suite or company-wide antivirus software are often only reviewed briefly by the legal department, with the focus instead on commercial terms, pricing, and license rights.

But there are many software license agreements that deserve a careful legal review before execution. For example, those systems that are critical to the the day-to-day operations of business, where the cost for implementation and ongoing use is significant, software that will have a large impact on other business systems or employees, or those tied to financial reporting may all require additional scrutiny. But many in-house and even outside attorneys don't review software license agreements frequently enough to see the potential pitfalls that may be inherent in the vendor form agreements. This list provides a quick reference on what to watch for, although there are many other potential issues to consider in each individual transaction; it's not meant to be an extensive list of such pitfalls, but rather a quick reference to prompt additional review of important agreement terms.

/1/ License Scope

The licensee must closely consider the scope of the desired license. Whether it will be an enterprise-wide license, per seat license, or concurrent user license, the licensee must confirm the licensing entity and scope of use. For example, it may be desirable to allow affiliates of a parent company to use the software under the same license or allow the parent entity to use a license entered into by a subsidiary. In addition, it should be clear that the licensee's authorized third-party contractors and perhaps even outsourcers will also have the right to use the software without running afoul of the licensing terms.

/2/ License Overruns

The licensee should also consider what happens in the event the license scope is exceeded. This is not unusual in the case of a license scope depending on number of seats or named users. In that event, the licensee will want contract language that provides for payment by the licensee of the additional licenses but will want to minimize any punitive fees associated with unintentional excess use. Vendors often request audit rights to monitor the licensee's use of the software, which may be acceptable if properly worded, but should not be unduly burdensome on the licensee and should not trigger undue penalties for overuse.

/3/ Pricing for Renewal Terms

Software licenses often have initial terms of one to three years and it's imperative that the licensee contemplate and define pricing terms for any potential renewal terms. Consider the alternative: a potential scenario where the licensee has spent significant money and time choosing a software package, implementing the software, and training its employees and then the software vendor, after the initial three-year term, increases the price of the license by 200%. That leaves the licensee in a difficult situation and the legal and business teams facing a difficult conversation with upper management.

/4/ Acceptance Testing Rights

Any software implementation of any level of difficulty should include clear acceptance testing rights for the licensee. Ideally, the licensee should not be obligated to pay any license or support fees (and perhaps no implementation fees, depending on the particular circumstances) until acceptance testing has been performed and the software has passed the tests. Vendors will often point to the software warranty as the licensee's best tool to ensure properly functioning software, but that relies on the licensee then making a claim under the agreement for breach of warranty and may require formal legal action before resolution is reach. It's far better to hold the vendor's first payment in hand while confirming that the software performs as promised in the licensee's environment.

/5/ IP Indemnification and Limitation of Liability

Many times, software vendors omit any sort of indemnification obligation, exclude indirect damages from their potential liability, and cap their liability for direct damages. But the fact is that the party best suited to control and limit potential damages related to possible infringement of any third party's intellectual property rights by the software is the software vendor. Therefore, there should be a clear obligation for indemnifying the licensee in the event of claim regarding such possible infringement by the software or the licensee's use of the software and that indemnification obligation should be carved out from any limitation of liability or liability cap. There may be compromise language that is agreeable based on use of the software as described in the documentation and other exceptions to the indemnification obligation, but in the end the indemnification should be clear and comprehensive.

/6/ Warranties and Maintenance and Support

As I stated before, the software vendor will often point to the software warranty and perhaps support obligations when the licensee looks for a remedy related to the failure of the software to meet the requirements of the agreement. In addition to the acceptance testing rights, it's also important to confirm that the warranty and support terms are appropriate. For example, any language stating that the vendor need to only attempt to remedy any nonconformance should be scrutinized closely. If that warranty states that the vendor will use "best efforts" to address software bugs, then the licensee may end up with software that has unresolved issues for a very long period of time with the only remedy to argue that the vendor isn't using enough effort to resolve the issue. It's preferable to have language stating that the failure to resolve an issue that affects the licensee's use of the software will trigger certain licensee rights, including termination for cause if the issue is not resolved in an agreed period of time.

/7/ Termination Rights

The licensee should contemplate termination or expiration of the agreement and verify that the agreement reflects the licensee's wishes in either event. Depending on the type of software at issue, there may be a desire to have a data extract from the software prior to shutdown, the licensee may wish to engage the vendor in assisting with the transition to replacement software, or the licensee may wish to confirm that the vendor will destroy all copies of the licensee's data in its possession soon after termination or expiration.

/8/ Statement of Work

A statement of work that is part of the license agreement is frequently overlooked by the licensee's legal team. But it's imperative that the SOW be reviewed carefully both to confirm that there is no legal language that conflicts with the terms of the body of the agreement and to ensure that the business terms in the document are sufficiently detailed and measurable to clearly set forth the obligations of both parties. A vague statement of work or one that relies on the parties to work out the details following execution is of little value and does nothing to aid in the timely installation of the software.

/9/ Multiple Agreements

Vendor often rely on separate agreements for the license terms, installation services, and ongoing support services resulting in multiple separate agreements defining the relationship. This mahy be acceptable on its face, but the licensee should confirm that it has clear rights to terminate related agreements in the event one is terminated for cause or otherwise and the licensee should also consider carefully any limitations of liability or other limitations tied to the value of one agreement on its own.

/10/ Minimum Support Term / New Products

Lastly, although I've already mentioned ensuring that the support terms "have some teeth" related to actual resolution of identified issues and bugs, the licensee may also want to add language stating that the vendor will continue to support the software in the version provided to the licensee for some minimum period of time. Again, in this case, the licensee does not want to be in a position of spending considerable time and effort implementing a software package only to find the vendor is moving to entirely different solution in two years. Another consideration is whether the licensee should have the right to move to any replacement software during the support term; although that may be a less than ideal solution depending on what that transition to the new software entails.

As stated previously, this is not a comprehensive list of issues to consider addressing in a standard vendor software license agreement but rather provides a starting place that may prompt additional examination by an attorney who is otherwise unfamiliar with some of the unique intricacies of such licenses.

Tips on Drafting Vendor Form Agreements

My practice is tilted towards representing licensees and customers who are looking to license software from established software vendors. As a result, I have reviewed countless vendor software license agreements, hosted software/SaaS agreements, service level agreements, and all the related forms and attachments that make up those transactions. However, I also occasionally represent vendors and have assisted in drafting the vendors' form agreements.

In this article, I'll share a few things I've learned on the way by observing these transactions from both sides of the negotiation table.

/1/ Get the Business Team Involved Early

Drafting any new agreement involves considering and including a long list of contract boilerplate language; for example, limitations of liability, warranties, the license grant, venue, and termination rights. Of course, these provisions are necessary to include in the final agreement, but the vendor business teams must also be involved in structuring the form agreement.

The software teams should be involved in provisions related to warranties or service levels involving system availability, any third-party embedded software that may require additional licenses or terms, requirements related to the customer's technical environment, and similar areas. The finance department may wish to have input on the term of the agreement, invoicing and payment terms, and even acceptance testing language. And certainly the sales team will wish to get involved to ensure the agreement contemplates what their customers are typically looking in an attempt to avoid later roadblocks or objections.

/2/ Structure the Agreement to Make it Flexible

The attorney drafting the form agreement must consider the lifecycle of a transaction, which may include proposal responses to RFPs, product demonstrations, customer due diligence, and a number of discussions between the vendor technical and sales teams and the customer representatives. And these discussions all probably take place before any in-house attorney is asked to get involved.

One way to stay out of the way of the early deal negotiations is to provide the business teams with a flexible contract that gives them certain freedoms to change the agreement to reflect the unique transaction being considered. Putting a legal document in front of the customer early in the process may also bog down or sidetrack the process. Instead, consider structuring the main body of the agreement to contemplate some of the different requirements that may come from the customer and keep the business terms segregated into the exhibits. With the negotiable items like contract term, license scope, pricing over time, and delivery schedule all contained in the exhibits, the vendor and customer teams can work together to structure the agreed transaction details before needing to get involved in the details of the main body of the agreement.

/3/ Consider How "Aggressive" the Agreement Should Be

Another area that will involve discussions with the business and sales teams is how aggressive the vendor wishes to make the agreement. This will depend greatly on the negotiation strength of the vendor, the willingness of the legal and sales teams to support what may be a longer negotiation, and the generally view within the market for strict contract language.

If the vendor has a strong position in the market and an established reputation, they may be able to present a very aggressive agreement and hold firm during negotiation, allowing little change. On the other hand, sophisticated customers will consider the contract provisions as part of the overall evaluation of the vendor solution and, if there are other viable options to the vendor's software in the marketplace, an overly aggressive form contract may make the customer consider the relationship with the vendor a "non starter" and move to friendlier pastures.

/4/ Position the Document for Negotiation

The other side of the equation when considering how aggressive to draft the form agreement is to look forward to future negotiations involving the document and consider how the business would like those to play out. Obviously, an overly aggressive agreement will require additional negotiation time from the business, sales, and legal teams. Another approach is to consider drafting a document that is generally fair to both parties with the hope of positioning it in that manner with the customer and fast-tracking the negotiation which will involve only a handful of issues. Of course, the risk in coming to the table with a balanced agreement is that the customer may still negotiate the agreement intensely which may lead to a long negotiation anyway or an agreement that now favors the customer over the vendor.

agreementsKenny Hoeschen