Computers are not intelligent things. They do what they are told, however ludicrous the result. Computers that handle dates using two digits will be unable to correctly deal with the change from 99 (1999) to 00 (2000). The computer will consider that 00 represents 1900 and will act accordingly, producing unreliable results.
Defining the problem may be easy but for businesses, finding the problem and fixing it in the time remaining is another matter. Although it is primarily a mainframe problem, it may also affect the basic input output system (Bios) of PCs and PC software. The problem may also arise in embedded chips in manufactured items that deal with dates, such as weapon systems and video recorders. For example, a particular model of Mitsubishi VCR is OK until 2003; beyond that, the clock reverts back to 1990.
Technical and legal audit
By now most companies are aware of the problem. There is an accepted method of carrying out a compliance project. The first step is to undertake an inventory of all hardware and software and using a flow chart to show the data paths used by the company to produce its data. This should show which areas are affected by date handling.
Once you have identified these areas the system has to be fixed to ensure that the correct dates are called. The system will then have to be tested and bugs corrected before the system can go live. This may involve a complex relationship between various pieces of hardware and software from a number of different sources.
This process will involve large amounts of time and money. The question is: to what extent can a company pass the financial burden onto others involved? This may involve software and hardware vendors, maintenance companies, consultants, outsourcing suppliers and possibly insurance companies.
To identify the relevant parties it is necessary that at the time of starting the technical audit a legal audit takes place. This should identify the contracts and licences relating to the software and hardware examined during the technical audit. This will include the contracts covering the relationships with the parties mentioned above.
Who is liable?
The vendor: the inability of the system to handle the change to the year 2000 may be categorised as a bug, a defect, an error or perhaps a built-in obsolescence.
The consequence of the categorisation, which may have to be left to a court to decide, will affect the question of liability. The concept of defect is one a court is likely to adopt.
The primary liability is, not surprisingly, going to rest with the software and hardware vendors of the non-compliant systems. Any action arising out of breach of contract will be subject to the six-year limitation period which commences probably with the supply of the non-compliant system. So if you are looking at contracts that were entered into prior to 1991, then any claims in contract are likely to be time-barred.
The user may be forced to try to bring an action in negligence asserting failure of reasonable skill and care. The courts are reluctant to allow claims of pure economic loss, but may consider claims for the amount necessary to make the system compliant.
A claim brought in contract would assert that the system, being goods, is subject to the implied terms under the Sale Of Goods Act 1979 of fitness for purpose and satisfactory quality. Depending on the status of the user, such terms may either not be excluded at all or, if they are excluded, then this may be subject to the test of reasonableness. This assumes that the software is categorised as goods rather than services.
The distinction between goods and services even post-ICL v St Albans is still not all that clear. If it is bespoke software then as a service it need only be supplied with reasonable skill and care. It may be argued that compliance is such a fundamental requirement that the supplier will be liable in any event.
If the vendor tries to argue that the software was not intended to operate beyond the millennium change then factors such as the duration of the licence or any warranties with regard to operation of the software would be looked into. A licence that expires beyond 2000 would be a very strong argument against the vendor.
The vendor may offer an upgrade to a compliant version, but at a price. Depending on the terms of the contract, you may have no choice but to accept this.
Care should be taken in bringing in third parties to provide a fix. The terms of the licence may preclude this without the permission of the copyright owner. Sections 50A to C of the Copyright, Designs and Patents Act 1988 give limited rights to users to decompile and 'error correct' software.
Liability under maintenance contracts
If there is a maintenance contract in place which places the obligation on the maintainer to ensure that the software should continue to function then it may be responsible for ensuring compliance, but again it will depend on the terms of the contract.
Outsourcing facilities management contracts
Similarly, if the user has entered into a facilities management (FM) agreement or has outsourced a particular area of the business then the burden of ensuring compliance, subject to the terms of the contract, may be shifted to the service supplier. If the FM supplier or outsourcer is entitled to terminate the contract to avoid this outcome, this may well be a route they take to avoid liability. We call this '1999 and out'.
Anybody buying software and hardware now should insist that a specific warranty of 2000 compliance is inserted into the contract or licence. Any force majeure clause should specifically exclude non-compliance.
Contracts with solution providers
To avoid leaping from the frying pan into the fire, any contracts entered into with companies or individuals engaged to make systems compliant should be carefully drafted, setting out clearly what service is being provided and the consequences of failing to do so.
It is unlikely that business interruption insurance will cover something that is not going to be an accident, but is foreseeable now. In any event, dialogue with the insurance company may clarify this point. There may also be a duty to notify the insurer if you become aware that you have a problem.
If the Gartner group is right that the fix will cost between $3bn and $6bn, worldwide, then it is safe to assume that users will seek to share this burden. It is better to try to do this by negotiation rather than litigation.