What is a Warranty?
Readers will all remember from law school and, if they are unlucky, more recent work that contract terms can be classed as: (i) ‘conditions’ that go to the heart of the contract; (ii) ‘warranties’ that while part of the contract do not go to its heart; and (iii) ‘innominate terms’ – terms that may be warranties or conditions depending upon the effect of the breach (see Hong Kong Fir Shipping Co Ltd v Kawasaki Kisen Kaisha Ltd [1962] 2 QB 26). A warranty is often an assurance that a statement about a factual matter is correct. (A discussion of the innominate term concept and the various legal commentaries on Hong Kong Fir are beyond the scope of this article. For these purposes, we have assumed that when drafting warranties, lawyers should be aware that they may amount to conditions in certain circumstances.)
The key difference between a warranty and a condition is that a breach of condition may entitle the innocent party to terminate whereas a breach of warranty typically gives rise only to damages (damages for breach are intended to put the innocent party in the position it would have been in had the warranty been true). The interesting thing is that whilst IT lawyers spend a lot of time worrying about the ‘warranties’ their clients are (or are not) giving or being given, whether a term of a contract is expressed as a warranty or not may not strictly speaking matter. If, even though the term is expressed as a ‘warranty’, it actually goes to the heart of the contract, it will be a ‘condition’. Though of course, the fact the parties stated that a term was ‘only’ a warranty will be of evidential value.
It is for this reason that often ‘warranties’ will also be called ‘representations and undertakings’ to maximise the innocent party’s range of remedies. Again though, there is always a risk that the court might disregard the preamble to a clause that purports to be a ‘warranty, representation and undertaking’ and instead reach its own conclusion as to whether a term is more than a mere warranty and is also a representation (and therefore rescission is a potential remedy) and/or an undertaking (and therefore somehow more like a condition). Finally it is worth noting that contracts often include express rights to terminate for material breaches of obligation which could include material breaches of warranties.
Warranty Fixation
If warranties are the ‘less important’ terms, why are IT contracts so fixated on them?
The simple answer is that they are not less important. Whilst called warranties, the ‘warranties clause’ typically sets out some of the key contractual obligations beyond those set out in the SLA, service description or charges sections. The reason they are set out as warranties derives from the fact that IT contracting started life in the US where the term ‘warranty’ is taken to mean a clause that goes to the heart of the contract – or what English lawyers take to be a ‘condition’. The fact that the English courts will look at the substantive importance of the clause not just its title means, despite the fact that at first sight the only remedy for breach of warranty ought to be damages, everyone knows that they require the level of attention they would get in the US or as if they were headed ‘Conditions’ rather than ‘Warranties’.
Another reason warranty clauses are so important is that as well as containing promises they also, as we will see below, often contain disclaimers or limitations of liabilities that might arise should those promises be broken.
Software Performance: Warranty vs Maintenance?
Most software licences or development agreements contain some form of warranty as to software performance, usually linked to the software’s specification. For this reason and also because most technologists appreciate that software is inherently ‘buggy’ and therefore prone to go wrong, it is also common to see limitations on these warranties. (Implied warranties as to ‘fitness for purpose’ and attempts to limit them are discussed below.) The limitations on software performance warranties are many and varied but typically come in two parts.
First, there are limitations on how compliant the software will be with its specification. Typical caveats might include a warranty to ‘comply in all material respects’ with its specification or to ‘perform substantially in accordance’ with that specification. Lawyers can debate these points long and hard. However, with bespoke software where various rounds of acceptance testing are anticipated, customers often expect that, on delivery at least, software will perform in full compliance with its specification. Conversely with COTS (commercially available off the shelf) code, vendors are in a stronger position to argue for caveats.
The second classic limitation goes to how long the software will comply (or substantially comply etc) with its specification/purpose. Particularly with COTS code but also with developed code, vendors and users expect bugs to arise and so they agree time-limits or ‘warranty periods’ on the software performance warranties. Again, long debates can ensue about the length of these warranty periods (they range from 30 days to a year but 90 days still seems to be typical) and as to when they start (from delivery or from acceptance?).
Having decided how compliant the software will be and for how long; the next question is what happens if the warranty is breached? Here, the ‘warranty’ seems to be more like an innominate term as, if the software fails to work altogether, that would seem to be a complete failure of consideration entitling the user to terminate. On the other hand, a few bugs might only give rise to damages, if that.
Typically however, software performance warranties spell out the user’s remedies – or fairly often, its lack of remedies. These pre-set remedies range from a right to return the software and be refunded the purchase price (or a proportion of the price if you have had some use of the software) to a right to have patches or work-arounds applied.
What is interesting is how often negotiators get involved in discussions on the nature of the software performance warranty in deals where the user is also purchasing maintenance. Where the user is paying for maintenance it is arguably paying the vendor to maintain a version of the performance warranty on an ongoing basis. Some vendors offer or users seek to obtain ‘free’ warranty cover for the warranty period but typically users pay for support from acceptance whilst also having a performance warranty (albeit that the warranty may be a less reliable remedy than a help desk backed by SLAs) to rely on.
Where software is supplied backed by a support and maintenance agreement, the user’s primary remedy for defective performance is likely to be under the maintenance agreement.
Service and Staff Performance
It is fairly typical in services contracts to see warranties that the services will be performed well or at least to a reasonable standard. The standard of performance varies but might require performance in accordance with some kind of defined yet seemingly objective standard such as ‘good [or sometimes best] industry practice’. Other clauses require the services to be performed in ‘a diligent and timely manner’. The aim of these clauses is to give the customer an opportunity to sue for breach, even if the narrow requirements of a service description or SLA have been met. Suppliers seek to avoid giving them but it can be hard to argue that, as an expert provider of services, you will not perform those services reasonably well. Where suppliers do accept such warranties, they sometimes look to limit their exposure to breaches – often to an obligation to re-perform or refund.
A similar warranty relates to the quality of the supplier’s staff. For example, it is common to see a warranty that the supplier will use a ‘sufficient number of suitably qualified staff’. Again, the aim is to give the customer additional ways to claim damages if service is poor and, as with service warranties, it can be hard to avoid giving them.
Contractual Obligations Called Out as Warranties
As discussed above, the warranty clause is commonly used to identify key supplier performance obligations. Beyond those relating simply to software or services, performance obligations called out as warranties might include: security obligations, data protection obligations, fraud and corruption obligations and even corporate social responsibility obligations.
Suppliers seem to fall into two camps on this. Those who take the view that the warranties simply restate their contractual obligations and so they might as well accept them and those who take the view that ratcheting up contractual obligations into warranties changes the balance of risk unfairly. This latter position is particularly common where the ‘warrants, represents and undertakes’ formulation is used. Usually compromises on these points can be reached.
Other Common Warranties
Aside from IP warranties that are beyond the scope of this article, the performance warranties described above are the key warranties in IT contracts. But this article would not be complete without considering a range of other common warranties.
Warranty as to Title – this warranty goes to the wider IPR discussion and will be covered in a separate article but see below on statutory warranties.
Warranty as to Capacity – this warranty is usually agreed without negotiation and makes clear that the parties have the legal capacity to enter the agreement. Sometimes the wording of these clauses is adjusted to try and bring in an implied warranty as to title in the materials to be provided by the supplier. For this reason, despite their seemingly ‘boiler plate’ nature, care should be taken when reviewing capacity clauses.
Warranty as to Regulatory Compliance – this warranty is sometimes framed as a follow up to the warranty as to capacity, ie the parties will ensure their entry into and performance under the agreement is in compliance with relevant regulations. However, it is often also linked to the performance warranties discussed above, ie the software or services concerned will comply with and will continue to comply with applicable regulations. This latter version of the regulatory compliance warranty can sometimes be even more contentious than the performance warranty. Typically, if the point of the software is to ensure regulatory compliance, the parties will agree a compromise linked to the payment of maintenance fees to keep the software or service up to date. If the software or services are merely tools to enable the customer to run its business, the supplier may argue that it cannot underwrite the customer’s own regulatory compliance and that the warranty should be deleted or amended accordingly.
Warranty as to Licences and Consents (other than IP Licences) – again this warranty is often framed as part of the capacity and/or the regulatory consents warranties discussed above, ie that the parties have the required licences and consents to enter into the agreement and/or provide goods and services under it. Typically this warranty becomes contentious only in the context of the broader discussion around licences and consents linked to IPR (which is beyond the scope of this article).
Warranties as to the Accuracy of Statements Made – this warranty is very wide-ranging and risky for suppliers, particularly given suppliers’ usual preference to exclude pre-contractual representations. It is rare but does arise in the public procurement context. As with warranties as to the abilities of a supplier’s staff, it is hard to argue you should not provide it but, given the nature of the procurement process, it is a risky warranty to provide – particularly if the warranty is also expressed to be a ‘representation and undertaking’. A compromise may be to link it to a materiality threshold.
Warranties as to Viruses and Disabling Code – the starting point for this type of warranty is that the supplier (or both parties) will not deliberately or negligently introduce viruses into the customer’s (or the other party’s) environment. Given the increasing complexity of anti-virus checking and the dangers of denial of service attacks and malicious code these warranties are now commonly framed as warranties to use up-to-date anti-virus checking software. The parties often negotiate on how up-to-date or how ‘best practice’ such software has to be, but it seems to be acknowledged that a complete guarantee that there will be no viruses is unrealistic.
One point to note is how these clauses may impact software vendors who install licence keys. Licence keys are software tools which turn the software off if the restrictions in the licence are breached. For example, in a term software licence, the software may cease to function at the end of the term and only by purchasing an extension are you given a key to unlock the software. Vendors can unwittingly find themselves in breach of a no virus or disabling code warranty if they install such keys in their software. While it is hard to see damages being awarded in such an instance, best practice is to carve out legitimate licence keys from these warranties.
Warranties as to Date and Euro Compliance – these warranties took off in the 1990s as users sought to protect themselves from the prospect of euro-conversion and the now infamous Y2K bug scare. The date compliance warranty has now largely been dropped from most new contracts but it still subsists in old contracts. Similarly the euro-warranty is much less common now. Many users still want to ensure that their software can handle transactions in different currencies but typically this is now built into the service description or specification (which is arguably where it belongs) instead of the warranty clause.
Implied Warranties
Statute in England implies a number of warranties into contracts. Liability for breach of some of these can be disclaimed but liability for certain others cannot.
Implied Warranties as to Title and Quiet Possession – these are implied by the Sale of Goods Act 1979, s 12 or the Supply of Goods and Services Act 1982, s 2, and liability for breach of them cannot be disclaimed (Unfair Contract Terms Act 1977, ss 6(1) and 7(3A)).
Implied Warranties as to Conformity of Goods to Description, Sample, Fitness for Purpose etc – these are implied by the Sale of Goods Act 1979, ss 13, 14 and 15 and the Supply of Goods and Services Act 1982, ss 3 and 4; in business to business transactions liability for breach can only be disclaimed to the extent it is reasonable to do so (Unfair Contract Terms Act 1977, ss 6(3) and 7(3)).
Whether and to what extent these warranties apply to software (ie is software a good) together with a more general discussion of limitations of liability, UCTA and warranties as to title are all beyond the scope of this article. However, as we will see below, caution must be exercised when reviewing exclusions of warranties or liabilities for breach of warranties to ensure that such clauses do not accidentally breach the express prohibition on excluding certain warranties implied by statute.
Limitations on and Disclaimers of Warranties and Remedies
As noted earlier, warranty clauses are often used to exclude or limit liabilities. These take a number of forms but some key examples are described below.
Exclusions of Other Warranties – the classic US software license (sic) usually sets out a complete disclaimer of all warranties whether express or implied (other than those specifically set out in the warranty clause). Typical practice in the US is to put disclaimers in capital letters and it is common to find the capital letters surviving into English law agreements. While choosing not to put such disclaimers into ‘sentence case’ is up to the lawyer concerned, caution must be applied to ensure that such disclaimers do not breach UCTA by disclaiming warranties implied by statute as to title etc (see above). Furthermore, such disclaimers are often so widely cast they could breach other UCTA requirements as to no limitation of liability for death or personal injury arising due to a party’s negligence. Best practice is to link such warranty exclusion clauses to the clause that makes clear liability for death etc is not excluded and to state that other warranties are excluded ‘to the maximum extent permitted by law‘.
Restrictions on Remedies – as discussed in relation to software performance, the warranty clause is sometimes used to restrict the innocent party’s contractual remedies for a breach. Beyond those related to performance discussed above, the other key area such restrictions are used is in relation to IP warranties (which are beyond the scope of this article).
Time Bars – as noted above, it is typical to provide a warranty period. The impact of such a time-limit may be that even catastrophic failures of software (and arguably therefore consideration) can give rise to no cause of action if they take place one day after the expiry of the warranty period.
Specifying Remedies
Finally, in addition to considering any restrictions on remedies, it can be useful to consider what remedies a party might actually want in the event of a breach of a warranty. As discussed at the start of this article, if the warranty really is a warranty, the starting position is that the innocent party’s only remedy would be damages.
This issue does not seem to be considered all that often in practice, but the parties may want to consider if they wish to require more than damages – particularly for breaches that while annoying or problematic do not give rise to costs. For example, the innocent party might want the right to require the guilty party to rectify a breach of warranty within a certain period. If that is what the innocent party wants, it should say so in the contract. Failure to rectify such a breach of warranty might then amount to (or the contract could explicitly deem it to be) a material breach of contract. This in turn could lead to something that started as a breach of warranty ultimately amounting to a termination event.
Toby Crick is a partner in Bristows’ Commercial IT and IP group. He advises on and negotiates commercial, technology and outsourcing agreements.
Helen Rose is an Associate in Bristows’ Commercial IT and IP group. She advises on a wide range of commercial, IT and IP transactions as well as on data and privacy issues.
