Reviewing Software License Agreements

A Licensee's Checklist

By: Howard G. Zaharoff
January 7, 2002

Often lawyers or contracts specialists are asked to give a "quick" review of an incoming license agreement on behalf of a prospective licensee. The following is a checklist and short discussion of the main issues the reviewer should consider.

License: Scope

The license granted should be sufficiently broad to permit the licensee to install and use the software on any (one or more) computer systems, copy it as required (including to execute the program and for reasonable backup), and (if appropriate) modify it as needed. (Rights to copy and modify should apply to the documentation, too.) If the license specifies a CPU, it should be clear that the program can be run on any single back-up or replacement CPU. (If the licensee maintains a separate development/support system and/or a backup site, be sure appropriate rights of installation, use, testing and/or adaptation are negotiated.) If the license specifies a location, it should be clear that the licensee may change the location (at least to anywhere within the United States and other predetermined locations) merely by notifying the licensor. (If they require notice to be given in advance, make sure that there is an exception for emergencies.)


The agreement should be clear on what the licensor will furnish (e.g. computer media containing the program in executable form and licensee documentation that is of sufficient quality and completion to enable a competent user to run the program). It should also be clear when these must be delivered.

Source Code

If the system is very costly, or if modifications clearly will be required and the licensee wants the ability to perform them, source code must be furnished. If that is not acceptable to the licensor, consider a source code escrow arrangement. Clearly define how the source code may be used — don’t assume the rights granted respecting the object code are sufficient.

Services Furnished

If training is required, the licensor's obligation to provide it (when and where) must be stated. Maintenance and support (fixes, corrected versions, new upgrades/releases, telephone consultation, online support and/or programming services) are almost always needed. Thus, either the agreement should spell out the licensee’s right to support, or a separate maintenance contract should be signed simultaneously, or the agreement should give the licensee the right to enter into a maintenance contract. See “Remedies” below. The availability of maintenance should be guaranteed for some minimum period, such as 3 or 5 years, with a fixed price, if possible — e.g. current prices increased no more than CPI or a fixed percentage (e.g., 5/7/10%/year).


The licensee should have the right to disclose the software not only to its employees and agents, but also to independent contractors whom it retains, as well as advisors and perhaps directors, investors and acquirers (subject to confidentiality). In some cases, disclosure must be made to the licensee's accountants and, in the case of banks, its examiners. Ideally the licensee's confidentiality obligation would be limited to informing these individuals thereof or, at most, requiring these individuals to observe confidentiality (without necessarily having to obtain signed agreements from all of them).

