Terms like ‘computer contract’ or ‘system procurement contract’ cover a broad range of commercial transactions, from the purchase of a single CD-ROM from a high street retailer through to multimillion pound agreements for consultancy or outsourcing services. This chapter outlines the legal issues that need to be addressed in any contract of this type, using examples from actual case law to illustrate the kinds of dispute that commonly arise in relation to systems procurement, and discusses how the process of drafting and negotiating the agreement can be used to prevent some of the most common problems.

THE NEGOTIATION PROCESS

The function of a written contract is to record the terms governing the supply of goods and services. In the absence of a clear, express understanding between the parties, certain terms may be implied into the contract as a matter of law, for example, that products will be delivered within a ‘reasonable’ time and that they will be of ‘satisfactory’ quality. The main terms that can be implied into a contract as a matter of law are summarised in the box.

However, given the vagueness of the implied terms and the unpredictability of their legal interpretation, any prudent buyer or seller of IT systems will prefer to ensure that the parties’ intentions are recorded as clearly and unambiguously as possible.

The negotiation process that leads to the written contract should help ensure that the parties understand each other’s expectations and commitments.

Many IT projects fail precisely because the parties do not exercise sufficient care to ensure that their expectations match, and often because of an uncritical acceptance by the customer of the supplier’s standard terms of business (or indeed, by the supplier of the customer’s standard procurement contract).

Any well-drawn contract will have provisions relating to three broad categories of expectation. The aim of the negotiation process is to ensure that no essential terms are missing from the final agreement, and this chapter will address each of the categories in turn:

• Contract mechanics–who delivers what, and when?
• Commercial highlights–what is the price, who owns the resulting intellectual property rights, and what warranties are given in respect of the system?
• Problem management–what happens if the project goes wrong and what remedies are available?

BEWARE THE STANDARD CONTRACT

The dangers of agreeing unquestioningly to the standard supply terms (or, for that matter, to a client’s standard terms of procurement) are illustrated by the case of Mackenzie Patten v. British Olivetti.

A law firm bought an Olivetti computer system to run their accounts. They discussed their needs with the salesperson and signed up to Olivetti’s standard terms. These dealt only with the system’s technical performance: they did not address certain other important issues that had been discussed between the parties.

In the event, the system proved unsuitable for the firm’s purposes: it was slow, difficult to use, and could not expand to cope with new business, but none of these matters was dealt with in the written contract. Even though a court found that Olivetti was bound by its salesperson’s claims that the system would be suitable for the law firm’s needs, the firm had by that stage expended significant time and money in the litigation and still had to find a replacement system.

Put another way, ‘standard’ forms are only suitable for entirely ‘standard’ transactions, and will often fail to address some essential point that the parties had in mind for their particular deal.

CONTRACT MECHANICS

Principal obligations

An IT contract need not be a complex document. It does not even need to be in writing, though a written document is clearly desirable to record fully each party’s commitments to the other. In the simplest case, however, a written contract need say no more than this: that the supplier will provide a system X computer to the client; and that the client will pay £Y to the supplier.

That is the essence of the commercial relationship and there is nothing else (from the strict legal point of view) that requires to be said. However, if the aim of the contract process is to ensure that the project goes ahead smoothly and with the minimum scope for disagreement between the two sides, the contract should be considerably more specific in terms of what is being delivered, when and how.

Specification

A clear specification is the foundation stone of a successful systems supply contract. Although the law implies a term into a contract that the system will conform to its description and be of satisfactory quality, this is no substitute for ensuring that the supplier and the client agree (and document, in as detailed a manner as possible) exactly what is to be provided and the performance and quality standards to be achieved.

Every system supply contract should, accordingly, include a detailed specification setting out:

• the required functionality (what the system is required to do);
• performance targets (how well it is supposed to do it);
• compatibility requirements for interfaces with other systems.

The need for a formal system specification

The legal implications of not developing a proper specification are illustrated by the case of Micron Computer Systems Ltd v. Wang (UK) Ltd.

