Data Protection Law
Software escrow arrangements exist to give protection to customers who have licensed software. In general terms ‘escrow’ means a legal arrangement in which a third party temporarily holds money or property until a particular condition is met. It is commonly used in real estate transactions to protect both the buyer and seller throughout the home buying process. In the technology sector, it is used to provide customers assurance that if a software licensor defaults (for example because of insolvency) or is unable to maintain their product sufficiently, then customers will gain access to the software’s source code and maintain the potentially business critical software themselves. A third party, known as an escrow agent, should hold the relevant software information so that if a triggering event occurs, such as default, they can release the information to the customer(s).
Source code / object code
The distinction between source code and object code was the main reason software escrow arrangements were initially sought after. Source code is the human readable version of software which a developer edits in order to create their product. When a software licensor used to physically install software on a customer’s premises, they would process source code with a program called a ‘complier’, turning it into object code and then install it on a customer’s system. Object code was the end product and not human readable. Usually, customers would be unable to turn the object code they received back into source code. Therefore, the source code was the ‘key’ so to speak, and licensors would want to keep it protected so it couldn’t be easily copied, or reverse engineered.
Software escrow arrangements – source code
Software escrow arrangements therefore became the way in which customers could gain access to this ‘key’, the source code, if things went wrong. Without the source code, a customer would be unable to use the software beyond a triggering event because there would be no way to edit the software, and hence maintain it. This was especially important if the software was of critical importance to the running of the customer’s business and/or had been tailor made for them. Software licensors and customers would enter into software escrow arrangements in which a third party, the escrow agent, would keep a copy of the relevant source code. This source code, and any other necessary documentation to maintain the product, would be released if the licensor went into default or was for some reason unable or unwilling to maintain the software sufficiently. A software escrow agreement would detail the circumstances in which such a trigger event would occur.
Software as a service
With the moving of software products to the cloud, the accessibility to object code and source code which defined the first software escrow arrangements, gradually became obsolete. No longer was it simply the case that a customer would have access to object code and an escrow agent would keep source code, and any relevant documentation, in case of a triggering event. With many licensors offering software as a service(SaaS), it would often be the case that both object code and source code would be in the licensor’s possession, because no longer was that object code being installed on a customer’s premises. Software as a service basically means licensors now give customers access to a cloud-based platform, such as a streaming service, and therefore all updates to source/object code and functionality can be done on their own system. This has made software maintenance cheaper, more agile and allowed easy access of software to anyone with an internet connection.
Types of cloud software escrow arrangements
Due to software suppliers keeping and maintaining both object and source code on their own systems following the adoption, by most, of cloud computing, software escrow arrangements have also developed to reflect this. Instead of source code being released upon a triggering event, in most cases, there are now two software escrow arrangements which customers use:
- Access solution – this allows a customer, following a trigger event in which a software supplier becomes unable to maintain their product, to access the software, via, for example, simply inputting a username or password, to the latest iteration of the software. The customer will essentially have access to software’s back-end, as the software existed at the moment a triggering event occurred.
- Replicate solution – a replicate solution does what you may intuitively imagine, it creates a replica of the software which exists alongside the software under escrow and is released upon a triggering event. A replicate solution allows the customer to essentially build its own version of the software in an infrastructure of its choosing, rather than being beholden to the software supplier’s chosen infrastructure.
Access or replicate?
An access solution is by far the simpler and cheaper. An escrow agent will simply hold the credentials necessary for the customer to gain access to the software after a triggering event. It is suited to low risk, non-essential cloud hosted software and a customer who has few intentions of developing it for the future. It may also be suitable where after a triggering event a customer’s main objective is to simply access and retain all the data stored on the platform. However, if the software is business critical and holds lots of sensitive data it may be better to consider the replicate solution because the customer will be able to build the replicate in an environment of its own choosing which is unlikely to be compromised in any way.
Another issue arises where the software has multi-tenant architecture. In such an instance, the access solution may be unsuitable because by giving multiple customers access to the platform, they could potentially compromise one another’s data, violating UK data protection laws. Many SaaS platforms use multi-tenant architecture and so it is worth considering from the outset of negotiating software escrow arrangements how you will deal with potential data issues. If data is particularly sensitive and the software itself is business critical, a replicate solution may be your only option.
Replicate solutions are going to be more expensive and harder to maintain because an escrow agent will have to keep an operating exact replica of the software ready for potential release. They are, however, likely to bring much greater security and potential longevity to its use. For many customers this will be of crucial importance.
Software escrow arrangements – issues
Software escrow arrangements essentially exist to allow the transfer of a supplier’s software and, potentially, intellectual property rights to customers upon their failure to maintain their product for whatever reason. However, often an escrow agreement will state that, whilst the customer will be able to use the software after a triggering event, they will not be able to re-distribute it. This is still likely to be a concern of a software licensor and so it may deter them from entering an escrow agreement. For a customer it may only want to use a supplier’s software if it has insurance that it can continue to use it upon a supplier’s default. Some potential problems include:
- A customer will need to have the technical know-how and ability to use the software, should it be released to them.
- Software escrow arrangements can be expensive.
- There may be a dispute over whether or not a triggering event has occurred.
- The escrow may need heavy maintenance and policing. Especially when a replicate solution.
- If a software supplier fails to fulfil their escrow obligations, such as changing access credentials without notifying customers, then a customer may only have recourse for damages against an already defaulted/insolvent software supplier.
- A customer may want to consider the cost of getting a third party to maintain the software upon release rather than themselves. They may also want to consider the cost of replacing the software altogether.
Here to help
There are instances in which a court will order the release of source code. In Psychometric Services Ltd v Merant International Ltd  FSR 8 it was ruled that source code could be transferred to a customer where the supplier’s inability to complete the software development would have a serious adverse impact on the customer’s business. In most instances though customers will not want to rely on the courts to deliver inadequately maintained or developed software. Software escrow arrangements offer a solution to this problem.
Cloud computing has changed the nature of software escrow arrangements, making the object code / source code distinction less important. In the context of cloud computing one of the most important issues to consider is data protection. Data, being stored on the cloud, is potentially more vulnerable should a software supplier default, especially where they serve a number of customers all desperate to retrieve the data stored. The pros and cons of using the access solution or replicate solution, as discussed above, needs to be considered in the context of cloud software escrow arrangements. Not entering a suitable escrow agreement until it is too late and failing to undertake sufficient due diligence on software suppliers are problems often seen with such arrangements.