Let’s imagine your company just spent a huge portion of its budget on a customized software from SoftWidget, an imaginary software provider. What would your company do with the software if SoftWidget decided it would no longer support it or went out of business? After all, the software industry is volatile (where did you go WordPerfect????). To address this issue, many software contracts include provisions for the creation of “software escrow accounts” which provide that a third party will retain a copy of the software code. The code is only released under a specified set of conditions.

Two types of code can be saved in a software escrow account: source code and object code. Source code is human readable code. This means that you do not need the assistance of a computer to understand the code. Think of it as a user’s manual to manipulate the machine readable code. If worse came to worse, you could maintain or support your users in-house with the proper personnel as long as you had the source code. Source code is commonly placed in a software escrow account.

Object code, on the other hand, is not user friendly. It is readable only by a machine. Because we don’t understand it, the source code acts as a sort of “cipher” to understand the object code. Additionally, the source code allows the manipulation and alteration of the object code. Customers usually receive only the object code when they purchase the software. They can use it, but they can’t change it. Object code has traditionally not been deposited in a software escrow account because customers already had the software locally installed on their own servers and were not dependent upon a third party. Thus, for most users, the object code need not be placed in an escrow account.

Software escrows become more complicated however, if you are purchasing a service as a software (“SaaS”) product. In this scenario, you do not actually receive the object code when you purchase the software. Instead, this code is located on the software provider’s servers and made available through the cloud. If the software provider were to suddenly go out of business and you qualify to receive code from the escrow account, it may do you no good if they have only stored source code, as this only provides instructions on how manipulate code you do not possess. Thus, in a SaaS scenario, a user would want both the source code and the object code placed into the software escrow account.

An additional consideration with SaaS escrows is the recovery of data. Escrows typically contain basic source code without any customer specific information. If your data is stored in the cloud (the software provider’s servers) it may be lost in an escrow qualifying event. You may want to consider requesting regular backups of your information to store on local servers as a safeguard against such an incident.

Before you agree to a company’s standard software escrow clause, verify which type(s) of code they are required to deposit, review the conditions that would qualify for a release of the code held in escrow, and consider the access you will have to your data in such an event. A solid understanding of these issues can help you have confidence in purchasing your next software system.

This information is made available by Spaulding Law for educational purposes only and not to provide legal advice. By using this website, you understand that there is no attorney-client relationship between you and Spaulding Law, unless you have entered into a separate representation agreement. This information should not be used as a substitute for competent legal advice from a licensed professional attorney.