One of Micron’s complaints against its supplier was that the Wang system did not provide ‘transaction logging’. The judge observed that ‘the acknowledged absence of a transaction logging facility is not in reality a fault in the system that was sold. Micron can only complain about its absence if Micron can establish a contractual term … to the effect that the system included such a facility. In order to make good its case in transaction logging, Micron must therefore establish that they made known to Wang that they required such a facility’.

The judge found that Micron had not made its requirement for transaction logging clear to Wang and accordingly that part of Micron’s case failed.

Timetable

The process of preparing the specification should enable the parties to assess the likely timescale for the project and to prepare a project plan setting out key deliverables (or ‘milestones’) and their expected dates. In almost all major systems implementations, staged payments will be triggered by the achievement of individual milestones. It is, accordingly, essential that these are identified with as much precision as possible and generally reflect the terminology of the contract.

The buyer will usually have in mind a timescale within which the system should be provided, although the sophistication of the timetable will vary according to the complexity of the project and how closely the payment arrangements are tied into the achievement of specific milestones.

Delivery

Although the law provides for an implied term that goods will be delivered ‘within a reasonable time’, delivery arrangements should always be dealt with expressly. From the point of view of contractual certainty, the ideal approach is for the contract to set out specific delivery dates, but it should also go on to deal with the ‘mechanics’ of delivery and installation. The contract should address:

• the date on which delivery is to be made;
• whether all the elements of the system are to be delivered at one time or whether it is to arrive in instalments;
• who has responsibility for installation and testing;
• the implications of late delivery or non-delivery (e.g. an express provision permitting cancellation of the contract, with or without compensation to the buyer, if the goods are not delivered by some cut-off date or if some other key milestone is not achieved by the required date).

Acceptance testing

Formal acceptance testing arrangements are a crucial aspect of any successful procurement. The system is required to meet the functions and performance targets set out in the specification, but until it is tested the parties can not determine whether those requirements have been met.

The nature of acceptance tests varies widely between projects. Where a major piece of development work is involved, the parties may negotiate and document detailed testing arrangements as part of the contract. At the other extreme, the acceptance procedure may simply be that if the buyer uses the system ‘live’ for, say, 30 days without rejecting it, then it is deemed to have been accepted.

From the point of view of creating contractual certainty, then, the acceptance procedure should:

• provide for an objective and measurable ‘yardstick’ as to the standards of performance and functionality to be demonstrated;
• address all those elements that are necessary to demonstrate, to the buyer’s satisfaction, that the system meets its requirements; and
• be clear as to the consequences of both the passing and failing of the acceptance test.

Acceptance will generally trigger payment of the whole or the final instalment of any lump sum charges, or the start of periodic charges, and following acceptance the buyer’s remedies will be limited to a claim under the warranty provision.

In the event of failure of the acceptance tests, the contract will typically provide for a period during which the supplier may rectify problems and then retest; but further failure will signal the premature end of the contract, with the buyer able to return the hardware and software in exchange for a refund of any money paid.

Client obligations

The successful implementation of a complex IT system normally requires the performance of obligations not just by the supplier, but also by the client. Although primary responsibility for providing a system rests with the supplier, the client may well have obligations in relation to providing information about its business, testing the software, providing employees to be trained and so on.

These obligations need to be spelled out in the contract every bit as clearly as the supplier’s commitments.

Change control

Client requirements may change frequently over the lifetime of a project. The parties need to agree a procedure for specifying and agreeing changes to the scope of work. The proper management and documentation of these changes will help to avoid disputes about what each party’s obligations actually were.

The contract should include a formal ‘change control’ clause, setting out a mechanism whereby the client can request (and the supplier can recommend) changes to the specification, the project plan, or any other aspect of the deal. Any such change needs to be considered from the point of view of:

• technical feasibility;
• impact on the respective obligations of the supplier and client;
• cost implications;
• impact on the timetable.

As a general rule, no change should take effect unless it has been formally agreed and documented by both parties.

Termination

