Picking up where we left off yesterday, below is the remainder of our quick checklist of issues that customers should consider in any software licensing agreement. Today’s items include more traditional legal issues to add to those issues contained in our previous post, which were more business or operational in nature.
- Warranty/Ongoing Support: Does the license come with a warranty that can be leveraged in lieu of the first year’s support? When do the warranty and support services each start? How is ongoing support contracted for? Are the license and support rights separate?
- Compliance with Specifications Representation: Is the vendor committing to compliance with specifications? Is the commitment limited to substantial or material compliance? Consider how the “immaterial” issues are addressed. Are the software descriptions in the contract and/or the vendor’s published documentation included in this commitment? Are there specific remedies for non-compliance (repair, replace, refund)? Are any exclusions from this representation, such as those for breach and combination use, narrowly tailored?
- No Disabling Code: Check to see that the agreement contains a warranty that the software does not contain time-bombs, worms, viruses, or other code that might be used to deactivate or disable the software or the company’s systems. Is the warranty given only at the time of delivery or does it continue throughout the support term? Are there any knowledge or materiality qualifiers that limit the warranty?
- Open Source: Ideally, any open source or similar publicly available software incorporated into the software would be specifically identified in the documentation and reviewed by the customer as part of its vendor due diligence. Does the use of open source comply with your internal open source policies? At a minimum, the agreement should include representations by the vendor that the software will be free from any “viral” open source software (e.g., a GNU general public license) that could result in obligations for disclosure of the source code or free licensing of the software or any software used in connection with the software.
- Non-Infringement Warranty/Indemnity: At a minimum, does the agreement require the vendor to indemnify the company for third party infringement claims? Does the provision cover all infringement claims or is it limited to certain claims (e.g. valid US patent or copyright claims)? Are any exceptions to the vendor’s indemnification obligation narrowly tailored? In addition to the indemnity, is a non-infringement warranty provided that would allow for the company to seek a repair or replacement remedy and/or direct damages?
- Bundled Products: Are any other products bundled with the core software the customer is licensing? If so, are they the vendor’s other products or are they provided on behalf of a third party supplier? Do additional terms and conditions apply? Does the agreement disclaim any or all responsibility for those bundled products? Are they covered by the other representations and warranties? Indemnities? At a minimum, the company should receive a pass-through of the warranties and indemnification available to the vendor from the supplier of any bundled third party products.
- Warranty Disclaimers: Confirm that any warranty disclaimers do not contradict the express warranties provided in the agreement. Any broad or potentially contradictory disclaimers should be qualified with “except as expressly set forth in this agreement.”
- Ownership of Modifications/Add-ons: Will you be modifying, configuring, or creating add-ons/bolt-ons to the software? Under the agreement, who owns, and has the right to use, modifications, configurations, and add-ons/bolt-ons? Are any such modifications/add-ons likely to be specific to this vendor’s software and of limited utility outside that context? Are there any that provide a competitive edge or investment? The customer should read the definitions of software and the IP rights carefully. Often, if the customer makes the change, you think that you own it. Beware, though, some agreements pull modifications into the definition of the product without reference to who created or was responsible for the modification. Also, some agreements have notification requirements regarding changes that may be administratively burdensome.
- Liability: Are limitations of liability reciprocal and commercially reasonable? Be mindful of any absolute disclaimers of responsibility or liability. Ensure that typical carve-outs—breaches of confidentiality or data security obligations, non-infringement provisions, indemnification obligations and gross negligence, willful misconduct or fraud—are included from each of the disclaimer of damages and liability cap as necessary to address the risk associated with the vendor and software use case.
- No Other Terms and Right to Change Terms: Always check to see if all terms are included in the contract you are reviewing. Be wary of links and references to other documents that are not attached. A statement that any click-throughs or links are expressly not applicable often is a good idea. Also think about how the vendor can change terms. Some forms allow the vendor to unilaterally change the terms with notice. As licensing models evolve, vendors look to evolve their licensing terms. Customers, on the other hand, generally seek the right to approve changes (at least material ones!) to the contracting terms, or to qualify the vendor’s right to incorporate changes that materially alter the current terms and/or reduce the customer’s current rights and remedies under the current terms.
This post is part of our recurring “Contract Corner” series, which provides analysis of specific contract terms and clauses that may raise particular issues or problems. Check out our prior Contract Corner posts for more on contracts, and be on the lookout for future posts in the series.