| Software is part of the day-to-day fabric for most companies. And almost everyone who uses it does so with little or no thought about what happens should it fail, or if it is no longer available.
However, the prudent software buyer will consider how to protect against failure of critical or bespoke software, which is where escrow may come in.
Be warned, though. It is costly, and significant technical resource will be required for it to be made to work effectively.
When might an escrow agreement be appropriate?
Escrow involves placing source code - the version of a computer program that can be read and manipulated by a person, rather than a machine - into secure storage. It is released to the buyer if the software provider becomes insolvent, or is unable or unwilling to continue to maintain and support the software.
Escrow is best used for bespoke or business critical software, which is not easily replicated or replaced, and where it has not been possible to purchase the source code and associated intellectual property rights from the developer as part of the overall software purchase.
It is not usually suitable for standard, off-the-shelf products from the likes of Microsoft, or 'Software as a Service' (SaaS) software, which is hosted by a developer and accessed 'as needed' via a web browser. Source code for these is unlikely to ever be made available, and even if it were, buyers would probably not have sufficient technical resources to implement it.
But even for bespoke and business critical applications, buyers should not rush to escrow, because it may be no more than expensive insurance. When evaluating whether escrow is necessary, the buyer should consider the following:
- Can the software be easily replicated, maintained or substituted (without access to the source code)? If so, escrow is not required.
- Does the software drive a function critical to health and safety, profitability or customer services? If it does, escrow should be considered.
- Is the buyer prepared to spend time and money to enforce escrow provisions? This might include members of the IT department evaluating or reviewing source code every time it is deposited into the escrow account, or instructing the buyer's legal department (or external lawyers) about enforcing the provisions of the agreement. If the buyer is not prepared to spend this time or money, escrow is unlikely to be of much value.
- Does the buyer have access to enough technical resource to be able to use or maintain the software in the event that the buyer has to rely on the source code in escrow?
In practical terms, undertaking an internal risk assessment across key departments may help to decide whether escrow is appropriate:
- contents (and risks) of escrow agreement (legal advisers)
- cost of alternative/replacement software (procurement department)
- developer's reputation, credit status, experience and references (procurement department)
- evaluation of capabilities of alternative/replacement product, assessment of risks to business following failure of software which is proposed to be put into escrow and whether it is even practicable for the developer to maintain the software in escrow (IT department)
The escrow agent
Since no special qualifications or skills are required to become an escrow agent, it is important for buyers to verify that the agent is both reputable and capable, and that storage facilities are appropriate - climate-controlled, fire proof etc. Well-known escrow agents include NCC and Iron Mountain.
The buyer must consider whether or not the agent should bear the costs of lost or damaged deposits where the loss or damage occurred whilst in the agent's control. This may mean an increase in the agent's fees, but may be useful if the cost of replacing deposited materials will be significant.
Types of escrow agreement
There are two main types of escrow agreement:
- two-way - agent and developer with rights to access materials for multiple licensees
- three-way - agent, developer and buyer
A two-way agreement is generally used where there are multiple users of the software. The buyer - who is not a party to the agreement - usually has limited rights to access the software.
A three-way agreement contains provisions specific to the buyer and the software purchased. The buyer is usually able to negotiate specific terms with both the escrow agent and developer.
What type of arrangement is required?
Understanding what software the buyer is purchasing and how important it is to them is crucial. If it appears that the software is business critical, and there is no mention of an escrow arrangement, it is important to ask 'Why not?'
If escrow is not required because the source code and materials (and intellectual property rights therein) have been purchased as part of the overall transaction, all well and good. However, if the developer has refused to part with the source code, the advantages and disadvantages of an escrow arrangement should be considered.
Understanding what types of arrangement are available and when they commonly appear will help the buyer (or developer) decide whether an escrow arrangement is appropriate in the circumstances and, for the buyer, will hopefully avoid future business continuity issues in the event of software failure.
Conversely, the ability to advise whether or not an escrow arrangement suggested by the buyer (or developer) is inappropriate or not feasible, may result in the buyer (or developer) saving time and money.
Armed with a detailed understanding of the aims and objectives of the escrow arrangement, it will be necessary to draft or review an agreement is suitable for the circumstances.
The escrow agreement
The escrow agreement should be signed at the same time as the software agreement, because there is very little incentive for the developer to sign once the software agreement has been agreed.
From a practical point of view, the developer and buyer should agree the terms of the escrow agreement between them before presenting it to the escrow agent for approval, thus avoiding protracted and costly three-way negotiations.
Whilst the escrow agent may agree to a higher level of liability in the agreement, it is likely that the agent's fees will increase.
Deposits
It is essential that the agreement specifies exactly what has to be deposited. This will usually be the software's source code. Source code is the version of the software setting out how the program works, and which often needs additional programming (called compilers or keys) in order for the software to run on a computer.
The compiler or key will also need to be deposited, together with any manuals, documents, methodology, tools or other items necessary to understand the source code and run the software.
In addition, a list of the names and contact details of the programmers who worked on the software should be included, so they can be contacted should there be a release event. The depositor should warrant that it has obtained consent from all programmers for disclosure of their personal details.
Deposits should include updates, revisions, patches or fixes. As a minimum, deposits of the source code and related materials should be updated on a quarterly basis. Out-of-date source code - source code out of step with the current version of the software - is of little value to a buyer. An exception to the requirement for updated versions is where the developer and buyer have agreed that the buyer can use an older version of the software. In these cases, only the agreed version of the source code and related materials should be deposited.
Release events
Because disputes about whether a particular event triggers the release of the software can mean it is withheld, the agreement should clearly state the release events.
These are usually limited to things that stop the developer or the developer's sub-contractor from providing, maintaining or supporting the buyer's version of the software, such as:
- insolvency
- failure to maintain/support the software in accordance with a software agreement
- failure to perform obligations under the software agreement
- merger or acquisition
Developer's right to object to a release
It is likely that the developer will require time to object to a proposed software release.
This should be avoided wherever possible, because in the event of a release the buyer will be looking for a prompt way to continue business operations. As long as the release events are clearly defined, there should be no need for the developer to object.
However, if the developer insists on a right to object to the release, it should be limited to circumstances where the developer can clearly and quickly show that a release event has not happened. In this instance, it is likely that the developer will require that the software remains in escrow, subject to a dispute process.
The dispute process should be set out clearly, explaining the escrow agent's obligations if the buyer and developer give conflicting instructions. This could be by expert opinion, or by stating which party's instructions the agent should follow. The length of the dispute process will be critical, since it is likely that a failure to access the software promptly could leave the buyer without a critical application.
Post-release
Following a release event, the buyer should be allowed to employ or train enough third parties to be able to continue to use the software if the developer has not provided details of programmers, or if programmers refuse to assist the buyer.
The buyer should be obliged to keep all information about materials and programmers confidential.
Verification and testing
An obligation to deposit the source code and related materials for current versions of the software (see above) is of little practical help if the developer fails to do so and subsequently goes bust. The escrow agent should therefore verify to the buyer that deposits have been made.
But verification alone will not guarantee that the materials can be used. The buyer should consider undertaking regular integrity testing of the deposited materials. This will usually be paid for by the buyer, and can be costly, but it may be possible to have developers agree to reimburse buyers' costs.
The extent and frequency of verification or testing should be set out in the agreement, and should address:
- how the initial deposit and subsequent updates will be verified
- the extent of the verification/testing
- who pays for verification/testing
- what happens if verification/testing identifies a problem or failure
- additional costs (eg extra reports)
- who undertakes the verification/testing (escrow agent or another party)
Where the escrow agent is to carry out the verification/testing, the escrow agreement should provide that the agent will provide a certificate to confirm it has taken place.
Intellectual property
It is critical that the parties know who owns all intellectual property in the materials.
The developer may have used a third party to write the manuals or a piece of code. If so, the developer must show that it owns or is fully licensed in respect of all intellectual property. Otherwise, the third party may block the release of the software. The developer should grant an indemnity in respect of any such third party rights.
If the developer cannot prove its ownership of - or its right to sub-license - material developed by a third party, it may be prudent for the buyer to get consent to the escrow arrangement from the third party.
Data protection
If details of programmers are to be deposited, two data protection warranties will be required. The developer should warrant that it has the permission of all programmers to deposit their personal data, and the agent should be asked to warrant that it will keep it secure.
Both warranties should be supported by an indemnity in the buyer's favour. But please note that, regarding the developer, the indemnity will be ineffective following insolvency and, in respect of the agent, higher fees may apply.
Non-solicitation
If details of programmers have been deposited, the buyer may need to agree that it will not solicit the programmers away from the developer during the term of the escrow agreement.
Other considerations
As well as usual boilerplate clauses, the escrow agreement should set out:
- all fees and costs payable and by whom
- termination rights for each party, particularly if this is linked to the duration of any software licence or maintenance agreement
- buyer/developer's rights to audit the agent's storage facilities
- reporting to be provided by the agent
- each party's liability for breach or negligence
Key or costly?
Where an escrow arrangement is used for business critical software, and deposits monitored and tested, escrow can be a key part of the buyer's business continuity planning.
But if deposits are not monitored, or release events are not sufficiently clear, it can amount to a costly and futile arrangement.
|