7-Jan-1998
It is difficult to pick up a magazine or newspaper or turn on a television without reading about all of the computer and software-related difficulties which are predicted to arrive with the Year 2000. Media attention may be overblown. You may be tempted to dismiss the entire matter as an alarmist fad. Unfortunately, the Year 2000 (or “Y2K”) issue is very real. You face difficult questions in determining how best to deal with this problem. There may be a variety of strategies to deal with Y2K issues, and time is very short.
What’s the problem?
Some software won’t react properly to the change from the year 1999 to the year 2000. The problem is caused by programming practices that began several decades ago. Programmers used only two digits to represent the year, without reference to the '19'. When the year 2000 arrives on January 1, 2000, some software won't be able to function correctly, or perhaps at all. Some software and systems won't recognize that the year 2000 is a leap year. Similar problems may occur in some systems on January 1, 1999. Some programmers used 1999 as a means to identify test data not intended for processing or as an expiration date for archived data.
In many cases, Y2K problems won't be delayed until January 1, 2000. Year 2000 dates already appear, or soon will, in a variety of contexts, such as credit card expiry dates and financial forecasts.
To make matters worse, the problem isn't just restricted to the software used to perform specific applications. It may also be embedded in chips used in computer systems and a variety of other equipment which is sensitive to, or keeps track of, dates. These chips are located in a wide variety of types of commercial, medical, security or transportation equipment. The problem is made more complex in such situations because there may be no simple means of determining whether a particular item contains a date sensitive chip. There also may be no easy way to determine if the chip suffers from a Y2K problem or how to deal with these problems once they are identified.
Apparently identical pieces of equipment with date-sensitive chips may have different versions of the chip. Some may be Y2K compliant; others may not. It may not be possible to tell without testing each unit, if that is possible at all. Complex systems may deal with dates in a large variety of ways, making it difficult, if not impossible, to test for, or even predict, whether such a system is Y2K compliant.
Several other factors make the situation more challenging. The Y2K problem is compounded because many computer systems are interdependent with data interchanged among a number (perhaps a very large number) of units. Even if nearly all of the units do not suffer from any Y2K problems, difficulty in a single or a few elements of a network could prevent every unit from functioning properly, or result in the propagation of corrupt data.
Another significant concern is the limited time and resources available to deal with the problem - qualified programmers, technicians and the like are in increasingly short supply.
Finally, your particular exposure isn't limited to a partial or total failure of your organization’s internal systems. The impact of the Y2K problem on businesses and service providers on which your organization is reliant may also affect your ability to carry on business normally.
What’s the solution?
There is no simple solution. Your particular exposure to the problem is dependent on the nature of your business and the degree of your exposure to computer systems and hardware with embedded chips. No one should expect a magic general solution to this problem. You need to assess the nature of your individual exposure. Once you understand the exposure, you need to develop a plan and a timetable to manage this risk. This may require you to obtain updated versions of existing software or even to replace software or equipment.
Isn't this a technical and not a legal issue?
Lawyers can't fix your software or embedded systems, but there are a number of legal issues which should be considered. Liability issues will arise in a very wide variety of circumstances. Some of these are discussed briefly in this update.
How should I contact vendors and suppliers about Y2K compliance?
Your Y2K due diligence would normally include requesting your vendors and suppliers to confirm that they and their products are Y2K compliant. Inquiries should generally be made in writing. A clear definition of Y2K compliance should be provided. It is important that the definition be carefully drafted to ensure that it addresses all material compliance issues for your organization. It is important that the inquiry identify as specifically as possible the software or equipment about which the inquiry is being made. You should also consider requesting information concerning the details of the Y2K compliance program of these vendors and suppliers. In order to avoid oversights, you should set up a diary system to follow up if a timely response to your inquiries is not received.
While it is worthwhile to make direct inquiries to vendors and suppliers, they may be unwilling to give unequivocal responses. Therefore, prudence will normally require you to carry out appropriate testing to confirm the scope of the potential problem in your organization. Reliance on the responses you receive is a matter of business judgment in the circumstances. Some organizations have elected to replace critical systems rather than take the risk that a “fix” provided by a vendor will actually fix all aspects of the Y2K problem.
I've received letters asking if my organization is Y2K compliant. How do I respond?
This is the mirror image of the preceding question. The inquirer is seeking a blanket assurance that everything is okay. This is the answer which is the most difficult and risky to give. The failure to provide the inquirer with any assurance may obviously affect ongoing business with that party. The usual response is to provide general information as to your organization's program and its current status. However, you should recognize that you may be liable to persons who suffer damage as a result of any inaccurate statement you make without exercising due care.
My organization supplies products or services which may not be Y2K compliant. What do we do?
The situation is more complex if your organization has already supplied products or services which raise Y2K issues - for example, if you supply software or software related services or supply or manufacture computers or equipment containing embedded chips. Here there are several possible serious issues:
- Is your organization under a duty to test its products for Y2K compliance, so as to provide a clear answer when current or former customers or users inquire as to compliance?
- Is your organization under a duty to warn current or former customers or users if you know or suspect that the products are not Y2K compliant?
- Is there a duty to provide fixes or repairs to noncompliant hardware or software?
- If so, does this apply only to current or recent versions, or also to products which may have been supplied years ago and may no longer be actively supported? (This may be a real problem if the programmers or others involved in producing the items are no longer available.)
- If you provide fixes or replacements, are you entitled to charge for them? If clients are paying for service contracts, is Y2K compliance part of what is contracted for?
Once again, there are no universal answers. Much will depend on the particular facts, and the relevant documents (if any), such as license agreements, hardware supply agreements and service contracts. Litigation is already underway in the United States on issues such as these, and it is anticipated that there will be a tidal wave of claims. Certainly any information your organization provides must be clear and correct. If, for example, it is decided to make an unequivocal warranty that products are Y2K compliant, or a definitive statement that products comply, and if the statements prove incorrect, liability is likely to result.
Who pays if my hardware or software needs repair or replacement?
Some vendors and suppliers may be prepared to provide 'fixes' for Y2K noncompliant software or components, especially in circumstances in which you have contracted for maintenance or support. However, maintenance or support arrangements will not necessarily include Y2K fixes - often, it will be necessary to review the particular terms of the maintenance or support contract.
A crucial question in circumstances in which fixes are not provided voluntarily or under maintenance or support arrangements, is whether vendors and suppliers are obliged by contract or otherwise to provide them. Ultimately this issue will depend on the terms of your purchase or license arrangements and the wording of any warranties. These types of agreements will be subject to litigation on this issue. It is not yet clear whether courts are prepared to conclude that providers of hardware and software were negligent in not having made better provision for Y2K issues.
Are the costs of the “fix” tax deductible?
The costs of dealing with the Y2K problem fall into two broad categories. The first category deals with expenditures designed to simply fix an existing application by either replacing affected chips or modifying the software. In this situation no new functionality is created. These expenditures are tax deductible as current expenses. The second category deals with situation where it is not practical to fix the problem. In these circumstances new software or hardware or both is usually purchased. Generally, such expenditures would not be fully deductible in the year in which they were made. However on June 11, 1998, the federal government announced new rules which are designed to permit small and medium sized businesses to make an election to deduct the full amount of these expenditures in the year in which they were made. To qualify, the expenditure must be made between January 1, 1998 and June 30, 1999. This special tax benefit is directed at smaller businesses. The maximum accelerated write-off is $50,000. Amounts in excess of this figure are subject to the normal rules applying to capital expenditures generally.
Can I fix the hardware or software myself?
If you own the hardware and have the expertise, it may be possible for you to fix the problem. The main issue is whether by attempting to fix the problem, you will void any warranties. Some warranties and maintenance and support arrangements cease to operate if fixes are attempted by unauthorized personnel. In order to avoid the possible loss of a warranty, you will need to review the documentation in question.
Your use of software results from licensing rather than an outright purchase. Most licenses do not permit the licensee access to the code required to make repairs and prohibit the licensee from altering the software. Once again, the documentation will need to be reviewed prior to attempting to implement a fix.
Are there other issues I should be concerned about?
Skilled personnel able to deal with Y2K issues are in short supply. The shortage will grow worse as the year 2000 approaches. If you have such people on staff, you may wish to consider reviewing their employment arrangements to ensure their remuneration is consistent with market conditions. It may be difficult to replace qualified staff if they leave for higher paying jobs elsewhere. In some circumstances, you may wish to consider what, if any, non-competition arrangements are in place.
Am I exposed to personal liability on Y2K issues?
This question is most likely to be of concern to corporate directors and senior managers, particularly those of public or large companies. Given the importance and complexity of Y2K issues and the potentially disastrous effects if the problems are not dealt with, such persons are probably under a duty to ensure that appropriate plans are in place in their organizations to deal with the problem. It is quite likely that failure to do so might be considered negligence. This issue has already been recognized by at least some public stock exchanges.
What about my insurance?
Most policies do not explicitly cover the Y2K problem. It has yet to been seen whether the effects of the Y2K problem would be covered under the general wording of insurance policies. Insurance companies will likely be reluctant to recognize claims for Y2K losses given the size of the potential exposure.
