As businesses become more dependent on technology they also become more reliant on third-party suppliers who provide and support such technology. This chapter explains how you can mitigate this dependency through the use of escrow arrangements. Details covered include a description of what escrow is, when you should consider using escrow, the legal and technical considerations of setting up an escrow arrangement and how to choose an escrow agent.

INTRODUCTION

The word ‘escrow’ is a legal term meaning ‘money, goods or a written document, held by a trusted third party, pending the fulfilment of some condition’.

This type of arrangement has been used for hundreds of years to facilitate deals where there is a time lag between the initial stages and completion of a business transaction.

Property transfers are a good example of this. The seller wants to know that the purchaser’s funds are sufficient and available before completing and handing over the relevant documentation. By placing the funds with a ‘trusted third party’ who guarantees the amount and that it will be transferred upon receipt of the property transfer documents, this requirement is satisfied.

Whilst escrow is used by the software industry in the manner explained below, there are numerous applications of this process. For example if a company provides services to a business using proprietary financial models developed to assist in its decision-making process, it may well be prudent to request that these models be placed in escrow in the event that the services terminate abruptly.

THE IMPORTANCE OF ESCROW FOR SOFTWARE USERS

Escrow has been used in the IT sector for over 35 years to provide users of software with long-term security. The service is built upon the split between source code and object code.

Programmers write software in source code (a form of computer program that is understood by humans and is required in order to maintain and update the software). When a program is ready, a compiler converts it into executable or object code (the machine-readable form of the computer program) that is licensed to users. The compiler may be available commercially or the owner may develop it especially for the program.

Software owners normally grant users a licence to use the executable code of their programs. Only very rarely will access to source code be provided. This is normally guarded jealously by the owner because the intellectual property of the source code makes up most of the value of the owner company. The reason why owners wish to keep their source code secret lies with the limitations of the legal protection provided for software infringement.

International protection for software is provided by copyright. Copyright provides owners with the right to copy the ‘work’ and enables them to take action against any infringement. This right depends upon the copy being ‘materially’ the same as the original. If the source code was to be made public any competitor would be able to see how the code was created and may be able to use this information to create quickly (and cheaply) a similar program.

Having to prove in court that this new version is a copy of the original would be expensive and time-consuming. It is therefore far better to keep the source code secret and never to allow this situation to arise.

Source code is necessary in order to maintain and update the software, so by ensuring that it remains confidential, the owners prevent users from doing this work themselves. This creates a business risk for the users because they are then reliant upon the owner for the correct and continuing operation of the software. If the package is key to their business and the owner for some reason is no longer able to support the package, operations may be critically affected.

Software escrow agreements provide for the placing of the source code with an independent trusted third party, known as the escrow agent. This agreement, which is made between the owner, the licensee and the escrow agent, states the events under which the source code will be released to the licensee and what the licensee may do with it once he receives it.

WHEN DO YOU NEED ESCROW?

Software escrow is not necessary for every software package that you purchase. A company needs to assess the criticality of the software package and the financial or operational loss that would occur in the event of its failure. This ideally needs to be done when procuring a new software package because it is far easier to request escrow during the negotiations leading to the purchase of a licence.

Looking at software you already use or waiting for a problem to occur before trying to enter into an escrow agreement is more problematical because owners are usually reluctant to enter into escrow arrangements after the licence has been signed (see below).

You should address the following points when considering escrow:

• The software owner:
  • Is the owner a substantial company that is highly unlikely to cease trading or is it a small start-up that could find itself in difficulties very quickly?
  • Do you have concerns over the software owner’s commitment to supporting the software package?
  • If it is a smaller company, is it backed by a large organisation that will step in and pick up the pieces in the event of a problem?
• The software:
  • If you do not accept the latest version of the software from the owner will the one that you have continue to be maintained?
  • Is there an alternative software package on the market that you could quickly switch to with little difficulty and cost?
  • Are there regular maintenance issues with the software?
  • What is the intended lifespan of the software?
• Your business:
  • Is the software key to your business? Would your business still be able to function effectively if the software suddenly becomes unavailable?
  • Would revenues be affected if the software became unavailable?
  • Will it cost a large amount to switch software in the event of a problem with the owner?

See table as text

TECHNICAL CONSIDERATIONS

Merely being able to access the source code may not be sufficient. Software source code is often immensely complex and completely unintelligible to the layman. Even an expert will usually find it difficult to understand the source code of a complex program if he is not familiar with it. So the question arises as to what you can do with it when it has been released to you?

