Few people in the IT industry would be unaware of the millenium or year 2000 "bug" which is present in a wide variety of software.

Typically, software afflicted by this bug records and processes only the last two characters of the year (ie. 1997 is recorded as 97) and the software may fail or produce incorrect output when a date involving the year 2000 or later is processed. The software may be unable to process date information containing "00" or may treat a date in 2000 as being earlier than a date in the 1990's (ie the software treats "00" as a reference to 1900).

How serious is this bug? It depends on the type of software which fails or produces errors. In theory, it could create global havoc with software malfunctions leading to power and telecommunications failures, disruption of water supplies and traffic jams.

Year 2000 is already causing problems. For example, a major credit card company issues credit cards with a 3 year expiry date (cards issued now expire in 00). The technology embedded in card readers in about 1.3 million outlets will reject cards with a 00 expiry date. How would you feel if your card was rejected late at night or whilst you were travelling overseas?

Most businesses have trimmed their information processing staff to the bone and those staff are fully occupied with the day to day operations of the business. Resources will be a real problem for many businesses attempting to address year 2000 problems and time is also running out. There are only about 150 weeks left until 2000.

In Australia more than $1.5 billion is likely to be spent by business and government to modify or replace defective software.

The Year 2000 malady presents a major opportunity for those involved in the provision of software cures or replacements. However, with the opportunity comes the threat of enormous potential liabilities.

In the United States, it is estimated that for every dollar spent on resolving the technical problem, two dollars will be spent on litigation and other legal costs associated with the Year 2000 problem. If this ratio applies in Australia, it translates to a $3 billion legal problem.

To address the wide variety of legal problems associated with the millenium bug, Bonnins has established a Year 2000 legal response group comprised of computer law specialists with extensive contract negotiation and litigation experience.

The group has identified a wide variety of issues which should be considered by IT practitioners who have had any involvement in the development, enhancement, maintenance, distribution or marketing of software which is not Year 2000 compliant and by those contemplating involvement in the rectification or replacement of such software.

Issues to address include the following:

• How long ago was the organisation or person involved with non-compliant software? The year 2000 problem has been publicised in the IT industry for many years. Involvement after the IT practitioner knew or ought to have known of the problem could create a liability based on negligence. On one view of the law, a competent programmer should always have known of the inherent deficiency in using a two character year field, so the critical test of negligence will be the time at which a reasonable programmer ought to have anticipated that the software might still be in use in 2000 AD.

• For licensors and distributors of non-compliant software, the contractual terms and any sales representations should be reviewed. If the contract excludes liability for bugs but includes an obligation to rectify bugs or provide a workaround, the licensor/distributor could be liable for all costs in curing the millenium bug or providing alternative software which is Year 2000 compliant.

• If it is uncertain whether software suffers from the year 2000 bug, contracts must be reviewed to ascertain which of the parties is liable to pay the costs of investigation and testing the software.

• For the providers of software maintenance services, the maintenance contract should be reviewed to assess whether the obligations expressly or impliedly extend to rectifying date related defects. A question also arises as to whether For contractors offering to remedy software supplied by third parties, the third party licence agreements must be reviewed to ensure that confidentiality and other obligations will not be contravened by the customer if the contractor is given access to the software code. The contractor must also ensure that the process of review and modification of source code does not involve any inadvertant copyright infringement. Note that copyright may be infringed merely by causing a copy of the code to be loaded into the memory of a computer or to be displayed on a screen.

• Contractors offering to rectify non-compliant software or provide replacement software should ensure that the various causes of delay and the consequences are clearly addressed in the contract. The obligations of the customer to permit access to source code, documentation, hardware, personnel and other resources should be clearly stated. The contractor should be entitled to extend time for performance of obligations where delay is caused by any factor beyond the contractor's control. The contractor's liability for delay should be limited to a stated maximum amount.

• As 2000 approaches, demands for expert programmers will soar and so will salaries. If the right employment contracts are not in place, a contractor may find that its employees are lured to work elsewhere and as a result the contractor may be unable to meet the time deadlines set by customers.

• Contractors should consider their exposure to third parties if the defective software is not correctly rectified and fails. Liability could arise for breach of contract, in negligence or pursuant to legislation. Customers should be advised to implement a disaster recovery strategy and insurance by both the contractor and the customer should be considered.

• Organisations should consider their exposure if key suppliers of goods or services have a major problem as a result of the millenium bug. The year 2000 compliance programs of those suppliers should be monitored and contracts with key suppliers should include appropriate protection.

IT organisations should also remain vigilant with respect to the wide variety of other date related problems which can afflict software. For example, software must be able to cope with leap years. A computer failure on 31 December 1996 caused aluminium smelters in New Zealand and Tasmania (which used the same software) to suffer multi-million dollar losses. The failure occurred because the software was not designed to handle the 366th day which occurs only in a leap year.

IMPORTANT DISCLAIMER -

This article is not intended to be legal or other advice and each reader should obtain separate advice on their specific circumstances.

ABOUT THE AUTHORS

Richard Pryor is managing partner of Bonnins and he established the first computer law specialty practice in South Australia. He completed a graduate diploma in sytems analysis in 1987 and has been a member of the ACS since 1988.

Alex Hannell is a member of Bonnins Technology Law Group. Before working as a lawyer, Alex was employed by a software and communications company in the UK with respect to the design and modification of software.

Back to Main Menu