Source code escrow arrangements can be a contentious topic in software license negotiations. Vendors are reluctant to make their proprietary source code available to third parties, while customers are concerned about business disruption if the vendor goes out of business or otherwise stops supporting the software. Below, we have outlined some key issues to consider and address when negotiating for the source code escrow remedy. We will continue this list in a post next week.

Is release an effective remedy?
Given the amount of time that often goes into negotiating for source code escrow provisions with vendors, before requesting this remedy, customers should consider whether they would want to, or would be able to, effectively use the source code once they receive it. Customers may choose not to negotiate for source code escrow if (a) they do not have, or do not want to engage, in-house expertise and other resources necessary to host and maintain the code themselves and/or (b) there are other solutions available in the marketplace that the customer could transition to if needed.

What are the key issues when negotiating source code escrow provisions?

Assuming that you move forward with negotiating a source code escrow remedy with your licensor, the following are some key issues to consider and address:

  1. Deposit Materials and Requirements to Update. Aside from the source code to the software itself, customers may need the software documentation and other necessary programming instructions to be deposited into escrow by the vendor. If customers do not already have the object code for the software (e.g., in a hosted solution), they should consider the need to obtain both the source code and object code for the software. The vendor should be required to keep all of the escrow deposit materials current (e.g., updating the deposit materials on a defined frequency or within a defined period of time following the issuance of each software update).
  2. Release Events. Release events, when the deposit materials are released to the customer, are often the most contentious point of escrow negotiations. Vendors typically seek to limit the definition of release events to bankruptcy or otherwise ceasing to operate. However, customers may need the deposit materials to support the software themselves if the vendor materially breaches its maintenance and support obligations (and fails to cure the breach within a specified period of time following notice of the breach). Other release events may be negotiated as deal-dependent. For example, if a customer relies on a vendor’s software solution to stay compliant with changing laws, the vendor’s failure to update the software as needed for such compliance may be another release event if the failure is not cured.
  3. License Grant. When it comes to the source code license grant itself, one technical drafting point is to structure the license grant as a “present” grant, i.e., not a promise by the vendor to grant the customer a license right in the future. See the distinction:
    1. Vendor hereby grants to Customer, exercisable solely upon the occurrence of a Release Event, the right and license to use and modify…(present grant)
    2. Vendor shall grant to Customer, solely upon the occurrence of a Release Event, the right and license to use and modify…(future grant)

Using a “present” grant better protects a customer’s right to retain its license rights against an enforceability challenge under bankruptcy law. Section 365(n) of the U.S. Bankruptcy Code protects licensees by allowing them to retain their license rights, even if, in connection with a bankruptcy of the licensor, the agreement is rejected by the debtor or trustee as an executory contract. However, section 365(n) applies only to license rights that existed prior to the bankruptcy’s commencement. A grant that may be construed as a future grant could present an enforceability challenge, and, therefore, the “present grant” structure is recommended.