Escrow agreements are usually entered into to protect the licensee by providing access to the licensed software’s source code in the event of a “release event” or a “release condition,” meaning a condition by which the deposit materials would be released to the beneficiary of an escrow agreement. It can also be referred to as a “release trigger” or in the case of a SaaS relationship, a “Contingency Trigger Event.”
The most important issues when negotiating an escrow agreement are the release events and related procedures. Release events should not be limited to “failure to function as a going concern” (whatever that means) and “subject to bankruptcy.” A licensee should seek much broader rights to include better-defined bankruptcy-related events and an associated early trigger mechanism. The licensee desires the escrow release to occur pre-bankruptcy to avoid complications under bankruptcy laws, as well as default triggers under any service level agreement (SLA) and any other meaningfully linked agreements. Making the failure to meet an SLA a release event optimizes vendor relationships as the vendor knowing that a beneficiary could access its intellectual property will almost always garner better service levels and response times.
From the licensee’s perspective, the release should be automatic on the licensee’s command and not subject to a complicated submission process subject to the licensor’s authorization. “Notice Release Process” and “Demand Release Process.” Notice Release is the potentially complicated submission process subject to time and potentially dispute resolution, whereas a Demand Release by-passes this authorization. A Demand Release is hard to obtain when the subject of the deposit material is the Depositor’s (licensor’s) intellectual property. On the other hand, escrowed materials that represent little risk to the depositor like object code, which is impossible to reverse engineer, or data, then a Demand Release actually is a critical requirement to facilitate the beneficiary’s (licensee’s or subscriber’s) recovery time objectives, especially in a SaaS relationship.
The definition of a release event is one of the most important aspects of a properly drafted escrow agreement. To avoid future disputes and ensure that the licensee is able to promptly access the source code, it is important that the parties clearly define what constitutes a release event. Common release events include (i) a material breach of the license agreement (or SLA) by the licensor; (ii) the failure of the licensor to properly maintain the software or offer maintenance for a contractually agreed period of time (at least five years); (iii) the acquisition of or a change in control of the licensor; and (iv) the bankruptcy/insolvency of the licensor. Other potential release events include the time after an announced “de-support” date, the termination, or death of a key support person and an extended outage for SaaS.
A prudent licensor should ensure that the licensee does not have the unilateral right to declare a release event and trigger the release of the source code but instead the licensee should have a right to file a release request, but under the Notice Release Process. The licensee should not have Demand Release rights for access to the licensor’s intellectual property. In the event the licensee believes a release event has occurred, the licensee should be obligated to provide the escrow agent written notice describing the relevant event, and the licensor should have a reasonable time period in which to respond. If the licensor cannot show that a release event has not occurred or the licensor does not contest the licensee’s claim, the source code should be released. Conversely, if the licensor can show that a release event did not occur, then it can issue contrary instructions to the escrow agent to block the release. A well-drafted escrow agreement will also establish in detail the dispute resolution process in the event the parties dispute the existence of a release event.
From the licensee’s perspective, the licensee should have the automatic right to receive the source code once it files a claim with the escrow agent, without having to arbitrate or invoke the dispute resolution process. Most licensors, however, are unwilling to agree to such an automatic release. See e.g., Vemics, Inc. v. Radvision, Ltd., 2007 WL 1459290 (S.D.N.Y. May 16, 2007).
A savvy licensor will seek to include a liquidated damages provision in the event the licensee inappropriately uses/releases the source code. See Mid-Michigan Computer Systems Inc. v. Marc Glassman, Inc., 416 F.3d 505 (6th Cir. 2005) (licensee required to pay licensor $50,000 for each site using software in the event source code wrongfully accessed).
The License Grant
To protect itself in the event of the licensor’s bankruptcy, the licensee should ensure that the escrow agreement includes an actual license grant to the escrowed materials as opposed to an “agreement to grant” the licensee a license to the escrowed materials.
Subject to the terms of the Software License between the parties, Licensor grants to Licensee a limited, non-transferable, non-assignable license to use the Software solely for Licensee’s internal business purposes, provided that the rights granted under this Section x.x shall be exercisable only upon the occurrence of a Release Event.
Providing a present grant strengthens the licensee’s argument under 365(n) of the US Bankruptcy Code that the licensee can retain its license in the event the licensor seeks to reject such license, as Section 365(n) addresses only licenses in existence at the time of the licensor’s bankruptcy filing. An agreement to grant a license as of the time of a future event may be interpreted as a future grant and outside the purview of section 365 (n).