Product testing: liability, acceptance, contract terms

"

SOFTWARE

ACQUISITION

PRODUCT TESTING: LIABILITY, ACCEPTANCE, CONTRACT TERMS will promptly verify that the product is acceptable. If a deficiency can be identified promptly, the supplier has an opportunity to correct it before further loss accrues. If the supplier is not told of the defect, he has no opportunity to correct it. The contract may reasonably insist on testing by the customer, and in default of testing, acceptance may be assumed and the customer himself may be at risk if he uses the product untested. Acceptance or rejection often deals with difficulties at the frontier of contractual performance. Whether or not a given product, as delivered, is "suitable" for the buyer's purposes may be partly subjective. If a product is accepted, suitability is admitted, and so suppliers like to be assured of informed acceptance after testing. Such informed and positive acceptance is more valuable than mere deemed acceptance, arising becausethe period allowed for acceptance testing has

THE CONTRACTUAL SIGNIFICANCE OF ACCEPTANCE Acceptance of software, like the acceptance of goods under a contract of sale, implies something more than mere receipt or delivery. It involves acknowledgment, express or implied, that the software or goods delivered are in accordance with the contract, and that the contractual obligation to deliver in accordance with the contract has been substantially performed. Acceptance does not detract from any express or implied warranties given in relation to the quality or condition of the software, which may afford the user a contractual right to have deficiencies corrected, but it does make clear that any conditions under the contract relating to delivery and quality have been satisfied. In this respect, the distinction between conditions and warranties is important. A condition of a contract is a term so significant that its breach will entitle the injured party to treat the whole contract as being at an end. Conversely, a warranty is a collateral term of lesser significance whose breach may give rise to a claim in damages but is not so serious as to entitle the injured party to avoid the remainder of the contract. Distinctions between conditions and warranties apart, failure to deliver a product which substantially conforms with the contract's requirements is not performance at all and if the failure to perform continues indefinitely it can itself be a fundamental breach of the contract. Acceptance of the delivered product, even if the product turns out to be seriously deficient, will reduce the injured party's claim from a failure to deliver to a claim for rectification of defects in the product as delivered. Put another way, acceptance implies loss of the right of rejection. This right may mean more than loss of the right to hand the software back. If the software has been accepted, it must be paid for. Not only are payments already made then irrecoverable, but instalments of the contract price which are not yet due will fall due in accordance with the contract terms and may be payable even though the software itself includes deficiencies.

elapsed. From the standpoint of both supplier and user of a computer

package, prompt acceptance testing is desirable. When the product is procured as custom written software, acceptance testing is so important as to be an almost fundamental component of the project.

TESTING OPTIONS AND TEST DATA It is usual and preferred practice that the client developer should provide test data, and the expected results to be derived from the processing of such data, before the product is delivered by the supplier. Using the client's test data has four advantages: • the client has practical knowledge of the kinds of data which the system will be required to process in daily use. Test data provided by the client will be more "real", and not just theoretical examples derived from the system specification or from standard practices; • the client's data, being real and based on the client's actual requirements in daily use, will test not only the correct functioning of the system in conformity with the contractual specification but the practical suitability of the system for live running in the client's business; • so far as the supplier is concerned, the client must accept exclusive responsibility for the adequacy and accuracy of the test data he provides. If the supplier's test data are used, this responsibility remains with the supplier, who may be liable if he negligently omits to include a test of a particular function within the software which subsequently proves to be defective; and • if the client's test data are provided in good time, the supplier can use it for quality assurance and pre-testing of the software before delivery. If the client neglects to provide test data by the time at which acceptance testing is required to take place, the supplier has no option but to use his own test data, and in such a case it is reasonable for the-supplier to insist that the client accepts the tested software on satisfactory completion of the supplier's testing. It may be less reasonable for the supplier to seek to transfer responsibility to the client for the adequacy and accuracy of the test data provided by the supplier, but since reliance on the supplier's data will only arise if the client is

W H Y TEST ON ACCEPTANCE? Typically, software is delivered on tape or disk with supporting documentation in a separate manual. Loading of the software may identify it, but except in the case of standard products identity does not imply any quality or standard in the product. The user is entitled to verify that the product as delivered conforms to his contract, and if he fails to do so, acceptance of the product will be implied against him. The right to test the product may be expressed under the contract as an obligation to test. A supplier may reasonably wish to be assured that, if he delivers the product, his customer 23

