Does Your Source Code Escrow Agreement Achieve Its Objectives?

Raleigh – It’s a common mantra: “You’re a small software company; how do we know you’ll be around next year? If we license your product, we need to know we will have access to your source code if we need it. You need a source code escrow agreement in place. You know, put your source code in escrow with a third party to be released to us under certain circumstances.” A source code escrow agreement (“escrow agreement”) is also often requested by inexperienced license negotiators using a form checklist of what should be included in a deal. The potential licensor, wanting to make the license sale, capitulates and agrees to enter into a source code escrow agreement, often one that contains terms unrelated to the licensee’s stated purpose. This is not to suggest that source code escrow agreements do not have an important place with respect to licenses for certain software products, especially software for large and mission critical products, but the escrow agreement needs to be drafted to fit the specific objectives of the licensee.

 

Under What Circumstances Should the Source Code Be Released?

The most important provisions in a source code escrow agreement are those that specify the events which, if they occur, will result in a release of the source code from escrow to the licensee. Interestingly enough, these are also the provisions in the agreement that most often are drafted incorrectly, perhaps because they are taken from a form checklist rather than by thinking through the details of how to achieve the objectives desired by the parties. There are many events that might be specified in the escrow agreement as potentially triggering a release of the source code from escrow, the most common being the licensor failing to maintain the software, ceasing to do business, or declaring bankruptcy. It is important, however, to look at the reasoning behind each potential release event to determine whether it makes sense within the context of a specific escrow agreement. The following question always should be asked: What is the ultimate objective of the parties?

If the licensee’s objective is to ensure continued maintenance of the software, do the terms in the escrow agreement correctly provide for this or are they drafted such that they could result in an unnecessary release when the licensor’s maintenance obligations are, in fact, being met? Instead of focusing on specific release events, the parties should concentrate on providing adequate explanations as to how to determine when the required maintenance obligations are not being met.

For example, if the licensee contends that ensuring continued maintenance of the software is one of its objectives, is this objective actually consistent with the factual circumstances of the license arrangement? In many instances the licensee insists that it does not need to enter into a maintenance agreement or, after entering into one, later determines the agreement is no longer needed. Why then, after the licensee has elected not to have maintenance provided, should the licensee have a right to use the source code if the licensor ceases to offer maintenance? A correctly drafted escrow agreement would provide for a release of the source code from escrow for a failure to provide maintenance only if the licensor actually has an obligation to provide maintenance. It should be irrelevant that the licensor ceases to provide maintenance or support or to update the software in any way if the licensee has no right to receive such services. As odd as it seems, however, it is quite common to see escrow agreements provide for a release of the source code from escrow if the licensor ceases to offer maintenance, despite the fact that the licensor has no legal obligation to provide it to the licensee and the licensee has no right to receive it.

Further, a provision in the escrow agreement allowing a release of the source code if the licensor ceases to do business could, depending on the circumstances under which the cessation occurs, result in a release when it is not needed to meet the parties’ objectives. For example, a licensor may sell all of its assets to another business “as a going concern”. Similarly, the licensor may merge into another company. In each instance, the original licensor has cease to do business, but the software maintenance is being undertaken by another party.

Finally, many (if not most) bankruptcies are unlikely to result in events that justify a release of the source code from escrow. If the licensor files for bankruptcy under Chapter 11 of the Bankruptcy Code, the company continues to operate while the debt is reorganized. Similarly, under Chapter 7 of the Bankruptcy Code, even though there is an entire discharge of debt, the company often continues in operation under court-ordered supervision until the assets are sold, after which time the buyer provides the required maintenance. 

Other Terms in the Escrow Agreement

In addition to precise release terms, the escrow agreement also should address what will happen if the licensee believes a release event has occurred and upon release of the source code.

Normally, licensees simply want to give notice of the release event and then have the source code released to them immediately. If the release terms are well drafted and specific so that there is no issue as to whether the release event has actually occurred, this may be acceptable. On the other hand, if the terms are vague (e.g., “failure to provide adequate support”), the licensor should, before release, have the opportunity to object if it has a good faith dispute that a release event has occurred. Either way, the escrow agreement needs to provide for immediate written notification to the licensor of any release request made by the licensee to the escrow agent.

Another major issue is what the licensee can do with the source code upon its release, especially if there is no chance for the licensor to object to the release before it occurs. Clearly, the escrow agreement must provide that the source code and all whole or partial copies made of it must be returned to the escrow agent if the circumstances resulting in the release cease to exist. Further, the escrow agreement must state that, upon any release, the source code may be used only to maintain the software, and that there can be no sublicensing or transfer to any third party.

The escrow agreement should provide that if there is a periodic or usage-based license fee and the licensee continues to use the software, the payments should continue. If the licensee has the right to use the source code to create derivative works, the escrow agreement should specify what can be done with the derivative works and whether additional payments are due if such works are licensed to third parties. The escrow agreement also should address exactly what is to be placed into escrow and on what medium. It is also important to provide how often the escrowed materials are to be updated and what supplemental materials may be required (such as installation instructions or third party licenses). The parties need to decide whether verification of the escrow deposit will be required and, if so, then the escrow agreement should include terms indicating who is to do it and what tests are to be run to ensure that the escrowed materials are what the licensee expects to find if there is a release. 

The Complete Agreement

There are many issues that must be considered when preparing a well-drafted and complete escrow agreement, not all of which are addressed above. For example, who will pay the escrow agent, what happens if the payment is not made, when will the escrow agent be liable if it improperly releases the source code, and what happens if the escrow agent wants to resign? Overall, it should be clear that a “one size fits all” escrow agreement does not fit all. The terms of an escrow agreement cannot be taken from a form checklist, but rather need to be carefully and thoughtfully drafted in detail to ensure that they accomplish the intended objectives of the parties.