Software buyers must understand contract law

Nigel Miller: If your software doesn't work, check the contract. Do the wrong thing, and you may lose the right to claim your money back
Written by Nigel Miller, Contributor
There is good news, and there are lessons to be learned, for both suppliers and purchasers of software in the recent High Court case of Sam Business Systems Limited ("Sam") v. Hedley and Company ("Hedley"). The facts
This case concerned the supply of a software product known as InterSet by Sam to Hedley, a small stock-broking business in Lancashire. Hedley had been using an old DOS system to administer its client accounts and other back office systems. Late in the day, Hedley realised that the system was unlikely to be year-2000 compliant. It decided to replace the system with InterSet. Sam claimed that InterSet could provide all the functionality of Hedley's old system together with some additional features and improved reporting. Despite the tight timescale, Sam was confident that implementation of InterSet could be completed in time for a go-live date in December 1999. In the event, implementation of InterSet was never completed. From the go-live date there were continuous problems. Eventually, in May 2001, Hedley changed to an alternative system. The failures in InterSet had a serious effect on Hedley's business. Not only did clients lose confidence in Hedley's service, but problems with the generation of reports (required for FSA compliance) resulted in the business being investigated by the regulator. The claim
In June 2001 Sam issued proceedings against Hedley for outstanding payments in respect of the initial implementation and for time spent by Sam in attempting to resolve the problems with InterSet. Sam claimed the sum of £310,509.84. Hedley counterclaimed for the sum of £789,658.44 in respect of damages suffered as a result of the failure of InterSet. The Court ordered Hedley to pay to Sam less than £10,000. Although the case cannot really be seen to be a victory for either party, it raises some important practical points for both suppliers and purchasers of software. Unfair Contract Terms Act
First, there was a question as to the enforceability of the limitations of liability clauses in the licence agreement under which the software was supplied. Sam's terms of business contained what was in effect a blanket exclusion of all liability. The only remedy available to the customer was an entitlement to claim back the purchase price if the customer rejected the software through the mechanism of an acceptance testing procedure. The court held that the exclusion clause was reasonable. In arriving at this conclusion, the judge considered the Unfair Contract Terms Act. He found that the parties were of equal bargaining power in terms of size and resources and that Hedley had not tried to negotiate a more favourable liability clause. In particular, Sam's terms contained an adequate remedy for the customer (the money-back guarantee); the judge commented that had this not been the case, the exclusion-of-liability clause would have been unenforceable. The right of rejection
To reject software effectively, a purchaser has to give unequivocal and timely notice of rejection at a time when it has gained no substantial benefit from the software. In this case Hedley continued to use InterSet, despite its shortcomings, for 17 months. At no time before commencement of the proceedings by Sam did Hedley give a clear indication that it had rejected the software. Moreover, Hedley did not follow the contractual arrangements for getting its money back. Accordingly, Hedley lost the right to take advantage of the money-back guarantee. As the limitation-of-liability clause was reasonable, Hedley was unable to reclaim much of the loss suffered as a result of the failures in InterSet. The evidence showed that Hedley went to great lengths to try and resolve the problems with InterSet. Ultimately, this did them no favours. The lesson for software purchasers is that they should not delay in rejecting software which does not function as it should. Purchasers should also ensure that the contract for the supply of software allows a reasonable trial period during which time software can be rejected and that they follow the contractual procedure. Bugs and defects
Complex software is unlikely to be completely free of error. InterSet was sold as a ready-made package, although there was some bespoke implementation work. The Court found that the more standard a software product is, the less tolerant the customer is entitled to be in relation to defects in it. On the evidence, InterSet contained defects from the outset. Many of these were never resolved. As is usual, the parties had also entered into an ongoing maintenance agreement in respect of the software. Under this agreement Sam was entitled to charge for resolving problems with the software. Sam claimed that work carried out for Hedley since the go-live date fell under the maintenance agreement and, accordingly, Hedley was obliged to pay for these services. The Court rejected this argument. Where work is carried out to fix defects in software which were present at the outset (as opposed to bugs which may appear in the course of normal use), the buyer should not be obliged to pay for the work. This is the case even where the contract had effectively excluded liability to pay damages for those defects. To find otherwise would entitle a supplier to charge for remedying his own breaches of contract. Nigel Miller is a Commerce and Technology partner at City law firm Fox Williams. He is also joint-chair of the Society for Computers & Law.
© Fox Williams 2003
Editorial standards