As the preceding discussions have indicated, computers are used increasingly in situations where any malfunction may result in financial or physical loss, damage or injury. The terms "mission" and "safety critical" are often used. In such circumstances, a lawyer's fancy lightly turns to thoughts of liability. Given the range of computer applications and the myriad forms of liability, any work of this nature can present no more than an overview of the issues. Unlike the topics discussed previously, no specific statutory provisions can be identified and case law is extremely limited. This dictates that the approach adopted in this chapter will differ from that of its predecessors. Its aim is, taking account of the major forms of liability, to instantiate situations where loss may result from the operation of computer systems and consider the factors which may influence the allocation and extent of liability.
Prior to considering these issues it is helpful to give brief consideration to the nature of computer software and to the differences which exist between software and the tangible products with which society and the law are more familiar. The first difference of substance may be identified at the level of testing. With a product such as a motor car, it is possible to test every component so as to provide definitive information about its properties. Often, however, testing entails destruction of the item involved and even where this is not the case, it will seldom be commercially feasible to test every specimen of the product. In production, it is possible that some components will be of inferior quality to those tested. A further point is that many, probably most, instances of defects occur as a result of errors at the production stage. Only a portion of products will be possess any particular defect and these may not be the one's which are selected for inspection. The conclusion from this analysis is that it is possible to test one item exhaustively but that the results have limited applicability regarding other items of the same type.
The situation is radically different where software is concerned. It is impossible to test even the simplest program in an exhaustive fashion. This is because of the myriad possibilities for interaction (whether desired or not) between the various elements of the program. In the world of popular science much publicity has been given in recent years to what is known as chaos theory. This suggests that every event influences every other event; that the beating of a butterfly's wings has an impact upon the development of a hurricane. On such an analysis, totally accurate weather forecasting will never be practicable because of the impossibility of taking account of all the variables affecting the climate. The theory's hypothesis is reality in a software context. Although software can and should be tested, it has to be accepted that every piece of software will contain errors which may not materialise until a particular and perhaps unrepeatable set of circumstances occurs. Especially where software is used in safety critical functions it is sometimes advocated that where an error is discovered it is preferable to devise procedures to prevent the circumstances recurring than to attempt to modify the software. The argument is that any change to the software may have unanticipated consequences resulting in another error manifesting itself at some time in the future. The cause of a massive failure which paralysed sections of the United States' telecommunications system in 1991 was ultimately traced to changes which had been made in the call routing software[1]. The software contained several million lines of code. Three apparently insignificant lines were changed and chaos ensued. By way of contrast, the operators of London's Docklands Light Railway, whose trains are driven under computer control, took the decision that they would not make any changes to the software after it had passed its acceptance tests. The result was that for several years trains stopped on an a open stretch of line, paused for a few seconds and then continued with their journey. It had been intended to build a station at the site. After the software was accepted the plans were abandoned but the trains remained ignorant of this fact.
The plus side of software testing and production is that although the testing has limitations, the nature of the copying is such as to give a very high degree of assurance that every copy which is made will be identical. Production defects are virtually unknown so that test results will be valid for every copy of the software.
The nature of legal rights and obligations is dependent in large measure upon the relationship between the parties. The distinction may be of limited significance where the operation of a computer system has resulted in some form of physical damage or injury but will be far more significant when loss is economic in nature. Here it may only be a contracting party who has a right to compensation.
The question whether information could or should be regarded as a form of property has been discussed extensively in previous chapters. A similar debate rages concerning the question whether computer software should be regarded as a product or be dealt with under the law relating to the supply of services. An illustration of this concerns the system of product liability introduced on an EC basis by the Council Directive 85/374 on the approximation of the laws, regulations and administrative provisions of the Member States concerning liability for defective products[2] and implemented in the United Kingdom under the terms of the Consumer Protection Act 1987. In answer to a question in the European Parliament concerning the scope of the Directive, the Commission stated that:
the term product is defined as all moveables, with the exception of primary agricultural products ... Consequently, the directive applies to software
By way of contrast, in a Consultative Note published by the Department of Trade and Industry prior to the enactment of the Act, it was suggested that:
Special problems arise with those industries dealing with products concerned with information such as books ... and computer software.
and the argument advanced that the legislation should not apply within these sectors. As discussed in relation to copyright, the linkage between books and software is a somewhat strained one, whilst it also appears that the Consultative Note conflates two distinct issues. A book is made up of pieces of paper bound together in some manner and a computer program will normally be supplied on a plastic disk. Paper and plastic must certainly be classed as products. If a book or disk has a sliver of metal embedded in its cover which cuts the hand of a user the item has to be regarded as a defective product. The second and more uncertain issue relates to the informational content of the products. The prevailing view has been as expressed by Denning LJ in the case of Candler v. Crane Christmas ([1951] 2 KB 164) that:
a scientist or expert ... is not liable to his readers for careless statements in his published works. He publishes his work simply for the purpose of giving information, and not with any particular transaction in mind at all.
In most cases human beings must be credited with the capacity for independent thought and judgement. Their actions will be based on a wider range of inputs than are normally contained in a single publication. The Commission, it is argued, are correct in considering software to be a product. This leads, however, to further issues when software can be considered defective and whether any particular defect can be regarded as having caused injury or damage as defined in the legislation.
In considering the application of the product liability regime three situations might be identified. The first is where the software controls directly some object or function and where any failure might result in injury or damage. Next we have situations where a software failure may set up a dangerous situation but where the existence of a causal link between defect and damage may be unclear. Finally, consideration will be given to the situation where a computer system gives information or advice to a human user who acts on this only for injury or damage to result.
In 1829 the directors of the embryonic Liverpool and Manchester railway determined to hold a contest to find the most suitable of motive power and devised a set of elaborate performance specifications. Items such as size weight, haulage power and speed were dealt with. There was even provision, ignored in practice, that locomotives should consume their own smoke. The specification, however, made no mention of brakes, an omission which was to have tragic consequences when Lord Huskisson stepped onto the track in front of an oncoming train.
Failure to consider the means of stopping a locomotive might appear exceptionally culpable. Prior to the invention of the steam engine, however, the major problem with transport had been to move objects. Stopping them had been a matter of little concern. From this standpoint, the omission of specifications regarding braking capabilities might be viewed rather more charitably. Many of the problems with software can be traced to deficiencies in the original specification. One of the best known concepts in science fiction is Isaac Asimov's laws of robotics. The laws state that:
In other situations, computer programs may perform similar functions in a more opaque fashion. An example might be where computers control the flight of an airplane. An automatic pilot is essentially a form of robot. At a more down to earth level, many motor cars rely upon computers to control the operation of items such as anti-lock braking systems. In both examples, the potentially fatal consequences of a failure on the part of the computer system are all too obvious. In one recent air crash, it has been speculated that a dispute between the human and the automatic pilots may have been responsible for the accident and it is a frequent complaint that those responsible for designing (specifying) computer systems take inadequate account of human frailties and our propensity to push the wrong button or stray from normal procedures.
Since the enactment of the Consumer Protection Act the producer of a defective product has been held strictly liable for any personal injury resulting from its operation. Liability is also imposed in respect of any damage to private (non-commercial) property. As will be discussed below, there is uncertainty whether a computer program might be regarded as a product for the purposes of either the Consumer Protection or the Sale of Goods Acts. This is a matter of little significance in the situation described above where the program controls directly the operation of a physical object which in turn causes death or personal injury. What is of more significance is the determination when the product is to be considered defective and, given that liability under the Consumer Protection Act is strict rather than absolute, whether any defences might be available.
Under the terms of the Consumer Protection Act a product is to be considered defective when it fails to provide the level of safety that "persons generally are entitled to expect". In most cases this must mean that a party will not come to any harm as a result of coming into contact with the product. Account must be taken of the manner in which the product is used. If a user cuts a finger whilst wielding a knife, it would generally be recognised that the fault lay with the user rather than the product. In similar fashion, although air passengers might reasonably expect that they will be carried safely to their destination, the producer of an airplane would not be held responsible for an accident caused by pilot error.
In real life it may seldom be the case that a single factor is responsible for an accident. The Consumer Protection Act is concerned only with the liability which may be incurred by the producer (or in some cases the supplier or importer of a product). In many instances, other forms of liability may also arise. In the example of the robot, it is likely that the worker would have been in a contractual relationship with the factory owner who might be liable for breach of the statutory duty to provide a safe system of work. In the airplane example, passengers would have had a contract of carriage (itself subject to the terms of international Conventions) with the airline involved.
It is also the case that risks may be inherent to an activity. The Act provides that a product is not to be considered defective solely because "the safety of a product which is supplied after that time is greater than the safety of the product in question." The example might be put forward of two cars travelling side by side along a road, each travelling at 80 kph. Without warning, a hole appears in the road 30 metres ahead. Seconds later, one car has stopped short of the obstacle whilst the other has disappeared into the bowels of the earth. Discounting factors such as driver reaction this might appear indicative that the second car is defective. Further investigations reveal that the first car was produced in 1994 and the second in 1954. If it is further discovered that the average stopping distance for a 1954 built car travelling at 80 kph was 35 metres, this conclusion may have to be revised. Products have to be assessed against their contemporaries rather than their successors although a distinction must be drawn between the situation described above where a certain level of performance represents the state of the art and that where a failure might be in accordance with expectations. The concept of perfection is seldom a realistic goal and it may be anticipated, for example, that an airplane engine will fail once in ten thousand hours of flight. It might be further calculated that the risks of both engines failing on a twin engined plane would be once for every 100 million hours of flight. In the event such a dual failure occurred and injury resulted, it would be no defence for the producer to establish that the failure rate was in line with the calculations and that the state of the technical art did not permit them to build a more robust product. These issues will be considered more fully in the context of the development risks defence.
As computer applications become more sophisticated, the risk analysis referred to above may become a matter of increasing complexity. It has been suggested that the technology is such that robot surgeons could perform operations to narrower tolerances than any human could attain. This is perceived as having particular advantages in surgery for the removal of brain tumours. By being able to cut more precisely, a robot could remove a greater proportion of the tumour thereby improving the patient's prognosis. Any operation can go wrong. In the event that a surgical procedure goes wrong, a patient seeking compensation has presently to establish negligence on the part of the surgeon. If the surgeon is a robot it may be that the provisions of the Consumer Protection Act will impose strict liability. The robot will thus be judged more harshly than the human. Other ethical and legal considerations aside, such a possibility may well deter hospital authorities from utilising the new technology. It may be that the law and lawyers are better equipped to assess the nebulous nature of human conduct than the statistical precision which characterises computer applications.
During 1992 considerable publicity was given to failures in a computer system supplied to and operated by the London Ambulance Service. A committee of inquiry established by the Regional Health Authority found those responsible for making the acquisition had made virtually every mistake could be made in such a process. The final mistake was to put an inadequately tested system into operation without retaining the older manual system as a back up until its reliability had been established. Almost at once the system crashed and the ambulance service descended into chaos. Some patients had to wait hours for an ambulance whilst others were attended by 5 or 6 vehicles. Although contemporary media claims that up to 30 deaths resulted have largely been discounted there can be no doubt that the situation was potentially dangerous. The legally significant question must be whether the failure of the computer system would have caused any death or injury. A relevant decision is that of R v. Poplar Coroner, ex parte Thomas (1993] 2 All ER 381). Here an asthma sufferer was victim to a severe attack. Attempts were made to summon an ambulance but delays ensured. More than half an hour elapsed before the ambulance arrived by which time the patient had stopped breathing and was certified dead shortly after arrival at hospital. The consultant in charge of the Accident and Emergency Unit at the hospital expressed the opinion that had the patient arrived at the hospital even a few minutes earlier she would not have died.
At issue in the case was the question whether an inquest should be held into the death. The Coroners Act of 1988 provided that an inquest was to be held when a patient had died "an unnatural death". The Coroner declined to hold an inquest on the ground that the deceased's death was not unnatural. Although the High Court overturned this ruling, the Court of Appeal agreed with the Coroner. Delivering the judgement of the Court, Dillon LJ held that the cause of the death was the asthma attack. Considering the role played by the late arrival of the ambulance, the judge postulated a number of scenarios which may have been responsible. Delivering his judgment shortly after the failure of the computer system, it is not surprising that one concerned "the failure of a newly installed computer installed by the ambulance service to handle emergency calls more efficiently malfunctioned, as newly installed computers are prone to". In this scenario, he stated, "common sense indicates that what caused the patient's death was ... the asthmatic attack, not the ... malfunction of the computer".
The particular case was concerned with a narrow point and it may be that a causal link could be established between the negligent operation of a computer system and an injury or fatality for the purpose of establishing civil liability. A further incident reported in comp.risks indicates further complexities which may be encountered in the medical field. For a considerable period of time, radiation treatment has been a standard response to forms of cancer. The dosage to be given to a patient is dependent upon a number of variables including the patient's weight. With the previous generation of machine, the operator had to perform the calculations. New equipment was supplied in which the calculations were made automatically. One operator was unaware of this and continued to make the calculations adjusting the machine's output accordingly. The effect of this was that a number of patients received a dosage smaller than the optimum.
It may be that negligence could be ascribed to either producer - for failing to provide adequate documentation or control systems - or to the user for failing to ensure that staff were adequately trained. Given the nature of the incident it may be difficult to establish a causal link. In other reported cases, patients have been given excessive doses of radiation. This clearly would result in physical harm. Underdosing might deprive the patient of some of the benefits of the treatment but would not per se cause harm.
In 1988 the United States warship Vicennes was on patrol in the Persian Gulf. It was equipped with a state of the art radar system linked to the ship's weapons system. One commentator has said of the system that "it had a lot of information to present to its operator, and cynics charge that it presented it in a form that was cryptic, cluttered and sometimes misleading. An operator saw data he misinterpreted data as a descending aircraft. The aircraft was in fact ascending. This misunderstanding contributed to the perception that the plane was an F-14 on the attack, rather than an Airbus 320 on a commercial route"[3]. The rest is tragic history.
Although the manner in which information was presented to the operator may have been open to criticism, the decision whether to act on it or not remained in human hands. Although there may be a perception that the producers of the system were negligent, the element of human involvement may well be such as to preclude the imposition of property status in respect of the system's output. The same result should apply where expert systems output advice to their users. In a number of instances, however, the possibility of human intervention may be so limited as to make the user effectively a part of the machine. The issue has been discussed in a number of United States cases brought against the Jeppesen Company, an undertaking specialising in the production of charts for use by airline pilots. In a number of instances the information given on the charts was defective and fatal accidents ensued. Liability was imposed under the United States' product liability regime on the basis that a pilot flying at night or in cloud would have no option other than to place total reliance upon the accuracy of the chart. Thus:
... although a sheet of paper might not be dangerous, per se, it would be difficult indeed to conceive of a saleable commodity with more inherent lethal potential than an aid to aircraft navigation that, contrary to its own design standards, fails to list the highest land mass immediately surrounding a landing site. (Fluor Corp. v. Jeppesen , 170 Cal App 3d 468)
Given that the Consumer Protection Act provides that the adequacy of any instructions for use supplied with a product are to be taken into account in determining whether it is defective, there seems no good reason why the legislation should not apply where the instructions constitute the product. Instances of this, however, are likely to be few in number. Although there has been a proliferation in the number of expert systems in safety related fields such as engineering and medicine these are invariably intended to be used to provide advice and guidance on a specialised topic to a user who possesses a general level of skill and experience of the subject.
One of the most controversial aspects of the Consumer Protection Act concerns the provision of a development risks defence. In part the controversy arises from a difference in terminology between the European Directive and the implementing UK legislation. The former provides the producer with a defence where it is established that:
... the state of scientific and technical knowledge at the time when he put the product into circulation was not such as to enable the existence of the defect to be established. (Article 7(e))
The Consumer Protection Act provides that the defence is to apply where a producer is able to establish that:
... the state of scientific and technical knowledge at the relevant time was not such that a producer of products of the same description as the product in question might have been expected to discover the defect if it had existed in his products while they were under his control ... (Section 4(1)(e))
Use of the phrase "might have been expected" appears to render the UK provision more favourable to a producer than the original version. The European Commission at one stage threatened proceedings against the UK Government alleging that the change in terminology constituted a failure fully to implement the provisions of the Directive. To date, no action has ensued.
The question how far the defence (in whatever version) may be relevant in a software context has been the subject of extensive debate. Given the recognition that the state of scientific and technical knowledge does not permit the exhaustive testing of software, some commentators have argued that the defence will be of considerable utility. The contrary view is that a distinction exists between risks whose occurrence was not foreseeable and defects whose existence was undiscoverable. The case of Smedleys v. Breed ([1974] AC 839) provides a helpful illustration of this rather opaque distinction. The appellants had been convicted of an offence under the terms of the Food and Drugs Act 1955. Section 2(1) of this Act prohibited the selling of food which was not of the nature, substance or quality demanded by the purchaser. At issue in the case was a can of peas which contained an unadvertised extra ingredient in the form of a caterpillar (deceased). Liability under the Act was strict but the appellants argued before the House of Lords that they were entitled to the benefit of a statutory defence applying where it could be demonstrated that the presence of the extraneous object "was an unavoidable consequence of the process of collection or preparation" (Section 3(3)).
In the year in question, 1971, the appellants had produced some 3,500,000 cans of peas and received only 4 complaints involving the presence of foreign bodies. Extensive checks involving both mechanical devices and human inspection were conducted by them but, presumably owing to a momentary lapse of attention by one of their checkers, the caterpillar escaped discovery. Statistically, the appellants' performance was impressive with a complaint rate of little more than one in a million cans. It was accepted that nothing more could feasibly be done to improve the control system. However, as was stated by Lord Hailsham:
What has to be shown in order to constitute a defence under section 3(3) of the Act is not that some failures are unavoidable and that, owing to the excellence of the system, statistically the failures have been few. This is a matter for mitigation. What has to be shown under section 3(3) is that "the presence of that matter" (i.e., the particular piece of extraneous matter) in the particular parcel of food the subject of the charge was "the unavoidable consequence of the process." As I ventured to point out in the argument, over a long enough run any sort of process, however excellent, will statistically result in some failures, human or otherwise, and these are statistically predictable in the light of experience. But that will not necessarily be a defence under section 3(3).
In the case of software it is the vast number of possible interactions which defeats any attempt at exhaustive testing rather than the intrinsic difficulty of the task of identifying a particular defect. A further argument may also be advanced against the application of the development risks defence. To an extent greater than with any other product, software is a creation of the human mind. Any defects are introduced by its creator(s). It would appear contrary to the aims of the legislation to allow a party to be allowed both to create a defect and subsequently claim that this was unforeseeable.
There will be many situations when the Consumer Protection Act will be of little relevance. It may be that the damage caused falls outside the somewhat narrow boundaries established by the statute. It may also be that the damage resulted from the act or omission of someone other than a producer. The following section will consider the rights and remedies which may exist when parties are in a contractual relationship. Initially, however, consideration will be given to the application of principles of non-contractual liability.
In order to establish liability under the law of tort/delict a pursuer is generally required to establish that the defender was negligent. The basis for this may lie either in an act or an omission. Two candidates may be identified for the role of defender. First consideration will be given to the liability of a producer or supplier of software and, second, to the liability of a party using (or failing to use) software in the course of their work.
The concept of the "reasonable man" is one of the most famous creations of the common law. A defender will be liable if he or she failed to display the level of skill and care reasonably to be expected of them. The value of the concept lies in part in its flexibility. Effectively, individuals will be judged by the standards of their peers. Such an approach can be of maximum effectiveness in the case of an established profession or activity. In the present context, the question "what would a reasonable software producer (or supplier) do?" has to be prefaced by that of "Who is a software producer?" Although a number of professional bodies such as the British Computer Society operate in the area, these lack the status of the regulatory bodies associated with the older professions such as law, accountancy and medicine.
A common issue in debate on the use of and failures in safety critical software systems is the aleged over dependence of human operators on the computer elements. An example recently cited concerned an experiment conducted on subjects who, without their knowledge, were given specially programmed calculators, then told to compute a few simple sums. The results indicated that most people trusted the machine even when a simple mental calculation would have given a different and correct answer. The experiment raises interesting questions concerning the possibility of such attitudes prevailing even in the highest levels of science. Is it wise to allow computer modelling to replace human observation? Of course, it is widely accepted that the use of new technology is essential if scientific advances are to be made. It has been said that the development of the Space Shuttle would not have been possible without Computer Aided Engineering. Bearing this in mind, what standards are to be expected of those who design or engineer systems which may be safety critical and how does the law apportion liability?
Of course a decision to adopt an innovative technique, as yet not extensively used, in itself will rarely be classed as negligence, but special care must be given to its application. If the innovative technique fails, and it is established that no reasonable member of that profession would have employed such a method, then the use of such a technique may be judged to be negligent.
Although the use of new technology always carries a certain degree of risk, it may well be that overall the level of risk is reduced. The system may be safer, although not totally risk free, if designed by new technology and by the application of new methods. Bearing this in mind, might it ever be considered negligent not to use a computer based technology? A number of earlier cases concerned with the shipping industry and its relationship with new technology provide useful parallels with the use of computers and computer simulated models.
In the case of T.J. Hooper (60 F 2d 737 (1932)), two barges were lost at sea partly because their tugs had not been equipped with working radio receivers. If radios had been installed, it would have been possible to listen to weather forecasts thus enabling them to seek shelter from the storm. At that time the installation of radios on tugs was not common practice. In spite of this, the owners were held to be negligent on the basis that "A whole calling may have unduly lagged in the adoption of new and available services"
However in the case of United States Fire Insurance Co. v United States (806 F.2d 1529 (1987)), Coast Guards who failed to identify the location of a hazard to navigation, were held not to be negligent even although it was agreed that an available computerised method was superior in its accuracy to the manual technique actually used by the coast guards. At an earlier stage, a court had found the Coast Guard to be negligent by not marking the position of the wreckage correctly but the Appeal Court held that the Coast Guard was not under an absolute duty to mark wreckage, but only to exercise due care in searching for it. The point was made that
...the district court must consider what actually transpired, not simply against what would have transpired [had the marker been in the correct location] but rather against what probably would have occurred had the Coast Guard exercised due care.
The fact that the desired result (in light of hindsight) did not occur does not imply that reasonable skill and care was not used, nor is it sufficient merely to establish that a new method which could have been adopted is superior to the old method. It must be established that in the circumstances, the risk was identifiable, that the failure to adopt the new method or the new technology was in itself a breach of a duty of care and that in the absence of such a breach, the loss or injury would not have occurred.
The likelihood of establishing negligence may depend on the extent to which the use of the new technology would have minimised the risk of loss or injury. Would use of the new technology have been very likely to have prevented such an error, or would it merely have reduced the risk but not eliminated it ? Of course such questions can only be resolved after the event on the basis of available expert evidence.
However, it should be said that manufacturer and designers must endeavour to keep themselves informed of new technical developments, as it is possible that a failure to adopt a new method could be considered negligent if an injury or loss occurred which would have been very unlikely to have occurred had the new technology been employed. Judging by T.J Hooper , this may apply even if the use of such technology is not yet standard practice. Failure to respond to an identifiable risk may well be considered to be negligent.
In the situation where the operation of software or a software based product has resulted in injury or damage an action may lie in delict or under the provisions of the Consumer Protection Act. The latter statute offers no remedy when loss is economic in nature whilst the availability of compensation for economic loss in the law of delict has been severely restricted by recent decisions of the House of Lords. In the situation where the complaint relates to the quality of the performance of software the only realistic prospect of success lies under the law of contract.
Once again, the issue of the status of software may be a matter of some significance. If the transaction is regarded as involving goods (whether a sale or other form of transfer) the implied terms of conformity with description, merchantable quality and fitness for purpose will apply with the supplier being held strictly liable for any defects in the goods supplied. If software should be regarded as a species of service, the supplier will be held strictly liable in respect of any goods supplied. In respect of the service component, however, the supplier will be required only to exercise of reasonable skill and care with liability being imposed only if negligence can be established.
In determining the distinction between these two species of contract, two distinct lines of judicial authority can be identified. In the case of Lee v. Griffin ((1861) 1 B&S 272), the Court of Appeal was faced with a contract under which a dentist undertook to make a set of dentures for a patient. A dispute subsequently arising, the court was faced inter alia with the question of the contract's proper categorisation. Holding the contract to be one of sale, the court held that the essential criteria was whether anything that could be the subject matter of a sale had come into existence. In the event, for example, that an attorney was engaged to draw up a deed for a client, it was held that the contract would be one for services. In other situations, however:
I do not think that the test to apply to these cases is whether the value of the work exceeds that of the materials used in its execution; for, if a sculptor were employed to execute a work of art, greatly as his skill and labour, assuming it to be of the highest description, might exceed the value of the marble on which he worked, the contract would in my opinion, nevertheless be a contract for the sale of a chattel.
Although it might be argued that any piece of tangible property must have some intrinsic value, however small, it would appear that this test requires that the product have some significant resale value in its own rather than in a representative capacity.
The distinction between sale of goods and supply of services was again at issue before the Court of Appeal in the case of Robinson v. Graves ([1935] 1 KB 579) The contract here was one whereby an artist agreed to paint a portrait of his client's wife. On the basis of the situation hypothesised in Lee v. Griffin it would appear that such a transaction should be regarded as one of sale. In the event, however, it was held that it should be regarded as one for services. In reaching this conclusion the Court sought to identify the prime purpose of the contract. In the oft quoted words of Greer LJ:
If the substance of the contract ... is that skill and labour have to be exercised for the production of the article and ... it is only ancillary to that that there will pass from the artist to his client or customer some materials in addition to the skill involved in the production of the portrait, that does not make any difference to the result, because the substance of the contract is the skill and experience of the artist in producing the picture.
Although the court in Robinson v. Graves did not overrule, or even distinguish, the earlier authority it must be doubted how far the two approaches can truly be considered compatible. In attempting to consider further the basis of the distinction between goods and services, a measure of assistance may be obtained from the United States' authority of Barbee v. Rogers (425 SW 2d 342 (1968)). Here, a firm of opticians advertised the provision of contact lenses at a fixed charge. One customer suffered eye damage, allegedly as a result of the provision of unsuitable lenses, and brought an action under the relevant sale of goods legislation. Holding that the transaction should be characterised as one for services it was held that although a uniform price was charged for contact lenses the amount of attention required by each customer would vary as would the prescription for the individual sets of lenses. Although this notion of the contract for services representing a unique relationship between the provider and the receiver cannot provide a single infallible test as to the status of the transaction (see Samuels v. Davies) it will hold true in many cases. In the event, for example, that a customer contracts with a photographic processing laboratory with a view to his film being developed and printed, this transaction may be one of hundreds or even thousands entered into by the laboratory on that day. All of these films will be subjected to identical processes within the laboratory yet each contract will be unique in that every customer must receive his own film back and the contract will be one for services. The converse proposition may be more certain. Where identical items are produced and sold without modification, regardless of the amount of labour exerted in the production process, the ultimate transaction must be regarded as one of sale.
Much legal ink has been consumed in discussion of the question whether software should be regarded as a product or a service. On occasion the discussion proceeds from the false premise that there is a single type of software. In reality, three basic types may be identified. In many large scale software contracts, a party is contracted to produce a single version of a computer program for the exclusive use of a single customer. Such a transaction seems to fit most naturally into the services category. At the opposite end of the software spectrum is standard software. This will include application packages such as spread sheet or word processing programs produced for use on personal computers. By the criteria identified above, these should be regarded as involving goods. Somewhere in between comes a category referred to as customised software. This sees a standard program being modified to suit the needs of a specific customer and may be an area which is not susceptible of precise categorisation.
In many situations a contract will relate to the provision of a computer system containing a mixture of hardware and software. In such cases there appears no doubt that the transaction will be regarded as one for goods. When discussion has occurred concerning the status of software in isolation the view has generally been taken that it was not necessary to determine the point. Thus, in the case of Eurodynamic Systems v. General Automation (Queens Bench Division, 6 September 1988), Mr Justice Steyn after surveying a number of United States authorities suggesting that software should be regarded as goods, stated that "the decision on this point is not of critical importance". It is well established that the requirements of merchantability and fitness for purpose are not generally to be interpreted as requiring that a product be perfect. In the case of software, it was stated:
... the expert evidence convincingly showed that it is regarded as acceptable practice to supply computer programmes (sic) (including system software) that contain errors and bugs. The basis of the obligation is that, pursuant to his obligation (free or chargeable as the case may be), the supplier will correct errors and bugs that prevent the product from being properly used. Not every bug or error in a computer programme (sic) can therefore be characterised as a breach of contract.
Similar views were expressed by Staughton LJ in the case of Saphena Computing Ltd. v. Allied Collection Agencies Ltd. (Court of Appeal, 3 May 1989). This case concerned a contract for the provision of software. The software was installed between September 1985 and February 1986. By the 11th of February 1986 it remained incapable of functioning in a satisfactory manner and in a telephone conversation between the parties it was agreed that the contract relationship should be terminated. The issues to be resolved in the legal proceedings under discussion concerned, inter alia, the customer's claim for compensation on the ground that the software supplied was not reasonably fit for its purpose. Delivering the judgement of the Court of Appeal, Lord Justice Staughton held that it was:
... common ground that the law governing these contracts was precisely the same whether they were contracts for the sale of goods or the supply of services. It is therefore unnecessary to consider into which category they might come. But it is important to remember that software is not a commodity which is handed over or delivered once and for all at one time. It may well have to be tested and modified as necessary. It would not be a breach of contract at all to deliver software in the first instance with a bug in it.
Although it was accepted that the software was not in an acceptable condition on the date when the contract was terminated, it was held to be part of the contract that the suppliers should have the "right and the duty to test and modify as necessary the software they supplied". The customer's over hasty action in terminating the contract deprived the supplier of their right and relieved them from their duty to modify the software.
Similar issues arose in the case of Simpson Nash Wharton v. Barco Graphics Ltd. (Queens Bench Division, 1 July 1991). In this case, the plaintiffs had agreed to purchase a hardware and software from the defendants for use in the design of packaging for food, drink and pharmaceutical products. The system, which was a new version of an existing product, was delivered on the 20th of June. Despite many complaints and much work by the suppliers over the following months it failed to function in a satisfactory fashion and on October 27th the plaintiffs' solicitors wrote to the defendants giving notice they were rejecting the system and seeking compensation.
The time scale involved in this case was broadly similar to that in Saphena. The defendants, whilst not claiming that the system was operating in a satisfactory manner and even conceding that the plaintiffs might justifiably have rejected the system shortly after delivery. They alleged that by retaining the system beyond the middle of July, the plaintiffs must be deemed to have accepted it. Support for this contention was sought from the decision of the High Court in the case of Bernstein v. Pamson Motors ([1987] 2 All ER 220). In this case, the passage of a period of 3-4 weeks was held sufficient to prevent the purchaser of a new car from rejecting what was accepted to be an unmerchantable vehicle. Whilst Judge Rivlin accepted Bernstein as authority for the proposition that the determination what was a reasonable time for the buyer to examine goods with a view to discovering any defects was dictated by the nature of the goods rather than by that of a particular defect, he held that:
... the goods in this case were highly sophisticated goods which required a deal of training to understand and work them satisfactorily, and moreover they were goods which were being constantly developed and improved by the provision of new software and the like.
Although the plaintiffs' succeeded in the present case, the dilemma facing customers is apparent and the position may be considerably less satisfactory in the situation where a software defect manifests itself only after a significant period of time. As the case of Bernstein indicates, of course, problems are by no means confined to the software sector.
The cases heard so far are of limited precedential value, indicated by the fact that so few have found a place in the Law Reports. In every case, the contracts have been for comparatively large scale projects - the contract in Simpson Nash Wharton was costed at some [[sterling]]206,000. Without exception, the courts have avoided giving a direct answer to the question whether software is a product or a service, in large part because the negotiations leading up to the conclusion of fairly major contracts have allowed them to claim that they are merely interpreting the terms of the particular bargain between the parties. The issues may have to be addressed more directly if and when disputes concerning smaller scale, possibly consumer, contracts involving standard software are litigated. It would appear from the cases decided to date that at least some functional requirements will be implied into any contract and consideration will require to be given to the interpretation of the famous concepts of merchantable quality and fitness for purpose.
Standard software packages are invariably supplied with a licence, generally referred to as shrink wrap licences. The term dates back to the early days of home computers when programs, normally in the form of games, were supplied on cassette tapes and the terms of a basic licence were printed on the cellophane wrapping. Today, the licence is normally buried inside the packaging. A typical approach is for the licence to be printed on the outside of an envelope in which are contained the program disks. A statement is normally printed to the effect that opening the envelope will constitute acceptance of the terms of the licence.
It is extremely questionable whether the terms of such a licence can ever be considered binding on a customer. The contract with the supplier will normally have been concluded some time before the packaging is opened and the terms of the licence revealed. The licence will therefore represent a unilateral attempt by the supplier to impose new terms and conditions. On the authority of the English case of Thornton v. Shoe Lane Parking ([1971] 2 QB 163), it may confidently be asserted that such techniques will not be accepted by the courts. A further complication is that the software may be supplied by an intermediary retailer whilst the licence is issued by a producer. In this situation there will be no contractual relationship between the licensor and potential licensee.
The licence itself may normally be divided into two sections. The first appears rather user friendly and will confer rights to use the software in specified ways and to make back up copies. Although the implementation of the European Union Directive has enhanced the statutory rights of a software user, these are still limited especially in relation to the making of back up copies. Such benefits come at a price for the user. The second element of the licence invariably seeks to exclude liability for any loss or damage suffered as a result of a defect in the software. Although the trend appears to be towards a more limited form of exclusion, until very recently one of the market leading word processor packages sought to exclude liability to make even a refund of the purchase price in the event that a fault on the disk supplied rendered the software unusable.
To an extent, the reluctance on the part of software suppliers to accept responsibility for losses resulting from its operation may not be unreasonable. To an extent greater than with other products, software may be used in a great variety of circumstances. An incident has been reported, for example, of a heart surgeon using a standard spreadsheet package to analyse data relating to patients in the course of an operation. Any error in the program could have fatal consequences. Even in its "normal" field of operation, a spreadsheet may be used for household accounts or to prepare a bid for a multi-million pound contract. Unlike the situation applying in cases such as Saphena above where the software was "not delivered once, only once and once and for all" there is little prospect of errors being corrected on an individual basis although the offer of free or reduced price upgrades of the software may be considered somewhat analogous. The question whether software is defective will have to be determined largely by reference to the state in which it was delivered. Even assuming the application of the Sale of Goods Act, perfection is seldom to be equated with merchantability, whilst applications such as those described above might be regarded as special purposes requiring notice be given to the supplier as a condition for the application of the implied term of fitness for purpose.
The conclusion may be that the application of the implied terms of merchantability and fitness for purpose in the context of standard software will not prove ruinous to software producers and suppliers. It may be that attempts to exclude liability may be more perilous. The operation of the Unfair Contract Terms Act renders invalid any attempt to restrict or exclude the application of the implied terms of the Sale of Goods Act in the case of consumer contracts and subjects these to the application of a test of reasonableness in other cases. Further, the Consumer Transactions (Restrictions on Statements) Order 1976 renders criminal the mere attempt to invoke such clauses.