Businesses reliant on software should look to protect it against software developers going bust in the economic downturn.

But unless it is absolutely necessary, escrow might not be the universal solution some believe it to be: it is costly, not always appropriate, and requires significant technical resource for it to work effectively.

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, where it is held by a third party agent.

Escrow is best used for bespoke or business critical software, which is not easily replicated or replaced.

But even for bespoke and business critical applications, buyers should not rush to escrow, because it may be no more than expensive insurance.

When looking at whether escrow is necessary, buyers should consider:

  • Can the software be easily replicated, maintained or substituted (without access to the source code)? If not, escrow is not required.
  • Does the software drive a function critical to health and safety, profitability or customer services? If yes, consider escrow.
  • 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?

As well as usual boilerplate clauses, an escrow agreement should also 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

Agreements between buyers and software developers – and agents in the case of three-way agreements – should specify the reasons for source code being released.

Typical "release events" include:

  • insolvency
  • failure to maintain/support the software in accordance with a software agreement
  • failure to perform obligations under the software agreement
  • merger or acquisition

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 nothing more than a costly and futile arrangement.

Michelle Sherwood is partner and IT specialist, and Tricia Pearson legal assistant at law firm Shoosmiths.