Provision has to be made for termination of the contract, setting out the circumstances in which the contract may be brought to an end and the consequences of that action. These provisions will vary according to the nature of the contract and the deliverables.

Apart from a general right to terminate the contract in the event of material breach or the insolvency of the other party, the following points should be considered:

• The client may wish to reserve a right to cancel or terminate the contract for convenience (say, because its business requirements change). In that event, the parties will need to discuss what compensation (if any) should be payable to the supplier.
• Contracts for development services are typically terminable by the client if specific time-critical milestones are significantly overdue. Provision should be made for treatment of the developed software on termination, including delivery of all copies (and source code) and certification that no copies have been retained.
• Contracts for continuing services (consultancy, support and maintenance services, bureau services) should be terminable on notice. The length of the notice and the earliest dates on which it may be effective are matters of negotiation in each case.

COMMERCIAL HIGHLIGHTS

Pricing and payment

There are as many pricing and payment structures as there are types of IT deal, and there is little to be gained from making generalisations about pricing and payment terms. The one point worth making is that, where payments are tied into specific targets (such as system acceptance or other milestones), the terminology and structure of the payment schedule should accurately reflect that of the timetable.

There are several payment-related mechanisms that are commonly used to ensure that both parties have incentives to perform their obligations:

• The client may wish to provide for payment by instalments as the various parts of the system are delivered, retaining a proportion of the price until the complete system has been tested. The retention of a significant proportion of the charges will give the buyer some assurance that the supplier will finish the job.
• In respect of periodic fees, specifically, the buyer will be concerned about the supplier’s rights to increase the fee and may seek to limit rises by agreeing to, for example, only one increase a year or by tying increases to an appropriate index.
• It is common for hardware suppliers to retain title in the goods they supply as security for payment. This means that although the buyer gets possession of the goods, ownership remains with the seller until certain conditions (normally payment in full) are met. If the buyer fails to comply with the conditions, the seller can repossess the goods and sell them to recoup its losses.

Intellectual property rights (IPRs)

System supply contracts generally entail the transfer of technology and information from one party to another, for example, specifications, software, data and confidential business information. The lawful use of technology and information depends on compliance with the laws relating to copyright, confidentiality, database rights and other forms of intellectual property (see Chapter 4), so system supply contracts must deal comprehensively with IPR issues. There are two key IPR aspects to consider: ownership, and warranties and indemnities in respect of third-party IPRs.

In relation to ownership, the contract should specify what IPRs are to be created or used, and precisely who owns them (including identifying the owners of any third-party IPRs that are to be used or licensed). Copyright law contains a common trap for the unwary in relation to contracts for software development or consultancy work. The IPR in work undertaken by a contractor (as opposed to an employee) will normally vest in the supplier rather than the client. This means that an express, written assignment of copyright is needed if the aim is for the client to own these IPRs outright.

In relation to warranties, most system supply contracts will contain an assurance that the client’s use of the system will not infringe third-party rights and an indemnity in respect of any claims that may arise against the client. The contract should set out any express warranties required by the client as to the supplier’s ownership or entitlement in respect of the IPRs comprised in the system, together with a process for addressing any breach of those warranties.

In relation to the possible infringement of third-party IPRs, the client will typically impose a formal obligation for the supplier to deal with any such allegations, especially if the system is a critical part of the client’s business and merely rejecting it and claiming back the purchase price would be insufficient. A typical IPR indemnity clause will provide:

• a right for the supplier to take over, litigate and/or settle any such action;
• a right for the supplier to modify the system so that it does not infringe the alleged right, provided that it still conforms with the specification; and
• an indemnity given by the supplier against the client’s losses in the event of a successful third-party claim.

Supplier warranties

The client will normally require the supplier to give certain other express assurances in respect of the system to be delivered. Ideally, the client will want to obtain a warranty that the system will comply with its specification and/or meet specified performance criteria.

Such warranties are often subject to time limits or other restrictions. It is not unusual for the supplier to seek to limit the warranty to, say, six months from acceptance: after that point, any defects are rectified under maintenance and support arrangements (paid for by the client) rather than under warranty.

