Buying software: the devil is in the detail
Wednesday 8th April 2009
Most businesses utilise some form of software on a daily basis. Where software is utilised it is often integral to operations and when it does not work, the consequences can be catastrophic.
Software suppliers are accomplished at marketing their products, claiming amongst other benefits, revolutionary technologies, streamlined operations and cost savings. Unfortunately businesses often find that on delivery the software fails to meet these claims and, worse still, that contractual remedies against the software supplier for such failure are limited.
This is because contracts governing the sale of software are inevitably biased in favour of the software supplier. They typically lack a detailed description of what is to be provided, offer limited remedies should the software fail to meet specification and unfairly limit the software supplier’s liability.
However, the software industry is heavily target driven and as a result sales staff may be willing to sacrifice the bias of their software contracts for a sale. With negotiation, bias can be replaced with balance and the resulting software contract can provide a business with all the legal protection that it might reasonably expect when contracting with a reputable supplier.
Below are set out some key considerations to bear in mind when negotiating software contracts. This is not intended to be an exhaustive list but rather to set out the most common limitations of supplier contracts from a buyer’s perspective.
Does the specification/ description of the software meet with your expectations?
Businesses should get what they are paying for. As noted above, it is rare for a software contract to incorporate a detailed – if any – description or specification of what is to be provided, while conversely it is routine for cost and payment details to be clearly and unambiguously set out.
Businesses should not accept this imbalance. If a supplier has advised a business that a piece of software can perform a particular function, the function should be incorporated into the description of the software in the software contract. If it is not and it transpires that the software does not in fact perform the function, it will be difficult for the business to seek redress from the supplier for the failure.
In negotiations a common approach is to request that any description of the software provided in, for example, a marketing brochure or specification sheet, is expressly incorporated into the software contract.
Installation services, training and maintenance?
Most businesses do not possess the expertise to install, maintain and utilise software without the supplier’s assistance in providing installation, maintenance and training services. If installation/ maintenance/ training is required, the supplier’s obligations in this respect should be incorporated into the software contract or an appendix to it.
The business should not rely on an informal understanding that installation/ training/ maintenance will be provided as if the supplier fails to honour this understanding, the business could face the prospect of unusable software. With specific regards to maintenance, costs should be fixed or subject to indexation, to prevent the supplier from exploiting the business’ reliance on its maintenance services.
Is a suitable acceptance testing procedure incorporated into the software contract?
Where bespoke software is being purchased, the software contract should provide a suitable acceptance testing procedure to ensure that the software meets agreed performance criteria. It should be a condition of payment that a proportion of the fee paid for the software is retained until successful completion of these tests.
Depending on the relative bargaining position of the parties, it may be possible to impose strict consequences on the supplier if the software fails to pass the acceptance tests. These could include liquidated damages or the right for the business to reject the software and require the supplier to repay any amounts paid for it.
Are you protected if a third party makes an intellectual property rights infringement claim against you?
Software is protected by intellectual property rights. Any user of software must therefore have a licence to use it, either from the owner of the software or from a party entitled to grant sub-licences to use it. A business using a piece of software which it had obtained from a party not entitled to licence the software could therefore be exposed to a claim that its use of the software infringes a third party’s intellectual property rights. This could hinder or prevent a business’s continued use of the software or worse.
It would be impracticable for a business to satisfy itself as to the software supplier’s right to licence the software: the business should instead ensure that it has protection from a supplier in the form of an indemnity or undertaking requiring the supplier to meet the specific potential legal liability of the business in the event that a third party claims intellectual property rights infringement.
In negotiations most suppliers will agree to this although the extent of the protection is often a contentious issue as the supplier seeks to limit its potential liability as far as possible. A common approach is for the supplier to try and cap the indemnity, but this should be resisted if possible, as it is difficult to assess the potential loss and costs that may result from an infringement claim.
Has the supplier provided suitable warranties?
A warranty is a contractual assurance or promise, the breach of which may give right to a legal action for resulting damages. As a minimum a supplier should provide the following warranties:
- that it has the right to licence the software to the business (see above);
- that the software meets with its specification or description provided to the business by the supplier (also see above);
- that the software will be free from defects for a suitable period of (up to 12 months) from the date of installation; and
- that the software and the media on which the software is delivered are free from viruses and other malicious code.
Depending on the circumstances, a business should also consider requiring warranties as to compatibility (for example, will the software function with the business’ existing and planned hardware and other software?), and capacity and performance (for example, will the software be able to cope with predicted quantities of data without degradation in performance?). If the supplier is carrying out installation, additional warranties will be appropriate (for example, as to the use of care and skill).
Limitations of Liability
Invariably a supplier will seek to limit liability under a software contract. Suppliers invariably argue that this is not unreasonable where the material value of software to a business far exceeds the fees charged for the software by the supplier. The case of Pegler Ltd v Wang illustrates that suppliers have a point as in this case the software supplier’s unlimited liability resulted in its liquidation. A common compromise is to set the level of liability at the price paid or payable by the business to the supplier for the software, but the level of liability should always be considered on a case by case basis with consideration of the risk of software failure to the fore.
Does the software contract provide that the source code of the software will be placed in escrow?
An escrow agreement is a tri-partite agreement under which a supplier deposits the source code of the software with a third party escrow agent who undertakes to the supplier and the customer that he will deliver a copy of the source code to the customer in certain events normally limited to the supplier’s insolvency and/or its refusal or inability to provide maintenance (Source code is usually required to perform maintenance on software).
Suppliers are rarely keen to enter in escrow arrangements but in the current economic climate, many have adopted a more understanding approach.
As noted this article is not intended to be an exhaustive summary of all potential issues, but to summarise the most common issues from a buyer’s perspective. Software acquisitions require case by case consideration and legal advice is recommended.
(UK) Ltd  BLR 218