A N ,^' FEB

TIlE COMI~UT|[.R I,AW AND SECURITY REPORT

~r~default of his own obligation to provide test data and since the burden of preparing test data is considerable, the client will not be in a strong position to resist the suppliers. arguments. Avoidance of the risk is in the client's own hands He must ensure that test data are prepared in good time. Sometimes, acceptance is agreed to be based on an extended period of evaluation by the client under live running conditions. Provided that a fixed time limit is applied to the evaluation period, this technique allows a more relaxed and realistic assessment of the software's reliability and so may work to the advantage of both supplier and client. Testing then ceases to be an occasion and becomes a commentary on live running, and there is less pressure to create artificial test conditions so that the software is run on a normal daily basis during the evaluation period and deficiencies can be seen in the context of their practical effect on live running. Desirably, an evaluation period should include a period-end or year-end run, if there is likely to be peaking of processing and printing requirements.

•

there is u,.;uailyno unqualified commitment Dy the suppliel to correcl faults within any specified time scale, or at at'.

•

if the supplier fails to comply with his Tault-correctior~ obligations there is no right to re-open an acceptance which has already taken place;

•

if the supplier fails to perform, it is probable that the client has no remedy in damages since most contracts will exclude any such liability; and

•

the worse the software, the more likely it is that the warranty period will expire before the software is in full use and before all potential errors have been diagnosed and corrected.

This last weakness may be addressed by either or both of the following contractual protections for the benefit of the purchaser: •

the warranty period may be expressed by the contract to be a period of, say, 90 successive days of uninterrupted fault-free running. Each interruption of running caused by faults in the software will require the warranty period to be recommenced. This is an incentive to the supplier not to deliver defective software, since its correction under the warranty will be a continuing cost for the supplier and since regular paid-for maintenance will not start until 90 days of fault-free running have been achieved; and

•

if during the warranty period or some longer period following acceptance, performance degrades below the bench marks set for acceptance testing, the supplier may be required by the contract to enhance or modify the system so as to restore performance levels to those required by the contract to satisfy acceptance test criteria, and in fact achieve at acceptance testing.

TEST AND ACCEPTANCE CRITERIA Acceptance testing usually has two aspects: •

functionality; concerned with the ability of the software to perform the calculations and algorithms required of it; and

•

performance; concerned with response times at terminals and the ability of the equipment, operating system and application software to process workloads within acceptable time scales.

Test data should be sufficient to prove functionality, but are unlikely to be able to confirm or deny capability of performance which will only be fully tested when the system is live and operating under peak load conditions. This is particularly true of year-ends, when processing makes heavy calls on machine capacity and degrades response times at enquiry terminals. Suppliers are wary of allowing their client's freedom to change their minds and to reject a system on the grounds of failure to pass acceptance tests where failure is not attributable to objective criteria. Because suitability is so critical to the success of a system, but its assessment is potentially subjective, there is a nice balance between allowing bona-fide rejection on the grounds of unsuitability only perceived at acceptance testing, and allowing alleged unsuitability to be used as an excuse for rejecting on purely commercial grounds. Correctly, the client should be required to specify his requirements for suitability at the outset of the project and should be allowed to reject for unsuitability only if those requirements, as specified, are not met by the finished product. Some latitude should be allowed in favour of the client who has genuinely failed to perceive an essential feature of his own requirements until too late: to force a client to accept a system which he recognises to be unsuitable may be to force him into continuing performance of a contract which is then likely to be handicapped into failure. However, some safeguard against spurious rejection may be included as, for example, a cancellation charge.

j 1 9 8 8 - 8 9 ] 5 CISR

If post-acceptance experience discloses a fundamental lack of suitability in the system which has not been recognised by either client or supplier at the specification or acceptance testing stages, each party should consider the wisdom of discharging the agreement on terms which will at least recoup the supplier's investment if not restore to him the full value of his lost bargain. Forced continuance in the face of a handicap of this kind may result in the supplier being required to make his system perform in other respects beyond its capability and the resulting disputes and recrimination could quickly absorb the residual profit and goodwill.