PROBLEM MANAGEMENT

Contractual remedies

The parties must consider at the negotiation stage what happens if a contract does not go according to plan, for example if the supplier fails to deliver a working system within the contracted time frames. Although damages and other remedies may be available as a matter of general law, it is preferable to spell out expressly the remedies that each party may have in particular situations.

One common mechanism for managing such disputes is to provide for payment of ‘liquidated’ damages for certain breaches. This involves setting out in advance the precise sum to be paid as compensation for certain breaches (e.g. late delivery at £X per day). Provided that the sum is a genuine estimate of the likely losses and not a penalty to force the other party to perform, the clause will be enforceable.

If the breach in question persists for a specified time or reaches a specified level of severity, the innocent party may also want a right to terminate the contract outright.

Limitations and exclusions of liability

IT suppliers generally seek to restrict their potential exposure to actions resulting from breach of contract or defects in the system. This is treated by some as purely a ‘legal’ issue, but in fact is a major question of commercial risk assessment and allocation, and these provisions can be amongst the most hard-fought in any contract negotiation.

A typical standard exclusion clause may take the following form:

• The supplier does not exclude liability for death or personal injury caused by negligence.
• The supplier seeks to exclude liability altogether for certain kinds of loss, often termed ‘special’, ‘indirect’ or ‘consequential’.
• The supplier accepts a limited degree of liability for certain other classes of loss.

From the legal point of view, exclusion clauses need to be considered from two broad angles. First, suppliers will often argue that they should have no liability for ‘consequential loss’, on the basis that the nature of IT products means that their uses (and so the potential losses resulting from failure) are not easily foreseeable at the time the contract is made and the potential exposure is in any case disproportionate to the contract value. Whether this is an acceptable commercial stance depends on the nature of the system and the extent of the client’s dependence on it. However, the courts have exercised considerable ingenuity in manipulating and interpreting expressions like ‘consequential loss’ in ways that the parties may not originally have intended.

Secondly, there is an extensive body of law relating to the enforceability of exclusion clauses generally: if the exclusion clause is found to be unreasonable or defective in some other way, then the party seeking to rely on the exclusion may nevertheless be exposed to a greater degree of legal and financial risk than it originally envisaged.

The combined effect of the enforceability rules and the uncertainty about the meaning of commonly used language is that clarity is of the utmost importance in the wording of exclusion clauses: it is not in anybody’s interest for the effect of the exclusion to be uncertain and indeed it is surprising that businesses should continue routinely to use some of the terminology that regularly crops up.

Instead of debating abstract concepts like ‘consequential loss’, suppliers and clients alike should focus on the specific risks associated with the particular system. The client will generally accept that the supplier has a legitimate concern about exposure to unspecified types of liability, but the kinds of loss that will flow from a breach of an IT supply contract can be classified, at least in general terms:

• Loss of cost or salary savings, or other expected benefits.
• Costs of repairing or replacing the defective system.
• Costs of additional IT staff and consultants required to make the system work.
• Loss of profits resulting from non-performance.
• Costs of wasted management time.

These categories of loss are not intended to be definitive: there is no ‘definitive list’ as such, and each client and supplier will have its own specific concerns.

However, the starting point for constructing an effective provision must be to identify the categories of loss that are foreseeable, and to state explicitly how the parties intend to allocate these risks between themselves. Any unspecified types of loss will then fall to be determined by the court according to normal legal principles.

ENFORCEABILITY OF EXCLUSION CLAUSES

The contra proferentem rule

An exclusion clause will only operate to limit a party’s liability if it covers the breach that has occurred. The rules of interpretation are complicated, but in general the more serious the breach of contract, the more clearly worded the clause must be if it is to exclude liability for that breach: it is interpreted against the person who seeks to rely on it.

One illustration of this rule at work is the case of Salvage Association v. CAP Financial Services Ltd. In that case, a contract to supply bespoke software contained a warranty from the supplier under which it promised to remedy certain types of defect, and also provided that a limitation of liability would apply ‘if CAP fails to perform its obligations under [the warranty]’.