If a written non-disclosure agreement is required, approve the form in advance. (Computer professionals are often independent contractors rather than employees, and for certain companies their auditors and the like must have the ability to view the operation--in short, access by third parties may be essential, and third parties' reactions to non-disclosure obligations should be considered before agreeing to them in the license agreement.)

Make sure that certain standard exceptions from the nondisclosure obligations apply: public information, information disclosed by third parties, independent development, judicial process. Consider both a time limit (e.g., 5 years) and, provided you will not be disclosing critical data to the licensor, a “residuals” clause (exempting from these nondisclosure obligations information learned by employees and retained unaided in memory).

If the licensor will learn confidential licensee information, it too must agree to treat the information as confidential. If that information involves customer data, such as personal financial or medical data, consider whether the licensor must agree to any particular rules, such as compliance with Gramm-Leach-Bliley or HIPAA.

Open Source

Developers increasingly use open source components in their products. A problem may arise if a licensee obtains rights to modify and sublicense portions of a program which includes open source code, particularly open source licensed on the GPL model. Licensors of open source who follow this model require licensees distributing software containing that open source code to freely license the derivative product, even if it is comprised mainly of otherwise proprietary code (though there remains some debate about the enforceable breadth of such clauses). Therefore, before a licensee modifies or redistributes any licensed software, it must determine whether it contains open source code and understand what special terms may apply respecting distribution.


Unless the licensee is able to determine in advance that the system works properly (for example, by discussing the matter with, and observing the operations of, other licensees), there should be an acceptance period and a right to a refund if the system is not accepted. Similarly there should be warranties of functionality usually tied to a specific pre-disclosed specification, and a right to a refund if problems cannot be corrected during the warranty period (or beyond). (However, where the project includes substantial customization or other services, the licensor will be loathe to agree to refund the service fee — negotiation may be needed.)


The licensor should not be able to terminate on account of the licensee’s breach unless the licensee has notice and an opportunity to cure (typically 30 days). For certain key applications, the licensee may deny the licensor a right to terminate (except perhaps under extreme circumstances, and then only after substantial advance notice and opportunity to cure).


The issue of remedies must be carefully considered. Once a licensee installs a system, it may be very difficult or time consuming to exercise a right to revoke and receive a refund. Therefore, it is generally critical to obligate the licensor to use whatever efforts are necessary to correct problems.

In general the licensor should be required to address problems promptly; but it is reasonable for response times to be commensurate with the severity of the problem. Thus, ideally the licensor should agree to respond to, and commence efforts to remedy, a system down problem within a very short period (e.g., 1-2 hours); a serious impediment quickly but not as immediately (e.g., 4 hours); and other material bugs and defects reasonably promptly (e.g., 8 hour response and 24-48 hour correction). If correction can't be completed within these time frames, the licensor should provide a “work around," i.e., a temporary fix that enables the licensee to continue using the software substantially as anticipated. The licensor should also be obliged to use its continuing best efforts to correct the problem fully thereafter (though truly minor issues can be corrected with the next release).

Consider also seeking a specific “cover” remedy: that is, if the licensed product can’t be made to work properly, ideally the licensor would be obligated to pay the cost of obtaining and providing to the licensee a comparable working system. However, expect an argument over this, particularly if comparable products don’t exist or are extremely costly.

If the licensor seeks force majeure and consequential damage limitations (and often even if it doesn't), the licensee should demand similar protections. (However, if the licensor will have access to valuable confidential information, consider not waiving consequential damages for breaches of confidentiality, since consequential harm may be the main injury sustained when secrets are disclosed.)

Hardware: Integrating Responsibility

If hardware is included in the deal, make sure that the software and hardware warranties are coordinated and integrated with each other. If the hardware is recommended by the licensor but purchased directly from the hardware manufacturer, make sure that the licensor is obligated (at least secondarily) to correct problems or (at a minimum) to provide reasonable cooperation with the licensee, at no cost, to ensure that problems are remedied. (Beware of the finger-pointing problem and be sure that the licensee cannot get trapped between a software licensor claiming it's a hardware problem and the hardware vendor claiming it's a software problem.)


There should be a warranty against infringement and a workable remedy if infringement claims are made. Typically this means that the licensor will notify the licensee of actual or anticipated claims made against it or its customers and agree to indemnify and defend the licensee against any such claims. The licensee should have a right to participate in the defense at its own expense; it may also seek a right to assume control of the defense, perhaps also at its own expense unless the licensor has mishandled the defense.

Typically the licensor will have the right either to modify the program so that it becomes non-infringing, replace it with a non-infringing replacement (either of its own creation or furnished by a third party — thus the “cover” remedy noted above), or repossess materials and provide a refund. If such provisions are included, make sure that the modified or substituted software continues to satisfy the applicable specifications and that the refund is adequate (for example, it should not be a refund of only the amount paid for the particular software application or module involved if in fact this is an integrated system and the removal of any single component could render the whole far less utility to the licensee.)


Ideally the licensee would have the right to transfer the software in connection with its sale of the related hardware. At a minimum, it should have the right to assign the license (and maintenance contract) to any successor business.


Tax consequences must be considered. Many states tax product sales, including licenses, without taxing services. Thus, breaking out the services component of the fee may save the licensee local sales taxes.

For more information regarding software license issues, please contact Howard G. Zaharoff.