Most contracts for bespoke software will, and should, be drawn up with reference to a specification setting out the fundamental features to be included.Â This will afford both parties a strong degree of certainty as to what is expected and will go a long way towards avoiding disputes arising in the future.Â Software contracts will contain warranties to ensure that obligations are met but, if breached, will only allow for damages to be claimed in respect of the breach and will not allow for termination of the contract.Â A software developer will want to include limitations on warranties because virtually no software is entirely free of bugs.
The developer may wish to limit its liability in relation to how compliant the software will be with the specification.Â A purchaser of bespoke software is likely to put the software through rigorous acceptance testing, so as to simulate the environment in which the software will be deployed and the typical extremes under which it will be expected to perform.Â This will help to identify bugs that can then be raised with the developer.Â These warranties are not readily available to the same extent where the software is an off-the-shelf solution and a purchaser will need to adjust its needs accordingly to fit around the software.
Another type of warranty common to software contracts relates to how long software will comply with the specification.Â Many bugs will only be discovered after extensive use, often long beyond the acceptance testing phase.Â A compliance period can be drafted to last for 12 months, although a developer will want this to be as short as possible and it is often no longer than three months.Â Most businesses will, however stipulate that this period of time will not begin to run until after the satisfactory completion of acceptance testing.
The breach of a warranty will usually give rise to damages if the bugs make the software unsatisfactory with reference to the specification.Â An interesting set of circumstances would be where the bugs make the software entirely unusable.Â In this case, the relevant warranties, despite the fact that they may be expressly referred to as such, would actually be innominate terms and could be interpreted as conditions of the contract.Â This would give rise to the possibility of termination of the contract, although in practice, it will depend on the number and effect of the bugs.Â A well drafted contract will anticipate foreseeable problems and include remedies.
One method to overcome reliance on warranties in the software contract would be for a separate maintenance agreement to be entered into, particularly where the software is largely usable and compliant with the specification.Â This would limit the need to negotiate warranties and would allow for the maintenance agreement to be relied on in the first instance, particularly where termination of the contract is in neither party’s best interests.Â Many purchasers, having invested heavily in bespoke software, will be keen to enter into a maintenance agreement and it will often be easier for it to rely on this rather than going back and interpreting the contract with reference to the specification.