Defective Software: Potential Legal Liabilities (Part 1) How do Courts View Software Errors?

Within a short period of six months, ‘software glitch’ has been the blame for a number of catastrophic breakdown of services suffered by the MTR Corporation, with the most recent incident resulting in a train collision that had left the red-line in Central inoperable.

Introduction

Software: “What am I?”

A software is a recognised form of literary work subject to copyright protection. Although there is no specific requirement for registration, the tech industry is advised to be acquainted with the WIPO Performances and Phonograms Treaty of 1996.

Whilst various parties have attempted to frame software as a ‘device’ in order to trigger patent registration (ie Re Patent Application 9204959.2 in the name of Fujitsu Limited), software is not deemed as ‘invention’ for the purposes of patent protection.

Birth of a Software

At the foundation of each software is its source code. In this modern day and age, however, it is quite rare for any software to be created from scratch. Rather, software available on the market is usually comprised of a patchwork of previously tested and trusted software routines.

The creation of a new software will usually undergo the following development lifecycle:

• Alpha Testing: prototype creation (usually require much debugging before meaningful use)

• Beta Testing: controlled pool of users (to spot for bugs and get a preview of the product)

• “Gold” or Final Release: General release for open public – but usually still contain bugs

• Post Launch Patch: Continue throughout its lifecycle with various updates and improvement

Software Errors: How do Courts View them?

The classical view of the Courts regarding software can be observed from the landmark authority of Saphena Computing v Allied Collection Agencies Ltd [1995] FSR 616 which supports the view that:

“… a computer program or software which contains bugs or errors will not necessarily be regarded as defective, or unfit for its purpose, but it is made clear that this is on the basis that the supplier is obliged to rectify such bugs and errors ...

If bugs or errors are identified and cannot be remedied, it may be necessary to go on to consider whether their effect is such as to render the software or program in breach of these implied conditions.”

Staughton LJ further observed:

“it is important to remember that software is not necessarily a commodity which is handed over or delivered once and for all at one time. It may well have to be tested and modified as necessary. It would not be a breach of contract at all to deliver software in the first instance with a defect in it.”

Given such stance of the Courts, much of a vendor’s liability will be determined by the type of software that was delivered in question together with promises made (outlined in delivery schedule and the level of maturity reached).

For instance, a different level of perfection will be expected and required for release of video games (ie beta stage vs general release). This is illustrated in Virgin Interactive Entertainment (Europe) Limited v Bluewall Limited [1995] 1 WLUK 516 where whilst the contract provided that a beta version will be delivered by a certain date, only an alpha version was available. Definition of stages was defined:

1. “Alpha” version; all the programme’s component parts are in a form in which they can be integrated together, but programme is not complete. Capable of being treated as a whole, rather than in separate parts or modules

2. “Beta” version; developer considers a programme to be complete in every way; but will be subject to final testing by the purchaser before releasing to the market

Further illustrated in St. Albans City v ICL [1996] EWCA Civ 1296, the specific contractual stipulations will disallow Spahena-type arguments.

Conclusion

In short, the Courts will often subject a software to different standards depending on the stage of maturity such software are in (together with relevant contract terms (if any)).

Vendors may therefore seek to avoid liabilities by dealing with potential software bugs with the following arrangements:

1. Always have a formal contract and understand the conditions under which parties are operating (this will avoid the need for parties to argue over expected stage & conditions – limiting the scope of any potential dispute);

2. Provide warranty (with specific terms to address various conditions) – parties will be able to resolve the matter amicably and avoid jumping the gun at litigation; and

3. Support and maintenance (for which vendors will usually charge an annual subscription fee) – not only is this an opportunity for more profits, but it gives the vendor the chance to fix a problem after discovery.

 

Jurisdictions: 

Solicitor, Hong Kong

Barrister, Hong Kong