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.