The two main options available are to contract with a new software supplier to maintain the software package for you or to take over the maintenance in-house.

Almost all software releases under escrow agreements are made due to the insolvency or cessation of trading of the owner. In these circumstances, the people who wrote the source code will usually be looking for work and it is likely that they would be willing to be contracted to provide support.

During this period of support you will be able to ensure that your own staff become familiar with the package so that self-sufficiency is finally attained.

As stated, source code is often immensely complex and even for a relatively straightforward program can run to thousands of pages. For anyone to understand the code (other than its author), it is essential that certain quality controls are used by the owner in maintaining the software such as proper indentation and notes. Failure to do this can make a huge difference if someone new, either your own staff or a new software supplier, has to try to work with the package.

VERIFICATION

During the early days of software escrow, no checks were made on the material deposited with the agents. Eventually it was realised that this was a substantial area of risk because it meant that the effectiveness of the escrow arrangements relied upon the honesty and efficiency and full understanding of the software owner.

As mentioned earlier, software owners are highly protective of their source code and therefore if their technical staff are asked to deposit the source code with an escrow agent they may often deposit the object code by a mistake because they have been told never to let the source code out of the building. Mistakes can be made when putting the deposit together that cannot be rectified if you only find this out when the code is released to you and the software owner has gone out of business.

Verification addresses some of these issues. Verification takes a number of forms. At a basic level, a check is made to ensure that:

• each item of media deposited can be read without error and contains no viruses;
• if the data have been encrypted or password protected in any way that the data can be accessed using the decryption key or password provided by the software owner;
• if compression has been used that the data can be decompressed;
• the deposit contains source code.

You will note that at no stage does this basic level of verification provide any assurance that the code provided is the correct and complete source code for the package that you are using.

The most effective way to ensure that the code lodged is the required code is to ask the escrow agent to work with the software owner to go through a process of building the application through compiling the source code into the executable code. You should agree on the testing that should be carried out on the executable software package and ask that you are involved in this process. The escrow agent will be able to fully document the build process and ensure that all information and files required to build the software package are included in the escrow deposit.

WHAT SHOULD BE LODGED?

The source code alone is not normally sufficient to be able to support and maintain software. You should also ensure that the following items are considered:

• Full details of the material deposited including the name and version number and the number of items.
• The owner will have used a compiler to compile the source code into executable code. In order to reproduce the executable code, you must identify the exact version of the compiler. If it is not commercially available (it may have been developed specifically for the licensed software by the owner), you will need to have it lodged in escrow as well. The escrow agreement should cover the terms under which such third-party software is held and released.
• The technical details that will enable someone to access and understand the contents of the media including the file and archive format and the retrieval commands. The type of hardware necessary and the operating system details should also be provided.
• Names and versions of development tools.
• The names and contact details of the people who wrote the original code. If the developer ceases to trade they may then be contacted to provide support on a contract basis.
• Supporting materials, such as design notes, flow charts, written documentation etc. Anything that will assist a trained programmer in understanding the code that is lodged.
• Code developed by third parties and used in the software. Often third-party developers are used to provide specialist elements of packages. If this occurs, then the appropriate source code for this element should also be provided and the consent of its owner obtained to the escrow arrangement.

THE AGREEMENTS

There are many different types of escrow agreement that have been developed over the years in order to deal with different licensing situations and different types of material being protected. The simplest one is the three-party agreement involving the owner, the user and the escrow agent. Agreements have also been developed to deal with multiple licensing situations where a standard software package is used by many users. Whatever parties are involved in the ownership and support of the package need to be included in the escrow agreement along with the end-user, such as distributors and outsourcers.

Notwithstanding the many types of agreement, most escrow agreements contain the same elements:

• Statement of ownership or right to enter into the agreement by the owner. This is key to any escrow agreement. Ownership of the copyright in software belongs to the person creating it unless an assignment has been completed. Many software owners do not realise this and it is not unusual for them to bring in outside contractors to complete specialist parts of a package. Unless the rights have been assigned, those contractors could cause problems at a later date if they find out that a third party has access to their source code.
• The release events. These may be anything that the parties agree upon although most standard agreements contain the following:
  • The liquidation of the software owner;
  • The software owner ceasing to trade;
  • A material failure under any maintenance agreement;
  • An assignment of the software to a third party who does not provide the licensee with similar protection to the current escrow agreement within 14 days of such assignment.
