In these uncertain times, the number of companies getting into difficulties is unfortunately increasing. Whilst the IT sector has not yet suffered as much as others, it is prudent for heavy users of IT to make sure that they can withstand the possible absence of a crucial supplier. One thing that could usefully be done is to review the protection offered (or which could be offered) by having in place proper source code escrow arrangements.
This is timely as the NCC Group is already reporting a significant increase in the amounts of source code being released under escrow agreements; the figures for the early part of 2009 show an increase of 220% over similar periods in 2008. NCC further estimates that around 20% of software companies are likely to go into administration in the course of the next 12 months.
Introduction to Escrow
Software escrow has its defects, and the release of source code under an escrow agreement is often something of a last resort. Nonetheless, for some years software escrow has been used as a means of risk management for companies who use custom-made or complex software to run their operations. In essence, it acts like any other form of escrow: a resource is placed in the keeping of a third party, who holds on to it until called upon to release it following fulfilment of a specified condition. In this case, the resource is software source code (not normally provided to the customer, although there are exceptions), and the conditions relate to the status of the software house. The purpose of the escrow is to ensure that the source code is obtainable by the licensee end-user, whatever happens to the licensor. The normal triggers for release are such events as a default of maintenance obligations or the insolvency of the software company.
If source code is in escrow, the licensee can use the software with greater confidence that it will always have the tools to fix problems and make necessary alterations, even if the licensor ceases trading or is otherwise unable to carry out its maintenance and other obligations.
A Systematic Approach
What then should businesses now do to ensure that – if need be – they do have direct access to source codes? Clearly, a lot depends on the content of the contract (normally a maintenance arrangement) currently in place. However, a systematic approach to a review might be as follows.
Identify the Software
The asset register should be up-to-date and a company should know precisely what IT systems it has. It is impractical to have escrow arrangements with all suppliers (try asking Microsoft) but a list should be collated of those items of software which are business critical and specific to a business and for which it is worth considering putting escrow in place.
The list is likely to consist of software which was commissioned or at least heavily customised, and which is not readily replaceable without a great deal of expenditure. It is not likely to consist of items which are of a ‘general’ office support nature.
Prioritisation is likely to be necessary; the software most at risk (for example, heavily customised software that is provided and maintained by a small independent software company) should be secured in this way first, particularly if there is a limited budget for escrow fees.
Review the Contract
Once this list has been put in place, the relevant contracts need to be collated and reviewed. This may well result (in the broadest terms) in three different types of scenarios:
• where source code has in fact been put into escrow
• where the relevant contract contains an obligation upon the supplier to put source code in escrow but that has not yet happened
• where the licence is silent on escrow.
Source Code Already in Escrow
The fact that the source code is already in escrow does not necessarily mean that it will be in useable form. It is not uncommon for any of a number of problems to be present: the source code may be incomplete or corrupt, inadequately documented, impossible to build into a working system, or simply out-of-date (perhaps not having been updated since the first deposit). Indeed, the software escrow provider Iron Mountain noted in 2007 that, according to its statistics, ‘97.4% of all deposits sent in for analysis were determined to be incomplete and 74% of examined deposits required additional input from the developer in order to be compiled’.
To assist with this issue, escrow providers such as Iron Mountain and NCC offer verification services in addition to simply holding the source code. Differing degrees of verification are offered, ranging from checking that the code as deposited is complete and includes the tools necessary for use, to actually assembling the software product from the source code and checking that it works in practice.
It will clearly be essential to make use of these verification services (although of course there will be additional expense incurred), and to follow up comprehensively with the software house if any problems are discovered.
Contractual Entitlement to Escrow
Whether there is a contractual entitlement will, of course, depend on the terms of the contract. However, if the option is there, then the first and most difficult hurdle to obtaining software escrow – getting the consent of the software developer to the potential release of their ‘Crown jewels’ – has been overcome. In the current economic climate, it is prudent to insist upon the activation of the escrow provision as soon as possible.
Once the software company has made the deposit then of course the issue of verification occurs again.
No Contractual Entitlement to Escrow
Here the user is in a weak position. Whether or not a request for escrow is likely to be agreed to by the software developer will depend on individual circumstances, but at the very least this is likely to require paying their costs and might well require additional money in consideration.
A supplier may well agree if not doing so will make the customer look elsewhere, but each negotiation is likely to be an individual one. Pressure for a sensible commercial response might be obtained by raising the issue as part of contractually required price negotiations or as a condition for contract renewal.
Source Code Use
As a final point, it is worth noting that, even where escrow has been arranged and the source code is complete and workable upon its release, this does not mean it can be put to work immediately. For many companies the reason they hired an external software developer in the first place was that software development (and therefore also maintenance) was not an area they had the time or expertise to deal with. As anyone who has created code will know, trying to understand and amend the code that someone else has written is a real challenge – and that is the main weakness of the source escrow mechanic. Having the code does not necessarily mean that anything useful can actually be done with it.
Conclusion
Retrieving source code from escrow is, as noted at the beginning, a remedy of last resort. None of the parties involved hope that it will happen: the developer because it represents the loss of their valuable intellectual property, and the end-user because, even if the code is useable, they may not have the staff or facilities in place to make proper use of it immediately.
In summary:
• identify candidate systems and prioritise
• check contracts
• negotiate, if necessary
• utilise verification services
• follow up.
And begin now!
Renzo Marchini is a solicitor specialising in IP/IT at Dechert LLP. He was previously a software engineer.
