2. Basic Licensing Checklist

The following is a basic checklist of key issues and questions to be considered in almost every software licensing transaction:

Has appropriate due diligence been conducted on this vendor? Depending on the size of the transaction, due diligence may range from site visits at other licensees to requests for financial data to simple Internet searches of trade publications for mentions of the vendor.
What is being licensed? Does the agreement clearly define the applications being licensed?
Does the license agreement define what the software is supposed to do, not merely refer to the vendor's "then current documentation"?
Does the licensee have any specific performance requirements for the software (e.g., the ability to interface with other systems, exchange data with other software, achieve certain performance levels)? If so, are those requirements included in the agreement?
Who is the "licensee"? Is "licensee" defined broadly enough to encompass all possible users of the software being licensed?
What is the scope of the license? What are the limitations on the licensee's use of the software? Does the scope of the license include all intended uses of the software?
What fees are due under the agreement? What is the projected yearly cost of operating the software? Have all possible revenue streams been identified (e.g., license fee, support fee, interface fees, customization fees, professional service fees)? Are there limitations on future fee increases? How are support fees calculated?
What is the term of the license? Is this a perpetual license or a term license? If a term license, how is the agreement renewed?
What is the expected useful life of this application to the licensee (e.g., how long does the licensee expect to be using this application)?
If the licensee has unique specifications, interoperability requirements, functionality for the software, have those specifications been expressly included in the agreement?
Is the software subject to acceptance testing? If so, how will acceptance testing be conducted?
How long will it take to implement the software? Is there a formal implementation plan? Does the implementation include objective milestones for the vendor to achieve? Are payments tied to those milestones?
Does the vendor place the source code for its software into escrow with a third party? Who is the escrow agent? Has a copy of the escrow agreement been provided for review?
What warranties are provided? Are any special or unique warranties required for this application (e.g., performance in accordance with regulatory requirements like the Health Insurance Portability and Accountability Act, Gramm-Leach Bliley, etc.)?
What are the vendor's support obligations? Is there a separate support agreement or, preferably, is support integrated into the license agreement? If this is a critical application, are there specific service levels for responding to support calls? How long is the vendor obligated to support the software?
Will the vendor have access to any proprietary or confidential information of the licensee and/or its customers? If so, have appropriate confidentiality and security provisions been incorporated into the agreement?
What indemnities has the vendor provided (e.g., intellectual property infringement, personal injury, damage to property, breach of confidentiality, etc.)?
What is the limitation of liability? What types of damages are excluded or limited? What is the overall cap on liability? Is anything excluded from the limitation of liability (e.g., indemnity for intellectual property infringement, breach of confidentiality, etc.)? Who is protected by the limitation of liability?
Can the licensee assign the agreement to a successor entity or an affiliate?
Does the licensee currently intend or does it reasonably foresee in the future the need to outsource operation of this application to a third party?

The foregoing is not intended to be an exhaustive list of all potential issues, but rather a listing of some of the key issues and questions that should be explored in every transaction. The list should be viewed as an organic document. The reader should expand the list to include issues that are unique to its organization as well as issues that it identifies as important based on its experiences in reviewing and negotiating its own software licenses. By making the list its "own," the reader will have developed a valuable resource for its enterprise.