3. Customers Lack Expertise to Use the Released Source Code

Even if the customer has been diligent and the released source code is properly updated, well-documented and fully operational, most customers lack the resources or capability to utilize the code upon release. In most cases, source code has been escrowed because customers are licensing software from a vendor that is providing technology and expertise the customer does not possess internally. Thus, once the software is released from escrow, the customer often is in no position to properly implement the software, train its employees on maintaining and supporting the software, or purchase the necessary hardware and third-party software. In addition, this process of bringing such software in-house can be lengthy and demanding on a company's resources. Further, the customer will likely be faced with a shortage of available talent knowledgeable on the released software, especially because many software license agreements prohibit customers from soliciting the vendor's employees upon termination of the licensing arrangement. All of these factors combined make it extremely difficult for a customer to utilize source code upon release, even if the code is in pristine condition. The only alternative for the customer is to hire a third-party software company. This is an expensive alternative and is often no better than moving to a substitute product. Furthermore, with this decision, the customer is back to where it started—relying on a third party to properly maintain the code.

4. Significant Delays and Legal Battles Often Accompany a Release

Another problem is that software vendors have the ability to prevent the timely release of the escrowed code and customers have limited recourse to prevent such a delay. It is not unusual for an escrow agreement to require the vendor's approval before the source code is released; thus, even if the customer demands the escrow agent to release the software upon a release event, the escrow agent is prohibited from doing so until it receives the approval of the vendor. Delays in the release of the software are problematic because vendors may not keep the software properly updated during the period of time that the parties are disputing its release.

Adding to the delay, escrow agreements often require parties to participate in alternative dispute resolution proceedings, such as arbitration or mediation, in the event of a dispute regarding the release of the source code. A commonly disputed issue is whether a release event has actually occurred. Although parties strive to clearly and completely define the triggers for a release of the software in software license agreements and escrow agreements, the language in these agreements may be ambiguous as to whether certain circumstances qualify as a release event. Therefore, the vendor can almost always dispute that such an event has occurred. A prime example of this can be found in the recent court case between Vemics, Inc. and Radvision, Ltd. (Vemics, Inc. v. Radvision, Ltd., No. 07-CV-0035, 2007 WL 1459290 (S.D.N.Y. May 16, 2007)). In this case, Vemics purchased a software license from First Virtual Communications (FVC), and the parties entered into a license agreement requiring the software to be placed in escrow and released upon specified release conditions. The parties also entered into a separate escrow agreement with the escrow agent, Iron Mountain. FVC filed for bankruptcy on March 11, 2005, and Radvision became the successor in interest to FVC's rights and obligations under the license agreement and escrow agreement with Vemics. Vemics demanded Iron Mountain to release the source code in January 2006 claiming FVC's bankruptcy constituted a release event. Interestingly, even though parties typically enter into source code arrangements to, at a minimum, protect the customer's interest in the software in the specific event of the vendor's bankruptcy, Radvision argued that FVC's bankruptcy was not a valid basis for release of the software. More than two years have passed since Vemics demanded the release, with the parties still at odds over whether the source code will ever be released. Even if it is finally released, the long delay and expensive legal battle have been a costly investment for Vemics.

5. Utilizing an Escrow Can Be Expensive

Another obvious cost consideration is that the expenses related to the opening and maintenance of an escrow account are typically borne by the customer. These fees can amount to thousands of dollars. In addition to the fees paid to the escrow agent, the customer will often incur significant legal expenses related to the drafting and negotiation of escrow agreements. Software developers are resistant to provide their source code to anyone in fear of inadvertent or unnecessary release. Therefore, escrow arrangements are often intensely negotiated. However, these legal expenses pale in comparison to those the customer will be forced to spend if the vendor disputes the customer's claim that a release event has occurred. The costs of resolving such a dispute can range from thousands of dollars in alternative dispute resolution proceedings to hundreds of thousands (or even millions) of dollars in protracted litigation. A point of great frustration for customers is that these added costs will not change the fact that the customer has no assurance the source code is useable and has little control over the time period of release.

For these reasons, customers should consider whether it makes sense to ever enter into source code escrow arrangements. Despite their appearance of importance, source code escrow arrangements are almost completely ineffective at protecting customers from failing software companies and carry with them significant costs and risks.

Shawn C. Helms and Alfred Cheng are attorneys at Jones Day in Dallas, Texas. Their practice is focused on complex technology and intellectual property-centric transactions, including business process and information technology outsourcing and technology licensing. The views set forth in this article are the personal views of the authors and do not necessarily reflect those of Jones Day.