REJECTION If the system fails to pass its acceptance test, the development contract will usually give opportunities for the supplier to correct errors and to re-test: but when these procedures are exhausted, the client must decide whether or not he intends to reject the system. A right to reject may not be maintained unexercised indefinitely, or beyond any period limited by the contract, and so must be either waived or exercised unambiguously and promptly. The contract may specify a method of giving notices, and a notice of rejection must be given in the manner specified by the contract if the notice is to be valid and effective. The effect of rejection will usually be to discharge the contract, except as to antecedent breaches. This will mean that both parties are excused from further performances of the contract, but a party who has already breached or failed to perform his obligations under the contract will remain liable for such breaches. Suppose, for example, that a client has withheld payment of monies due under the contract because he is dissatisfied with the supplier's progress in developing the software, and that an amount of £10,000 has been invoiced by the supplier to

POST-ACCEPTANCE DEFICIENCIES Even the most thorough acceptance tests cannot guarantee to catch every fault and deficiency in a new system and this is particularly true of custom-written software. Faults likely to escape diagnosis at thorough acceptance testing are also likely not to be fundamental to the operation of the system, and the client's remedy after acceptance is usually reduced to a warranty claim entitling him to free correction of the faults notified to the supplier within a defined warranty period. This reduced remedy has four disadvantages, from the client's standpoint: 24

IAN -.'Ft~B

TIlE COMPUTER LAW AND SECURITY REPORT

1988-89] 5 CLSR

Some of these risks are not capable of being insured at costs which will leave an acceptable profit in the hands of the supplier, or in some cases at all: it is not therefore surprising that suppliers seek to limit or exclude their liabilities to the maximum possible extent. The Unfair Contract Terms Act 1977 makes it impossible effectively to exclude liability for death and personal injury claims caused by negligence, and exclusion clauses will usually not seek to do so. In addition to this provision, the Act makes void "unreasonable" exclusion clauses contained in written standard terms of business, though Schedule 1 to the Act disapplies these provisions from any contract insofar as it relates to the creation or transfer of rights in intellectual property. In the case of software procurement and licensing, the effect of this latter provision is unclear, but in view of this uncertainty neither supplier nor client should assume that an "unreasonable" exclusion clause is either enforceable or otherwise. Instead, the parties should seek to agree a limitation of liability provision which fairly apportions responsibility and risk. A policy which appears to be emerging as an industry practice is as follows:

the client but remains outstanding. Suppose also that the supplier then delivers software which the client tests, finds defective and rejects. Rejection will not necessarily exclude the client from his obligation to pay the supplier's outstanding invoice unless the contract provides that, on rejection, amounts already paid or payable to the supplier shall be repaid or discharged. A dissatisfied client must also take care not to reject software if he is not entitled to do so under the terms of the contract. An unjustified rejection may amount to a repudiation by the client, discharging the supplier from further performance of the contract and exposing the client to a claim for damages for breach of contract, including a claim for loss of the supplier's profit. It is unlikely that a client who repudiates in this way will have the benefit of any limitation of liability provision under the contract, since such limitation of liability provisions are usually drafted so as to protect only the supplier and not the client. If a supplier fundamentally fails to perform his contract by persistently failing to deliver the software which he has undertaken to supply, the client may be in a dilemma: if he continues to allow the supplier time, the client may be compromising his own position by failing to act promptly; but if he acts decisively and cancels the contract for non-delivery, the supplier may claim that the client has repudiated by not allowing the supplier sufficient time to perform his obligations. The correct remedy is for the client either: • to negotiate and include a "long-stop" date in the contract, and a provision that if acceptance testing has not been satisfactorily achieved by this date, the contract is to be deemed discharged; or • if the contract provides no "long-stop" date, to give notice to making time the essence of the contract and specifying a date which is sufficiently far ahead to be unquestionably reasonable and by which acceptance testing must have been achieved. Selecting a date is made easier if the supplier can be persuaded to propose one himself: if this date is then passed, the user can discharge the contract with confidence; or • to give notice of intention to treat the supplier's continuing failure to deliver as a discharge of the contract if delivery is not achieved by a specified, and reasonable, future date, but on the express basis if a court decides that the supplier's delays have been insufficient to discharge the contract, the client will accept the court's judgement and treat the contract as continuing.