The wording of the warranty was sufficiently ambiguous that the court could interpret it as meaning that the warranty did not come into effect until after acceptance of the system by the client. Acceptance had never in fact occurred because the dispute began before the contract’s acceptance procedures were reached, so the court decided that the warranty never came into effect and so the exclusion of liability never came into effect either. The result was that the supplier’s liability for breach of contract was completely unlimited.

The ‘reasonableness’ test

Under Section 3 of the Unfair Contract Terms Act 1977 (UCTA), where the buyer deals either as a consumer or (if the buyer is a business) on the seller’s written standard terms, any exclusion clause favouring the seller must satisfy a test of ‘reasonableness’ in order to be effective.

The measure of ‘reasonableness’ is whether it was fair and reasonable to include the clause at the time the contract was made. The court will take account of matters such as the following:

• The relative bargaining position of the parties.
• Whether the buyer received some benefit (e.g. a lower price) for agreeing to the clause.
• How far the buyer knew or ought to have known of the existence and extent of the clause.
• If the exclusion is contingent on compliance with some condition (e.g. regular maintenance), whether it was reasonable to expect the condition to be complied with.
• Whether the goods were ‘off the shelf’ or were specially made or adapted to the client’s order.

The courts have also held that the question as to which of the parties can most readily insure against the loss is a relevant consideration and that a limitation of liability is more likely to be reasonable than a complete exclusion.

The appendix to this chapter outlines the way in which the courts have applied the UCTA reasonableness test in practice.

Special considerations in software contracts

Computer programs are governed mainly by the law of copyright, which requires that the user of a program has a licence from the copyright owner. (Note that the term ‘licence’ is synonymous with ‘permission’ or ‘consent’.)

There are no particular legal formalities with regard to the form of the licence, but it is desirable for the licence to be in writing to ensure that there is complete clarity as to what may and may not be done with the software.

The type of licence depends on the nature of the package:

• Standard software is often supplied by retailers or distributors under a ‘shrink-wrap’ licence: the disk is wrapped in a clear plastic film, through which the terms of the licence granted by the copyright owner are clearly visible, along with an instruction that breaking the seal on the package will amount to acceptance of those terms.
• Contracts for bespoke software tend to be entered into on a more formal basis because of the need to agree a specification and to address other issues arising out of the development process. (It may also be the case that the client wishes to own the program outright rather than use it under licence, in which case see the warning in the section on IPRs as to the need for an express assignment of copyright from the contractor.)

The term of the licence may be perpetual or for a fixed period. Again, it is desirable for the term to be spelled out expressly because, in the absence of any express contractual provision, the normal rule is that an intellectual property licence is terminable by ‘reasonable notice’.

The licence will often impose restrictions on the use that the client may make of the software. Common restrictions include:

• limiting the number or class of users who may access the software;
• restricting use to the ‘internal purposes’ of the client (to prevent the client depriving the supplier of potential licence fees by using the software to provide bureau services to third parties);
• prohibiting the client from transferring the software to any third party, on the basis that the supplier has a right to know precisely who is using its software.

These are all legitimate concerns on the face of it, but the client should check the wording carefully to ensure that the permitted uses reflect all its present and anticipated future requirements. Exceeding the permitted use may leave the client exposed to a claim for copyright infringement or to being charged additional licence fees. At the very least, consider:

• Does this wording prevent the client processing data on behalf of other companies in its group?
• Does the clause operate in such a way as to allow the supplier to impose undefined conditions (such as additional licence fees) in the event of a transfer of the software?
• Might the restriction operate to prevent the client getting a third party to run the system as part of an outsourcing arrangement?

CONCLUSION

The delivery of a working system that meets the client’s needs is a difficult enough task, but it is even more difficult to achieve in a contractual vacuum.

Clearly recording each party’s contractual obligations and setting up appropriate mechanisms for resolving potential disputes will help to ensure the project stays on track. Defining those obligations and mechanisms is the principal purpose of the contract negotiation process.

