Tainted source

Dai Davis explains why a source code deposit agreement won't necessarily save your bacon if your software's got a bug and the...

Dai Davis explains why a source code deposit agreement won't necessarily save your bacon if your software's got a bug and the supplier's gone bust

When the supplier of your business-critical application deposited its source code with a third party, you probably felt much more secure. After all, should the supplier go out of business or lose interest in its application, at least the program won't be unfixable should problems subsequently emerge. That, at least, is what many external auditors appear to believe in insisting that users get a source code deposit agreement from their suppliers, trusting that it will magically fix any problems caused when a supplier goes into liquidation or has better things to do than keep a legacy application going.

Source code deposit agreements provide for the release of source code in certain specified events, such as supplier insolvency. The source code is deposited with some trusted third party such as the National Computer Centre. Although other third parties such as banks, solicitors and supplier organisations like the CSSA are sometimes used. they are generally unsatisfactory because:

  • they aren't independent as they invariably represent one party to the transaction, or they aren't seen as independent;

  • they don't always store the software media properly;

  • they can't always check that what has been deposited is what should have been deposited.

    The last aspect is important because unless you can be sure the correct version of the application you bought has been deposited, you won't be protected. The National Computer Centre offers this service but it is expensive.

    There is another problem too. Who maintains the source code? Although in theory any competent programmer can maintain a program, in practice only one familiar with the program can do it in a reasonable time. A programmer who has actually worked on the program is the best person to employ. Where a software supplier has become insolvent, it may be possible to engage one of the programmers. In the past, user groups have been successful in in this, but individual users may not be able to afford to do so.

    A more radical approach can prove more successful. In practice, what the user is trying to achieve is a reduction in business risk. A better solution is to try and reduce the risk in some other way. This can be done:

  • by obtaining a guarantee from the supplier or an associated company;

  • by obtaining a promise to maintain the software from another company with the source code - for example, a US owner of the software;

  • by agreeing with the supplier that the user (rather than a third party) takes possession of the source code while undertaking only to use it if the supplier fails to maintain it.

    To pull this last sort of agreement off you need a good bargaining position, so the earlier you request a guarantee the more likely you are to get one. Ideally you should place the request in your Invitation to Tender. Even if you haven't done so, many suppliers can be persuaded there is little danger in giving a copy of the code, say, to the chairman of the parent of the user, who agrees to place it in a safe and not to use it unless and until the supplier becomes insolvent.

    Dai Davis is a chartered engineer, consultant and solicitor with Nabarro Nathanson. He can be contacted at [email protected]

  • Read more on IT risk management