Roger Clarke's Software Escrow

For many years, software developers and computer users concerned themselves with the risk of failure of their latest project. Now that our systems analysis and design and software construction standards are higher, and our expectations of failure far lower, life ought to be less worrying.

It isn't; success has brought with it new kinds of risks. The scale of contemporary applications is such that it is often cost-effective to purchase packages, or to contract with a package-owner to customise their package to the organisation's need. Packages are being applied not only to satisfy administrative, commercial and operational data processing needs, but also to address organisations' strategic requirements, and to provide competitive advantage.

As a result of these developments, most organisations are reliant on at least some software for which they do not hold source code. This creates a number of risks for the organisation. Will the application continue to be maintainable in the event of the supplier becoming insolvent, being declared bankrupt, closing down of its own free will, or withdrawing support for the particular product, or in the particular geographical area? How can the organisation even be sure that a set of source-code still exists that corresponds to the version of the executable code it is using?

Software suppliers are often unwilling to supply source code to their clients, because they too face risks. One risk is that the supplier may lose track of who has which variant of which base version. He may later be accused of supplying a poor product or poor services, and lose reputation, and therefore business. Another risk is that a customer, or an employee or contractor of a customer, may expropriate (some might say 'steal') the source code, and use it in defiance of the supplier's copyright, or disguise it and sell it, or a variant of it, as their own product.

The problem may arise at a more subtle level than a whole package. Many products today make use of third-party components, such as system calls (from the hardware supplier), and date calculation routines, table maintenance and file-handlers (which may be the software house's own, may be from the hardware supplier, or from a third party systems software house).

At the deepest level, many organisations would do well to make an inventory of the systems software which they have on their mainframes, mid-range machines, and fleets of PCs, WP equipment, workstations and network controllers. In general, they do not have access to source code for any of it. In the present state of the marketplace, that may be 'normal', but it involves risk.

While ever the right people have access to the source code, it may matter very little that the ultimate user doesn't. After all, a great many users neither know about nor care about such technical matters, and wouldn't know what to do with the source code even if they had it. Users are happy in such circumstances - until something goes wrong.

A remarkably large number of different things can and do go wrong. The most dramatic example is that some software suppliers, including some very reputable ones, have gone into receivership in the past, and some will do so in the future. By world standards, Australia has very high quality software houses, but the industry is very competitive, technology changes very quickly, and Australian capital markets still leave a lot to be desired.

When companies die, the receiver searches for and makes an inventory of whatever assets he can find. So, if the source code can be found, the receiver impounds it. In due course he seeks the highest bidder for each item, in order to repay the creditors as much as possible of the amounts owing to them. This is a long drawn out process, lasting many months, perhaps years.

Naturally the more urgently something is needed, the higher the price. Unless he is selling the business as a going concern, which is unusual in such circumstances, the receiver has the interests of the creditors in mind, not those of the ex-customers. The source code may well be (eventually) sold to someone who has no intention of offering services to the users, or who will do so only on very expensive terms.

Quite commonly the source code cannot even be found, whether through technical ignorance or incompetence, low quality library management, or skulduggery. In such circumstances, the software is not just temporarily unmaintainable; it is permanently unmaintainable.

In principle it is possible to maintain a product which was developed using high-level procedural code, using the executable code - if enough very clever people can be found and paid for to de-compile large quantities of machine code (a mixture of art and science), and to understand and modify the resulting code without the benefit of comments, meaningful labels, or meaningful datanames. For a crucial small program, such an undertaking is feasible; but for the hundreds of thousands of lines that make up a complex commercial application, it isn't.

In addition to reputable suppliers which get into difficulties, it is remarkable how much important software is produced by small teams and individuals. Some such people get sick, and have car accidents. Some, including (especially?) the most gifted ones, decide the beach is more fun, or just leave. In these cases there is often very little chance of finding the source code that corresponds to any particular user's executable version.

Not that the supplier's demise is the only risk; indeed, default probably occurs far more often. Suppliers, once again even reputable ones, may withdraw products from the market if they have been insufficiently successful, or withdraw support for versions running on particular machines or under particular operating systems. Overseas and interstate suppliers may fail to re-appoint local distributers or agents.

Given the large number of products on the market, the shortage of software professionals, and their high cost, a supplier's expertise in any given product is often confined to a small number of people, whose services may no longer be available. If this is the case, the supplier may be unable to perform maintenance services, or unable to perform them in the time-frame needed by the user.

The existence of a maintenance contract establishes the basis for a subsequent suit for damages, but if a supplier despite best attempts just cannot perform the task, a contract cannot of itself fix bugs or adapt code to changed requirements.

There is no magic wand to fix all of these problems. However, there is a way in which organisations dependent on software can provide a basis for addressing them. One party has an interest in gaining access to source code in certain circumstances, and the other has an interest in preventing them having access except in those circumstances. The solution is to place the source code on deposit with a trusted third party, and contractually bind that party to deliver it to the right people in the right circumstances. That's called software escrow.

Software Escrow is the placing of materials related to computer software in the hands of an independent person, to be held securely and confidentially, until and unless a specified contingency is fulfilled.

The importance of software escrow services has been increasingly recognised during the last decade. In France, accounting software has been required by taxation law since the early 1980s to be kept for six years (in the same way that Australian taxpayers are required to know where their last seven years' receipts are). In the United Kingdom, such a service has been available since 1983, and is now really taking off. In the U.S., the Bankruptcy Code provides a receiver with the ability to claim goods in escrow, so such services are of very little use in that country in the case of the supplier's demise, and the market has therefore developed more slowly.

With the maturation in the market for packaged software, some suppliers are recognising the concerns of their customers and prospects, and themselves arranging to deposit materials in escrow, and adding new customers to the schedule of customers who may access the materials in the event of default.

But simply placing into a vault whatever bundle of materials the software supplier delivers may not be a sufficient way of addressing the risks that the user organisation faces. The escrow agent may warrant to store the materials in appropriate conditions, but is unlikely to offer any guarantee as to what the deposited materials contain. The user therefore faces the additional risk that the materials are insufficient to enable the organisation's executable code to be regenerated. In order to address that risk, it is necessary to arrange for an inspection of the materials placed into escrow.

Given the heavy dependence of organisations on information technology, trust between suppliers of packaged software and their customers is an insufficient form of risk management. Deposit into escrow of a set of materials sufficient to enable the re-generation and ongoing maintenance of each operational version of the package is essential.

Personalia Photographs
Presentations
Videos Access
Statistics

The content and infrastructure for these community service pages are provided by Roger Clarke through his consultancy company, Xamax.

From the site's beginnings in August 1994 until February 2009, the infrastructure was provided by the Australian National University. During that time, the site accumulated close to 30 million hits. It passed 65 million in early 2021.

Sponsored by the Gallery, Bunhybee Grasslands, the extended Clarke Family, Knights of the Spatchcock and their drummer

Xamax Consultancy Pty Ltd
ACN: 002 360 456
78 Sidaway St, Chapman ACT 2611 AUSTRALIA
Tel: +61 2 6288 6916

Created: 15 October 1995 - Last Amended: 15 October 1995 by Roger Clarke - Site Last Verified: 15 February 2009
This document is at www.rogerclarke.com/SOS/PaperEscrow.html
Mail to Webmaster - © Xamax Consultancy Pty Ltd, 1995-2022 - Privacy Policy

Roger Clarke's Web-Site

© Xamax Consultancy Pty Ltd, 1995-2024

When Your Software Supplier Lets You Down ... The Case For Inspection of Software Escrow Deposits

When Your Software Supplier Lets You Down ...
The Case For Inspection of Software Escrow Deposits