APPENDIX: THE ‘REASONABLENESS’ TEST IN PRACTICE

St Albans City and District Council v. International Computers Ltd

ICL had developed a complex package (COMCIS) to calculate and administer the community charge (or ‘poll tax’) system of local taxation. St Albans used COMCIS to calculate the number of community charge payers in its area and used that figure to set its community charge rate. The software contained an error, so that although the St Albans database contained all the necessary details, the population figure reported was too high, the per capita charge was therefore set too low and, as a result, St Albans suffered a financial loss.

The contract contained a clause limiting ICL’s liability to the price or charge payable for the item of equipment, program or service in respect of which the liability arose or £100,000 (whichever was the lesser) and completely excluding liability for any indirect or consequential loss or loss of business or profits sustained by the client. Liability turned on whether this clause was reasonable under UCTA.

ICL contested that UCTA applied at all, arguing that the contract had not been on standard terms. However, the judge held that UCTA did apply. Even though many elements of the contract were negotiated at length (e.g. delivery dates and specification), ICL’s standard terms (which contained the limitation and exclusion clauses) ‘remained effectively untouched in the negotiations’, and indeed were referred to by ICL staff as ‘Standard Terms and Conditions’ in witness statements and letters.

The court then went on to consider whether the exclusions were ‘reasonable’ and concluded that they were not. Although St Albans knew of the limitation and had attempted to negotiate it, the following factors operated to render the clause unreasonable:

• ICL had substantially more resources than St Albans.
• ICL held product liability insurance in an aggregate sum of £50 million worldwide.
• ICL called no evidence to show that the limitation to £100,000 was reasonable, either in relation to the potential risk or the actual loss.
• The contract had mistakenly been made on an outmoded version of the General Conditions; in the then current version, the standard limitation had been increased to £125,000.
• Local authorities are not in the same position as private sector businesses: their operations are constrained by statute and financial restraints and they cannot necessarily be expected to insure against commercial risks.
• St Albans received no inducement to agree to the limitation and there was evidence that all ICL’s competitors imposed similar limitations of liability.
• When St Albans tried to negotiate the limitation, albeit at the last moment, ICL in effect said that this was not possible because it would delay the provision of the software to St Albans beyond the date for implementation of the community charge.

The judge accordingly found that ICL had not discharged its burden of proving that the term was fair and reasonable and also that, financially, ICL was better placed to bear a risk of this kind through insurance and to spread it across its client base.

South West Water Services Ltd v. International Computers Ltd

SWW and ICL had entered into two contracts (a turnkey agreement and a project management agreement) under which ICL was to deliver a client service system to SWW. After ICL accepted that it would be unable to deliver the system to specification and in accordance with a planned timetable, SWW sued for breach of contract, claiming that ICL had failed to deliver the system as agreed, and for misrepresentation.

Both agreements had contained a clause based on a standard ICL contract and purporting to limit ICL’s liability for any claim for loss or damage.

The evidence was that, during the negotiations, SWW had originally submitted its own standard procurement conditions to ICL and that ICL had rejected them.

The question then arose whether, in these circumstances, the ICL limitations could be regarded as ICL’s ‘standard terms’. The court followed the St Albans decision in finding that, even though SWW originally offered its own terms in negotiations, in the event ICL had dealt on ICL’s standard terms that had been only slightly adapted. The fact that one fairly predictable eventuality, that is failure to progress the project to a point where there was a system in place for SWW that was capable of being tested, had not been addressed in the documentation also tended to suggest that the contract should be regarded as ‘standard terms’.

The judge went on to note that the extent to which a party has had discussions and has freely entered into a contract on the other party’s standard terms may be relevant as an important circumstance in considering whether those terms are reasonable. ICL argued that its standard limitation clause should be treated as reasonable in this case because its terms had been subject to arm’s length discussion and negotiations, but this was found not be the case on the evidence.

This contribution is based on the author’s chapter on System Supply Contracts, in the 6th edition of Computer Law (2007), published by Oxford University Press.