•

do not attempt to limit or exclude liability for death or personal injury claims;

•

limit, but do not entirely exclude, liability for direct and physical loss attributable, for example, to damage to tangible property The limit of liability should bear some relationship to the size of the contract and to the levels of cover usually obtained under public liability insurance policies; and

•

exclude or severely limit liability for consequential or indirect losses arising from faults in software.

Sometimes, suppliers are concerned about the possibility of claims being raised by strangers who suffer loss in consequence of use of defective software supplied by the supplier and used by a client of the supplier or by a third party. There is, at least in theory, a risk that a stranger who can prove he has suffered loss in these circumstances, and that the faults causing the loss are attributable to the negligence of the supplier of the software or its employees, may have a valid claim against the supplier. To guard against this risk the supplier requires each customer to indemnify the supplier against third party claims arising from use of the software by the client, even though such claims may be attributable to faults in the software caused by the supplier's negligence. Exceptionally, it is industry practice to include for the benefit of clients indemnities by suppliers against third party intellectual property claims alleging that the supplier's product infringes copyright, patents or in some cases trade secrets of any third parties. Sometimes, even this liability of the supplier is limited, and the supplier will usually reserve the right to withdraw the allegedly infringing product and to replace it with another of substantially similar functionality.

LIABILITIES The liability of the client for breach of an agreement for the development of bespoke software is seldom likely to exceed the liability to pay the fee due under the contract. Additional liability may accrue if the contract includes, for example, a right for the supplier to market the resulting product after its acceptance by the client, so that failure by the client to go forward with the development may result in loss by the supplier of prospective marketing profits and a claim by the supplier for compensation for such loss. Conversely, the liabilities to which the supplier is potentially exposed are much greater. They may include liabilities for: • failure to perform the contract; • defective performance, by delivery of faulty software; • breach of intellectual property rights by the incorporation of software which infringes copyright, patents or trade secrets of a third party; and • negligence, causing loss either to the client, or to the client's own customers, or to strangers.

CONCLUSIONS In contracts for the procurement of custom-written software, overriding importance is attached to acceptance and the loss of the right of rejection. This is because such contracts usually cut down or entirely remove remedies in damages available against suppliers who provide defective software, and a client who has prematurely accepted unsuitable software may find that he is relatively unprotected. Remedies for faults discovered after acceptance are difficult to enforce but nevertheless important. Since such faults may

25

AN ,^' FEB