• Confidentiality. Strict obligations of confidentiality should be entered into so that the source code remains a trade secret of the owner. Notwithstanding that the user has access to the source code this does not mean that it can be made available to the whole world. For example, it will still be of value to a liquidator in the event of a liquidation and should therefore be rigorously protected.
• Limitations on use. Strict limitations are normally placed upon the user so that the code may be used only for their own maintenance and support. The user should not be able to start licensing the code and making competing packages.
• Time-bound release process. If there is a dispute about release or some other critical provision a rapid resolution is essential. The user is not going to want to wait months for release at a time when his business may be in jeopardy.
• Title. Unless there are special circumstances, ownership of the source code will not change merely due to a release of the package to the user. A statement confirming that ownership remains with the original owner is found in most escrow agreements.

USER’S DUTIES

An escrow agreement is only as good as the efforts made by the user to ensure its effectiveness. For example, the owner may issue new versions on a regular basis. The escrow agent has no knowledge of these new versions unless the user tells it that they have been received. If this is not done then the agent will hold an out-of-date, and potentially unusable, version of the source code.

The user must also spend some time ensuring that the material placed in escrow is everything that is needed for support and maintenance of the software. This can be helped by asking the escrow agent to carry out high levels of verification. It is too late to correct matters if this is left until after a release event.

CHOOSING AN ESCROW AGENT

It is vital to choose an appropriate escrow agent. Many companies have used a bank or a firm of lawyers as their agent. This is not good practice because these organisations do not usually have the administrative capacity to maintain correctly an escrow deposit over a period of years. Neither do they usually have the skills to provide any level of verification. An agent should have the in-house legal, technical and administrative personnel to back up the services it offers.

There are professional escrow agents that provide a suitable level of service and these should be used wherever possible. The largest escrow agent in the world is NCC Group plc who are based in Manchester in the UK, but have offices throughout Europe and in the USA. The geographical situation of the escrow agent is often unimportant. Code can be delivered worldwide on almost a 24-hour basis. The software industry is truly global. Decisions on agents should be made on the quality of the services provided and, inevitably, cost.

ADVANTAGES OF ESCROW FOR SOFTWARE OWNERS

Software owners are increasingly seeing the advantages of actively offering escrow to all their customers.

• Confidence. Providing escrow protection shows a commitment to their customers. It gives customers confidence in their dealings with the software owner and can be a motivation for the customers to deal with them rather than another supplier. This is particularly true if the owner is dealing in a new market or is a start-up company.

  A number of software companies when attempting to break into a new geographical market have used escrow in their marketing literature to convince companies that there is a low business risk in dealing with them and that they are committed to such customers in a tangible long-term manner.

• Off-site storage of the complete source code. Whilst off-site storage should be a basic business continuity measure for all owners it is surprising how many do not do this. There have been a number of examples of owners requesting their code back from an escrow agent because they have ‘lost’ their own copy, especially for older versions of the software.

  Furthermore it is common to find that owners do not have a complete copy of the latest source code stored anywhere because different persons in different parts of the company will hold the source code that they are working on. Placing the source code for a package in escrow can be seen as a useful quality measure to ensure that internal standards are complied with, particularly if verification is carried out to prove that the code is correct and complete.

• Proof of ownership. Software is protected by copyright and one of the main issues concerning proof of ownership is the date the ‘work’ was created. By placing the code in escrow, the trusted third party can provide evidence of the date that the code was lodged.

CONCLUSION

There have been some notable examples where organisations have obtained release of source code from an escrow agent and been able to support and maintain it after the respective software owners have gone out of business. There have also been a number of companies that have suffered greatly because a key software owner was unable to continue providing its usual service and they have had no escrow protection in place.

Software escrow provides an ‘insurance policy’ against the unpredictable IT market through enabling continuing maintenance of critical applications in the event of release of code. They should therefore form an essential part of business continuity and disaster recovery planning.

Software escrow also provides users with leverage in the event that the software owner defaults on maintenance obligations because the threat of release under the escrow agreement will often result in the maintenance issues being resolved. This is also true in the case of change of IPR ownership where the users protected under a software escrow agreement are in a good position to be top priority for the new IPR owner.

Decisions concerning software escrow should not be made without a careful consideration of the surrounding circumstances. A risk assessment should be carried out on each new software package procured and then repeated on a regular basis to determine if escrow protection is required and what level of testing should be carried out. Once escrow protection is in place the arrangement needs to be managed to make sure that the source code for the correct version of the software being used by the end-user is held at all times.