1. Introduction
The potential consequences of inadequate source code[1] escrow arrangements[2] for a business or organisation dependent on external software maintenance and support services involve time and money, or more to the point, the loss of time and the loss of money:
- a business dependent on critical software applications may experience serious operational disruptions, loss of productivity or financial loss due to bugs in, or the total failure of, software used by it
- an organisation that has poured money into the development of bespoke software by a software developer may lose the entire fruits of its investment before the end-product is implemented or even delivered or tested
- an organisation may be exposed to liability as a result of breaching contractual obligations to third parties
- an organisation may be forced to seek alternative software and face a myriad of difficulties – a substitute solution may not be readily available or may need to be re-developed from scratch or may only be available on unpalatable terms – and the customer may have little option but to fork out hefty replacement costs (additional licence or development fees, consultancy fees and training fees).
Often, these losses of time and money could have been avoided if the customer had adequate source code escrow arrangements. If access to source code materials is part of the life-blood of business continuity, you may well ask: why have some escrow arrangements failed to provide adequately for the customer’s survival and well-being? And perhaps more importantly, how might such failures be prevented?
In this article, we dissect the anatomy of source code escrow arrangements and diagnose three common causes of inadequate escrow arrangements:
(i) a prevailing mindset that an escrow agreement comprises a rigid, inflexible set of standard terms, the primary (if not sole) purpose of which is to permit the customer to get access to the supplier’s[3] source code materials only if the supplier becomes insolvent or does not remedy a breach of its maintenance and support obligations
(ii) inadequate or unsuitable terms of agreement for the customer’s unique needs and
(iii) the failure of one or more of the parties to properly execute and/or manage the escrow agreement.
Each of these problems has possible remedies. In our view, by viewing source code escrow arrangements as essentially strategic arrangements for the promotion of business continuity, and appreciating their strategic significance, customers can use escrow arrangements to their advantage, and maximise the utility of their source code escrow arrangements for the promotion of business continuity.[4]
2. Importance of access to source code materials
Access to source code materials, which contain important technical information and knowhow, the building blocks of software’s creation, is usually vital for correcting errors in the software, maintaining and supporting the software, modifying or developing new functionality for the software and interfacing or integrating the software with other software or systems. However, the supplier, whose primary concern is to protect the confidentiality and commercial value of the intellectual property rights and knowhow in the source code materials, will seek to avoid disclosure of the source code materials, except in limited circumstances.
Source code escrow arrangements seek to address the competing interests of the supplier and the customer – the source code materials are securely stored with a trusted third party and the customer is permitted to get access to and use the source code materials only upon the occurrence of specified release events, usually where the supplier is unwilling and/or unable to provide maintenance and support services.
3. A strategy for promoting business continuity
It is important at the outset to break free of the mindset that a source code escrow agreement is merely an inflexible set of standard terms to be uniformly applied to customers, oblivious to their unique requirements.
The main purpose of source code escrow arrangements for customers is to promote business continuity – ie mitigate operational risk, protect against the possibility of failure of external software maintenance and support services, and provide the tools to cure defects in and sustain the operation of software. They have potentially long-term strategic importance. By viewing source code escrow arrangements as a strategic arrangement and appreciating their strategic significance, customers can best utilise escrow arrangements to promote business continuity.
A strategy for implementing effective source code escrow arrangements consists of three main stages: first, identifying customer requirements; secondly, negotiating and agreeing the terms of the escrow agreement; and thirdly, effectively managing or administering the escrow agreement.
4. Stage 1: identifying customer requirements
The first stage of the strategy is to determine what the customer’s source code requirements are. This involves some soul-searching, a critical self-assessment of the organisation or business identifying and analysing its operational requirements. The customer should ask two key questions: first, what are the purposes for which we may need the source code materials? And secondly, in what circumstances do we need the source code materials? The answers to these will vary depending on the nature of an organisation’s operations.
5. Stage 2: terms of the escrow agreement
Once the organisation or business has identified its requirements, the next stage of the strategy is to negotiate and agree appropriate and advantageous terms of agreement.
It is apparent that in software licensing or development negotiations, customers frequently regard source code escrow arrangements as something of an after-thought, a tedious side issue of relatively little interest and involving relatively little money in the scheme of the main commercial agreement. Either the issue is not given detailed consideration, or it is considered only at the eleventh hour in the negotiations, and even then only in cursory terms.
The consequence of this mindset is that customers often simply accept a supplier’s standard form escrow agreement, which is likely to contain terms that are largely favourable to the supplier and may not be appropriate for the customer’s needs. From the customer’s perspective, certain terms of an escrow agreement are of key strategic importance. In general, a customer’s main objectives in an escrow agreement are usually to ensure that:
- it has contractual rights of access to and use of the source code materials which are enforceable against the supplier and the escrow agent[5]
- the source code materials deposited into escrow by the supplier are complete, current, do not contain defects, and are sufficient for the customer’s needs
- the source code materials are deposited into escrow by a specified time and are kept up-to-date
- once deposited, the integrity of the source code materials is verified
- the circumstances in which the customer is entitled to require the release to it of the source code materials are clear and as broad as possible
- once the customer requests the release of the source code materials, those materials are released promptly with minimal opportunity for the supplier to challenge the customer’s entitlement to require the release of the source code materials
- once released to the customer, the customer is entitled to use the source code materials for all its required purposes
- the customer has the right at any time during the term of the escrow agreement to pay the escrow agent’s fees (irrespective of which party is ordinarily required to pay such fees), in order to ensure that the escrow agent does not terminate the escrow agreement due to a breach of the obligation to pay the escrow fees.
Far from being an inflexible agreement, in relation to each of these issues, there is a range of negotiable positions, some of which are illustrated in the Table.
Issue/clause | Pro-supplier position | Pro-customer position |
Definition of source code materials (sometimes referred to as deposit materials) | narrow definition of source code materials, eg: “source code and related materials” | broad, comprehensive definition inclusive of any materials specifically identified in a schedule include all technical information and knowhow |
Deposits of source code materials* | ||
(i) Time by which source code materials to be deposited | initial deposit: within a reasonable period of time of the execution of the agreement or of request by the customer | initial deposit: within a reasonable period of time of the execution of the agreement or of request by the customer |
ii) Frequency of deposit of updates | following receipt of reasonable notice from the customer (not automatically), and subject to a limit on the frequency of update deposits (eg: no more than once per year) | automatically within a specified period of an update (or new release or new version, as appropriate) being completed, or in accordance with defined periodic update requirements |
(iii) Notice of confirmation of deposit | escrow agent notifies both supplier and customer upon receipt of source code materials | escrow agent notifies both supplier and customer upon receipt of source code materials and provides details of the contents of the initial deposit and each subsequent deposit |
(iv) Reminder notices in relation to updates | obligation on escrow agent to issue reminder notices in relation to updates to supplier where appropriate, obligation on the supplier to either supply any updates within a specified time of the notice (or other milestone) or confirm in writing that there are no updates | |
Verification* | no verification or a single verification of the completeness of source code materials | the nature and extent of verification required by the customer, which may include a right to periodic verification of content, completeness or sufficiency, integrity, quality, functionality and currency of the source code materials obligation on the supplier to cooperate with the customer in relation to verification, and to provide software, systems, hardware and suitably qualified personnel reasonably required for such purposes |
Audit rights | right to periodically audit the escrow agent’s records relating to receipt of source code materials from supplier | |
Release events* | source code materials to be released in only limited circumstances, eg: bankruptcy or insolvency of supplier, or breach of maintenance obligations by supplier release of source code materials subject to conditions precedent, eg: provision of statutory declaration or similar document attesting to the occurrence of a release event release of source code materials subject to supplier’s right to challenge the release | as many release events as possible, including specific release events relevant to customer’s particular requirements no or few conditions precedent to the release of the source code materials |
Timing of release* | within a reasonable period of receipt by the escrow agent of a valid request for release by the customer (subject to any right to challenge the release – see below) | within a specified (short) period of time of a receipt by the escrow agent of a request for release by the customer |
Right to challenge release* | right to challenge the release of source code materials in any circumstances by notice to the customer and escrow agent | no right or only limited right of supplier to challenge or prevent the release of source code materials (and only if the basis of the challenge is reasonable) |
Payment of escrow fees | customer to pay all escrow fees responsibility for payment of escrow fees is clearly specified | supplier to pay all escrow fees, or supplier and customer to contribute in specified proportions to payment of escrow fees a right for customer to pay escrow fees in circumstances where there is a failure by the supplier to pay the escrow fees which would otherwise entitle the escrow agent to terminate the escrow agreement for breach of the obligation to pay the escrow fees responsibility for payment of escrow fees is clearly specified |
Scope of licence/right to use source code materials* | licence/right to use source code materials no broader than those granted in the main commercial agreement, or silent | licence/right to use source code materials at least as broad as those granted in the main commercial agreement permits employees, agents and subcontractors (and where appropriate any affiliates of the customer) to use the source code materials |
Obligations of escrow agent | to maintain source code materials in safe and secure environment and release source code materials only in accordance with express provisions of the escrow agreement | as for supplier, but including in addition specified verification services and notifications to parties in relation to receipt of source code materials and updates and other communications |
Note: those items marked “*” are discussed in more detail below.
The extent to which a customer will seek to negotiate the terms of the escrow agreement will depend on a number of factors, including the suitability of the terms of the agreement for the customer, the importance of the software to its operational requirements, the customer’s risk analysis of the consequences of the software’s failure and the relative bargaining positions of the customer and supplier. It is worth commenting in more detail in relation to some of the above issues.
5.1 Sufficiency of deposit materials
The customer should ensure that the source code materials placed into escrow are sufficient to ensure that a fully functional version of the software is able to be produced. Little will be gained from simply getting an amalgam of code, files and documents that require piecing together.
Carefully check the definition of “source code materials”, which might be a bit on the thin side. The definition of “source code materials” should be broad and comprehensive and, where appropriate, include the product name, version or release numbers, information regarding the hardware and software environments necessary to read, compile and maintain the source code materials, details of the media type (for example, disks, magnetic tape or other media) containing the source code materials, directory listings of media content, the names and versions of development tools or libraries, software design information, details of any encryption devices required to use the source code, any documentation required to use the source code, details of the compiler required to use the source code materials, and the names and contact details of the programmers or software engineers who wrote or created the software. For added caution, it may be helpful to include in the definition a catch-all phrase to the effect that the source code materials include any materials required to enable a reasonably skilled programmer to understand, maintain and correct the software. (Similar language is included in the National Computing Centre’s standard escrow agreements.)
The customer may also seek the inclusion in the escrow agreement (or the main commercial agreement) of a warranty that the source code materials contain all information in human-readable form and on suitable media to enable a reasonably skilled programmer to understand, maintain and correct the software. The customer may consider seeking the inclusion of a warranty as to the quality of the source code materials, and to the effect that the source code does not contain any lock, time bomb or other similar device that may render the source code unusable.
5.2 Frequency of updates
Source code materials are not much use if they are out-of-date. The customer should consider the frequency with which updates should be deposited into escrow. This will depend partly on the nature of the commercial agreement between the supplier and the customer.
Where bespoke software is being developed over an extended period of time, it may be prudent for source code materials, which are being continually updated, to be placed into escrow on a regular basis, upon completion of specified milestones. In the case of a conventional software maintenance and support agreement where updates consist of new releases or versions of software, if the supplier has a standard procedure for updating the source code materials deposited in escrow, it may be most appropriate to adopt the standard procedure if acceptable to the customer.
For extra protection, the customer may require the supplier to deposit the then-current and immediately preceding versions of the source code materials into escrow, in case there are errors in the most recent version of the source code materials. Even if the supplier is not required to deposit any new versions or updates of source code materials into escrow following the initial deposit, the customer should consider requiring the supplier to deposit a replacement copy of the initial deposit of source code materials periodically to protect against possible deterioration of the media containing the source code materials.
Finally, the customer should check that any standard or defined terms in the escrow agreement are appropriate to the nature of its activities and consistent with the terms in the main commercial agreement. For example, the operative provisions of the escrow agreement specifying the supplier’s obligation to keep the source code materials in escrow up-to-date may refer to “new releases” or “new versions”, which may not be appropriate in the context of software development agreements which contemplate the supply of, and use the terminology of, bespoke “deliverables”.
5.3 Third-party materials
Source code materials usually include software or other materials in which third parties have rights – for example, various utilities, libraries, compilers and operating systems which are needed to replicate the original development environment for the software.
The customer should make sure that it obtains the right to use any software or other materials in which third parties have rights. If it is the supplier’s responsibility to obtain such rights, this should be clearly stated in the escrow agreement. Usually the customer will require a warranty that the supplier has the authority to grant to the customer and the escrow agent the rights provided pursuant to the escrow agreement.
5.4 Verification
Verification of the source code materials is an important means of checking various aspects of the source code materials, ranging from confirming their composition to extensively evaluating their completeness or sufficiency, integrity, quality, functionality and currency. Verification assists in determining whether the source code materials will perform their intended function. It may be used to detect viruses, media defects, third-party software, and to compile and execute program applications.
The extent and frequency of verification desired will depend on the customer’s assessment of the importance of the software to the customer’s operations. Periodic verification enables the customer to determine at various points in time whether the source code materials correspond to the most current object code version of the software application.
If the customer expects the escrow agent to perform a certain type of verification or a relatively high degree of verification, this should be clearly described in the escrow agreement. To the extent that a customer may require the assistance of the supplier in order to verify the source code materials, the customer may consider including a term in the escrow agreement obliging the supplier to co-operate and to provide software, systems, hardware and suitably qualified personnel reasonably required for such purposes.
5.5 Release events and right to challenge release
In addition to relatively standard release events (for example, insolvency and unremedied breach of maintenance and support obligations), the customer may seek the inclusion of a range of specific release events particular to its requirements, including:
- supplier’s failure to deliver all information needed to make software compatible with other software when reasonably requested by customer
- supplier’s failure to carry out obligations imposed on it pursuant to the licence agreement
- supplier ceases to trade or continue to do business in the ordinary course
- change of control of the supplier or acquisition of supplier by a competitor
- supplier discontinues providing maintenance and support services for any reason
- supplier fails to deliver the final software product or to perform development services
- supplier loses specified or key management staff or software engineers which may adversely affect its ability to perform its obligations
- supplier’s unrestricted cash balance falls below a certain specified threshold amount
- the advent of a force majeure event, which then has effect for a specified period of time
- supplier assigns the whole or part of the intellectual property rights in the source code materials to a third party (and/or fails to offer the customer substantially similar protection at no material cost increase within a specified period of time).
Customers may also seek to broaden particular release events to encompass not only their actual occurrence, but also the reasonable likelihood of their occurrence.
As well as ensuring that appropriate release events are included in the terms of the escrow agreement, the customer should ensure that each release event is clear. The supplier may require that the customer return the source code materials to the supplier if particular breaches triggering release events are remedied or cease to exist.
Where the supplier requires the right to challenge the release of the source code materials, the customer should seek to limit the circumstances in which the supplier is entitled to do so to where there is a genuine dispute as to the occurrence of a particular release event or there is a reasonable basis, based on good faith, for the supplier to challenge the release. The inclusion of an efficient dispute resolution mechanism in the escrow agreement may enable any challenges to the release of the source code materials by the supplier to be dealt with expediently.
5.6 Right of use of source code materials
The customer should ensure that the scope of its licence to use the source code materials is not narrower than the scope of the licence to use the software granted under the main commercial agreement and that its rights under the escrow agreement are sufficient for its operational requirements.
The customer’s requirements may include, for example, the use of the source code for the purposes of the main commercial agreement, for correcting errors or defects caused by improper use or viruses, for modifications, developments, enhancements, and to exploit any modifications, developments and enhancements.
5.7 Consistency between terms of escrow agreement and terms of main commercial agreement
In some circumstances, whether intentionally or not, escrow arrangements between the customer and supplier may be addressed to some extent in both the main commercial agreement and an escrow agreement. In such circumstances, it is important to ensure that there is a mechanism for resolving any actual or potential inconsistencies between the terms of each agreement in order to avoid uncertainty and disputes as to the applicable terms and ensure that any rights that the customer thought it had under one agreement are not obstructed by contrary or inconsistent terms in the other agreement.
6. Stage 3: management of the escrow agreement
Once the deal has been struck and the parties’ obligations have been clearly and comprehensively documented in the escrow agreement, the third stage in the customer’s strategy for optimising its source code escrow arrangements relates to the management of the escrow agreement.
It is trite, but nevertheless worthy of mention, that an escrow agreement with favourable terms for the customer may be of little use unless it is properly managed or administered. Here is a brief checklist of key issues to keep in mind when managing the escrow agreement:
(a) Make sure that the parties to the escrow agreement are correct, particularly in circumstances involving relatively complex escrow agreements, various entities within corporate groups, or where there have been novations, assignments or other transfers of agreements, changes of company structures or company names.
(b) Make sure that the definition or description of the source code materials is comprehensive, complete and clear.
(c) Make sure that the customer’s rights and the supplier’s obligations with respect to third-party materials included in the source code materials or otherwise required to utilise the source code materials are adequately identified and described.
(d) Make sure that the parties’ contact details for notices and communications are complete and correct.
(e) Check that the escrow agreement is validly executed by all parties and that a duly executed counterpart of the agreement is retained.
(f) As far as possible, proactively monitor the supplier’s and escrow agent’s compliance with any key dates or milestones (for example, initial deposit and updates of source code materials, verification of the source code materials, payment of the escrow fees).
(g) Keep in a centralised location copies of any correspondence sent and received in relation to the administration of the escrow agreement, including notices of change of the other parties’ addresses or contact details.
(h) Proactively monitor both the performance of the supplier under the main agreement and, as far as possible, its operational status, and be alert to defaults by the other parties, and the occurrence of release events in order to be in a position to exercise the customer’s rights under the escrow agreement and minimise the risk of a supplier having any basis for arguing that the customer’s failure promptly to exercise a right amounts to the waiver of the right (see CardBase Technologies Ltd v ValuCard Nigeria plc [2002] All ER (D) 128 (May) (Chancery Division) ).
7. Conclusion
Inadequate escrow arrangements can incapacitate and impede an organisation’s ability to function.
An organisation’s source code escrow arrangements are usually an important operational risk management tool.
The effectiveness or utility of a customer’s escrow arrangements can be enhanced by viewing source code escrow arrangements as not simply an inflexible, standard form agreement, but rather as a strategic arrangement that is able to be tailored to the customer’s individual needs.
By viewing source code escrow arrangements in this way, and adopting a more critical, forward-looking and proactive approach to the negotiation, implementation and management of source code escrow arrangements, customers will be better placed to maximise the utility of their escrow arrangements for the promotion of business continuity.
Alex Mitchell and Andrea Ruggieri are Associates with Baker & McKenzie’s IP and IT/C Department in London and Washington respectively. The views expressed in this article are those of the writers and not necessarily those of Baker & McKenzie.
——————————————————————————–
[1] Source code is the human-readable version of a software program. Unless the contrary intention appears, the use of the expression “source code materials” is intended to include computer program source code and all related technical documentation and materials.
[2] In basic terms, a source code escrow arrangement is an arrangement whereby the supplier of software agrees to deposit the source code materials relating to software licensed to a customer with a trusted third party, the escrow agent. The escrow agent holds the source code materials for release to the customer upon the occurrence of certain specified events.
The most common forms of escrow agreement are two party agreements and tripartite agreements. Two party agreements are entered into between the software supplier and the escrow agent. The customer is not party to the agreement. Instead, the supplier notifies the escrow agent that particular customers are beneficiaries entitled to access to the source code materials from the escrow agent upon notice of the occurrence of any of certain specified events. The customer may have difficulties enforcing the terms of the escrow agreement of the escrow agent if it is not party to the agreement (and is not able to enforce the terms of the agreement as a third party beneficiary). A tripartite agreement is an agreement between the supplier, escrow agent and customer under which the customer has contractual rights against the supplier and the escrow agent that may be enforced. In addition, or in the alternative, the terms relating to contracting parties’ escrow arrangements may also be dealt with in whole or in part in the main commercial agreement.
[3] In this article, the term “supplier” is used (instead of “owner” or “depositor”) to refer to the owner or right-holder of the software who is party to the escrow agreement. These terms may not be appropriate in all instances. The supplier may actually be the sub-licensor of third party software, and in the context of a joint software development agreement, there may be two or more owners.
[4] The source of a customer’s legal rights in relation to access to source code is contractual. There are only limited statutory rights in the United Kingdom in relation to access to source code – the so-called “decompilation” right provided pursuant to the Copyright, Designs and Patents Act 1988, s 50B is of limited assistance.
[5]It is generally prudent for customers to conduct some form of due diligence on a prospective escrow agent and ensure there is no conflict of interest in the escrow agent’s relationships with the customer and supplier.
[6] (sometimes referred to as “deposit materials”).