~I[E COMPUTER I,AW AND SECURITY REPORT

lie undetected for an extended period, the concepts o,~ the re-commencing warranty period of 90 days fault-free running and the obligation to restore performance to acceptance test bench mark levels are useful protections for the client. Overall, the client must ultimately accept responsibility for the product of his supplier if the client adopts the product and decides to market it, or to use it in circumstances which may

iii :i

i ~988-891 5 CISR

cause Ioss~_~. ~ :c the client's own customers or [o rnember'.~ c ~, the public: 'Dn this basis, the client needs all the protectior he ca~q get against defaults attributable to the client's ow~ supplier.

Simon Chalton, Solicitor

Report Correspondent

BOOK REVIEW FINANCIAL TRADING TECHNOLOGY

iiii:. Computers in Financial Trading, James Essinger 1988

leading authority on expert systems for banking and financial trading functions. The conclusion is that expert systems for financial trading functions may be restricted for some time to come by the limitations of computer systems based on sequential reasoning. It is clear, however, that there are considerable possibilities for the development of these systems in financial trading scenarios and eventually the limits of what can be done in this area may only be determined by the limits of human imagination. Chapter 4 examines the security problem faced by any organisation seeking to maximise its use of computerised financial trading systems. In a typical trading situation a trading firm will have a number of PCs connected to its own internal telecommunications network (local area network - or LAN). The LAN will, in turn, have the facility for connection to an external telecommunications network, such as in another trading firm's office, or in the office of a client. Whether or not a particular PC will be connected outwards to an external network will depend on the function which the trader is performing at the PC. In these circumstances the firm will need protection against fundamental security hazards such as unauthorised entry to the dealing room, or use of a terminal in the dealing room or interference with messages sent, either internally or externally through the trading firm's telecommunications network. This chapter considers these issues and suggests approaches that might be taken. Chapter 5 looks at regulation. Computer systems deployed in financial trading scenarios have been firmly monitored by regulatory authorities since they first began to be installed. However, the world wide crash in stock markets of October 1987 brought regulation into prominence in a manner that few market participants probably expected. This chapter considers how the governing boards of stock exchanges in New York, London and Tokyo deploy computer systems to help traders make markets and, where relevant, how these regulatory authorities have sought to control the use of computers in financial tradings. The final chapter examines the future: despite the undoubted complexity of the global financial trading technology industry, it is still in its infancy. During the next five years sweeping changes and developments will occur and by the year 2000 the applications and regulatory frameworks scrutinised in this report are bound to look decidedly primitive. The chapter considers very briefly its prognoses for the future, grouped according to the chapter headings in the report. The study also contains two annexes: the first is a list of the head offices or organisations featured or mentioned in the report and the second contact points relating to publications and forum organisations also referred to in the study. There is also a glossary offering a concise definition of key concepts discussed.

~li (Elsevier Advanced Technology Publications, 251pp. ~iiii!iISBN 094 639 5373 iii~ This report aims to give a state of the art account of the use of computers in financial trading in the London, New York and Tokyo financial markets. The related issues of security and regulation are also discussed in detail. The report is based substantially on research undertaken between January and June 1988. The foreword begins with a comment that the financial trading technology industry is a field in which there are many specialists but relatively few individuals with an overall knowledge of what is happening throughout the industry. The ~iii:: primary purpose of the report is to provide such an overview. The study emphasises the practical applications of computer ~:i~i systems rather than the technical aspects, The rationale is that the majority of readers will want to know exactly what activities computer programs are capable of carrying out rather than the technical details of how they perform their activities. i~i:!i:The first section deals with decision support, that is the supply of real-time information to traders (and in some cases also supply of value-added information) supplied by official agencies such as the Stock Exchange or by commercial organisations. :::~ii For a market maker, whose profit is the difference between iiiiji the prices at which he is able to sell the financial instrument in which he is dealing as against the prices at which he bought ii those instruments, rapid access to the right kind of market information at the right time will mean the difference between success and failure. :~:~ Chapter 2 examines program trading: no other type of trading iil}i that utilises computers has excited such interest and controversy ::!i~ both among financial trading firms and among the general ii~ii public. For a period of time following the 'Crash', certain forms ~!~i of computer-assisted trading were prohibited from using the :iil New York Exchange's order delivery systems and although this ~ii~ ban has now been removed NYSE has imposed permanent iili restrictions on computer assisted trading activity. This chapter examines program trading developments as well as the history !ii!:~ surrounding its introduction: it canvasses opinions and summarises the findings. Chapter 3 looks at artificial intelligence and identifies an immediate problem - that of definition. Although specialists tend to agree on what 'artificial intelligence' means as a concept, they by no means agree at which point a system ceases to be a mere processor of essentially arithmetic calculations and becomes a system which, in however !ii!ii rudimentary a fashion, has the appearance of being 'intelligent'. :~iiii The problem that must face all financial trading firms from time iii to time is how to make the best use of specialist skills within :ii} the firm. The more effective that use, the more profitable the :ii~il firm will be. The logical step is to try to use computers to ~i!~il replicate at least a part of the expert's expertise and thereby provide a resource that will 'fill in' for him when he is on holiday !~ or sick or asleep. Chapter 3 examines the issue with the ::l~:: assistance of lan Reid, Chief Consultant of Data Logic and a

i::iil iii i::iiil iii ~! ii:iii :~.ii i~il~ ill

:i:i:

i! :!i: i:i: i!~i i!i~ :-:i i:ii

:~i:i

:iill l~:~i ii:i ~i: i iiiii!i i:~:~ ~,ii!i :ilii iili

A highly recommended study it is available from Elsevier ~i::i Advanced Technology Publications, Mayfield House, i ~. Banbury Road, Oxford OX2 7DH.

26