ESCROW Overview

1. The escrow agreement

The Software Escrow agreement is the foundation of any escrow service and a vital component of any software licensing deal. Unlike the main software license agreement, the escrow nature of the Software Escrow agreement requires there to be a third party, an Escrow Agent, who will hold the source code in trust for the parties and which will only be released in accordance with the terms of the agreement. Usually, the software license agreement will contain a clause that states that the parties agree to escrow and will execute a separate agreement to cover those terms. As this agreement involves three parties, the negotiations can be more difficult than usual.

SAES offer their own sample escrow agreement that can be used ‘as is’. However, it can be tweaked or changed completely to favour more deal-specific needs. The Depositor (Developer) and Beneficiary (User) may also profit from having their own terms to present to one another when beginning the escrow discussions.

While the terms of the agreements may vary to cater for specific needs, there are certain aspects of these agreements that both Depositor and Beneficiary will need to consider carefully before entering into an agreement. These issues include a clear understanding of what needs to be deposited, the extent and frequency of the deposit put in escrow, together with degree of validation applied to it; who bears the cost of the escrow agent's services and of any administrative or litigation costs and the conditions under which the deposit may be released.

There are generally two types of software escrow agreements. These are sometimes referred to as ‘Two Party’ or ‘Three Party’ Escrow Agreements. For ease of understanding, SAES have termed these agreements as:

• ‘Single Beneficiary’ (also known as Three Party). This is the most commonly used software escrow agreement and most often recommended by SAES. It is executed by the Depositor (Developer), Beneficiary (User) and the Escrow Agent (SAES). Some benefits of entering into such an agreement include:
• The ability to use SAES’s sample escrow agreement ‘as is’;
• The provision that allows each party to review, provide input and customise the agreement to suit each party’s individual needs, since it is executed by these three parties only; and most importantly,
• The Beneficiary is the only party who can benefit from the agreement and associated deposit materials.



• ‘Multiple Beneficiary’ (also known as Two Party). This agreement is reviewed, compiled and negotiated between the Depositor (Developer) and the Escrow Agent (SAES) only. It offers blanket protection to two or more Beneficiaries (Users). It is commonly used when the Depositor develops very standard ‘off-the-shelf’ software that is distributed ‘as is’ (no user specific features or customisations) to multiple Users. The Beneficiaries are not granted the opportunity to negotiate or change the agreement terms, conditions or services. Every new User, purchasing the software, is provided a beneficiary registration form and granted access to the source code under certain pre-defined conditions.

Some benefits of entering into such an agreement include:

• SAES’s sample escrow agreement can be used ‘as is’;
• The time to conclude and enter into contract is quick;
• The Beneficiary is provided a copy of the software escrow agreement for his records; and,
• As with the Single Beneficiary agreement, each Beneficiary is guaranteed their own copy of the deposit materials upon materialisation of the release conditions.

2. Deposit materials

It is important that an organisation create a standard list of escrow materials to be deposited by the vendors. This helps ensure that all escrows created have a comprehensive deposit covering anything necessary to reconstruct the software. A partial list of recommended deposit materials includes:

• Preferably, two copies of the source code on a suitable media for each version of the software. CDs are strongly recommended due to their higher tolerance in humidity and temperature fluctuations and reliability of long term storage (Magnetic media, example Tapes, should be avoided)
• Electronic copies of all manuals provided to the User
• Maintenance tools and third-party systems
• Login and password identifications
• Names and addresses of key technical employees that the User may hire as a subcontractor in the event the developer ceasing to exist
• Compilation libraries, compilation instructions, execution instructions, installation procedures etc.

SAES will generally make arrangements to personally collect the deposit materials. Should this not be possible and a shipping agent is required, please ensure the use of a reliable and traceable courier. In the event that a courier service is used, SAES will contact both the Depositor (Developer) and the Beneficiary (User) to confirm the receipt thereof.

2.3 Storage

The most common storage facility used is bank vaults. This provides a cost effective and extensively secure environment. Alternative storage facilities and locations, to suit specific needs, may be requested but logistical issues and costs need to be carefully considered. The use of bank vaults provides the flexibility of distributing the deposit materials to the bank or location convenient to the parties.

2.4 Updates

From time to time the software being licensed by the Beneficiary (User) is upgraded. It is critical that SAES is notified of updates to the source code and that deposit materials correspond with the versions being used by the Beneficiary. Furthermore, SAES provides written notification (reports) to both the Depositor (Developer) and Beneficiary (User) of changes to the deposit materials throughout the agreement period. The parties will also be notified if no changes to the deposit materials have been made.

2.5 Verification

SAES provides a range of verification services to meet all needs. This includes:

• Standard verification (most commonly used) – Each time a deposit is made, a Deposit Update form is completed and signed by the appropriate parties after verifying the materials by matching the tangible deposit materials (e.g. CDs, Tapes, documents etc.) with the labelled descriptions on the form. Once the deposit has been verified, it is not removed from the escrow deposit unless mutually agreed to be completely replaced with a new version. Ongoing updates are merely added to the existing deposit.
• Witness technical verification – This is an optional service and consists of the Developer and User performing an agreed level of technical verification while SAES bears witness to the result. Once the deposit has been technically verified, it is not removed from the escrow deposit unless mutually agreed to be completely replaced with a new technically verified version.

2.6 Release conditions

The release conditions listed in the escrow agreement covers typical concerns with the software, such as:

• Depositor (Developer) filing for bankruptcy
• Depositor breaching the software license agreement
• Depositor breach of maintenance/support agreement
• Depositor merger or acquisition that results in new or unfavourable software license conditions to Beneficiary (User).

2.7 Filing for release

Most requests for a release are initiated by the Beneficiary (User) because the Depositor (Developer) has either ceased operations or failed to support the product. To initiate a release, the Beneficiary contacts SAES and provides any documentation that is required by the escrow contract to support the request. SAES then notifies the Depositor who is given a period of time to object or consent to the request. More often than not, the Depositor will rectify any problem with its Beneficiary during the period following the request for release. However, the Depositor may contest the release of the materials and take the matter before an arbitration panel designed to resolve such disputes.

The Depositor generally carries this cost, however, the involved parties can decide differently