Escrow Agreements for Software As a Service – are they worth the paper they are written on?

23 September 2011

Software escrow involves the deposit by a software vendor of the source code for their software with a third party escrow agent.  The escrow agent then holds the source code on behalf of a customer of the vendor and will only release the source code to the customer upon certain conditions being met.  This allows the customer to access the source code in times where the software vendor is unable to continue to maintain and support the software, thereby in theory ensuring minimal disruption to the customer. 

The traditional software escrow approach was born during a time when software systems were complete systems, which often resided at a business’s premises.  Access to the source code generally provided the customer with a complete solution to maintaining the software. 

However, software systems today are more complicated.  A software system is now usually constituted by multiple software applications, operating on different premises, hosted by different parties, and not necessarily under the complete control of the business which uses it. 

One such system is a Software As a Service application (commonly known as a “SAAS” application).  A SAAS application is usually hosted by a third party and accessed remotely (often through a web browser).  The software and the data contained in the software are stored by the third party.  

SAAS applications pose a conundrum for businesses that have traditionally looked to the safety of a software escrow arrangement, to enable them to continue maintaining and updating their software should the service provider be unable to do so.  The issues which arise from entering into an escrow arrangement for a SAAS application are explored below.

Escrow revisited

Traditional escrow arrangements are constituted by a contractual arrangement (the “Escrow Agreement”) between three parties:  the customer, the software owner and the escrow agent.

Under an Escrow Agreement, the following usually occurs:

(a)                 The parties identify the scope of materials to be deposited.  This could include the source code for the system and copies of design and implementation documentation.  It could also include hardware and third party software. 

(b)                 The parties agree on how often the escrow materials are to be deposited.  Most arrangements require quarterly deposits.  Some require more frequent deposits.

(c)                 The parties agree on the form of supply of the materials.  Some arrangements require that a DVD be deposited with the escrow agent.  Others require regular uploads of the development environment.

(d)                 The parties specify the conditions upon which the escrow materials will be released to the customer.  The most standard condition is the insolvency of the software vendor.  Other conditions however may include the software vendor determining to no longer support or update their software; one or more material breaches of a service agreement; or one or more material breaches of service levels. 

(e)                 The parties agree on the usage rights granted to the customer.  In most cases the customer will be granted a restricted licence which will provide the customer with the limited right to use the source code to update the software for their own business requirements or to correct errors. 

(f)                  The parties may agree that upon release of the escrow materials, any restriction on the customer head hunting the software vendor’s employees will be lifted.

(g)                 The Escrow Agreement will also set out the fees of the escrow agent, who pays those fees (usually the customer) and any other obligations of the escrow agent (such as conducting independent tests to verify that the escrow materials, as deposited, meet the requirements specified in the Escrow Agreement). 

The above terms are often negotiable and may vary between different products/customers and software vendors. 

Escrow and SAAS Applications – the conundrum

Many enterprise software solutions are now being offered as a SAAS application.  For many businesses it is therefore imperative that they protect their ability to continue to use the SAAS application if the software vendor becomes insolvent, or some other event occurs which restricts their ability to use and/or access the software. 

A SAAS application is often a combination of different software components, and hosted externally to the customer’s business premises.  This creates multiple issues for businesses which have traditionally looked to the safety of a software escrow arrangement to provide access to the software’s source code, to enable them to continue maintaining and updating the software should the service provider be unable to do so.  These issues include:

(a)                 Given their online nature, many SAAS applications are accessed by many customers in many countries.  Further, many SAAS applications are activated online without any direct interaction (or negotiations) between the service provider and the customer.  Consequently, a SAAS provider may commercially be unwilling to enter into an escrow arrangement unless the customer comprises a substantial part of their revenue, or the right price is offered. 

(b)                 A SAAS application is usually a combination of many software systems, and may require a complicated environment in which to execute.  Consequently, to enable the continued operation of the software, in addition to access  to source code, the customer will also require:

(1)                 Access to third party components which are incorporated into the SAAS application.  These third party components could include, for example, software libraries or complete database systems. 

(2)                 Access to third party relationships.  For example, a SAAS application provider may have contractual relationships with web hosting providers and payment processors.  These relationships may need to be replicated for the software to function.

(3)                 Instructions and third party tools necessary for the compilation, installation and configuration of the SAAS application to allow it to be perfectly replicated.

Even if the above components are deposited with an escrow agent, in order to compile, install and configure the SAAS application, the customer will require:

(a)                 Access to competent personnel to assist with the compilation, installation and configuration of the SAAS application.   Quite often these staff may be existing staff of the service provider.  If the SAAS application provider is outside Australia, it may be difficult to entice these staff to assist. 

(b)                 Most importantly – access to data.  Data, which may be frequently updated, needs to be regularly backed up.  This is outside the escrow relationship, however the most up to date version of the data needs to be available.

If the above issues are not properly dealt with then any escrow arrangement may in practice hold little value to the customer.

What should businesses do?

Businesses need to undertake a multi-pronged approach to protect themselves in the case of the failure of a SAAS application to function, or to be accessible.  They cannot rely on escrow alone, but must also rely on other measures to protect themselves.  These include contractual obligations which require:

(a)                 a minimum level of uptime of the system;

(b)                 regular backups of data.  These should were practical be stored offsite;

(c)                 liquidated damages for poor performance;

(d)                 the software vendor to enter into a disaster recovery plan; and

(e)                 the software source code to be placed in escrow.

Businesses should also prepare their own disaster recovery plan, should they be unable to access or use the SAAS application for a prolonged period of time.  The plan should focus predominantly on practical measures to address any shortfall in performance of the software vendor which affects the operation of the business, and not necessarily rely on legal measures alone. 

Darren Sommers, Special Counsel