Year 2000 Internet Resources

The Great Computer Crash of 2000

By Craig A. Fieschko

Editor's Note: To view Wisconsin statutory materials referenced in this article you must have and/or install Adobe Acrobat Reader 3.0 on your computer.

It's Monday, Jan. 3, 2000. You were hoping for a slow day after the holiday weekend, but the telephone keeps ringing:

• A local bank calls to report that its computer system misplaced all of its depositors' accounts, and it's wondering about legal ramifications.
  
  
• A local hotelier wants to sue his building maintenance contractor because his new climate control system malfunctioned, treating his guests to air conditioning in the middle of winter, and they're leaving in droves. He also fears that he may be facing suits from the guests that stayed: They were stuck in their rooms when the computerized key system also went haywire.
  
  
• You just received a policy cancellation from your professional malpractice carrier, who says that their database shows you haven't paid your premiums for almost a century.
  
  
• Several (ex)clients are questioning your competence and diligence owing to your failure to meet important deadlines. You try to explain that your docketing software failed, but they aren't very understanding.

You note that all of these problems appear to originate in computerized systems, but why now, and why all at once?

The year 2000 problem

If you've been watching the news, chances are you've heard of similar scenarios that could arise from the year 2000 problem, also known as the "Millennium Bug," the "Millennium Bomb," and the "Y2K Bug." The problem originates in the date-processing routines of older computer software and hardware.¹ Because computer memory once was very limited and expensive, software and hardware generally stored dates in six-digit form: For example, the date June 8, 1995, might be represented in dd/mm/yy form; that is, as 080695. Thus, the year 2000 problem arises due to the "rolling over" of the year digits on Jan. 1, 2000 (or 010100).

Owing to the lack of millennial and centennial digits, software and hardware that perform actions based on the year digits may treat the year 2000 as the year 1900 and yield erroneous results. For example, a program that sorts dates and their associated actions into ascending order may treat dates in the year 2000 as having higher priority than dates in the 1990s. As another example, a program might calculate that minus 99 years have passed between Dec. 31, 1999 (311299) and Jan. 1, 2000 (010100) by subtracting 99 from zero. Other software and hardware may be incapable of accepting years after 1999, or may fail to recognize the year 2000 as a leap year and skip directly from February 28 to March 1.

There is no realistic chance of a universal solution for the year 2000 problem. There literally are billions of lines of software code wherein year 2000 problems may be hidden, and numerous different programming languages and styles to contend with. Thus, each different program generally will require its own customized repairs. Additionally, year 2000 problems can be difficult to isolate since even if software is year 2000 compliant, the same is not necessarily true of the hardware on which it runs. An example may be sitting on your own desktop, since the internal clocks and memories of many older personal computers use two-digit years.

The year 2000 problem is compounded in that it is not limited to what most people regard to be computers and software, since many modern devices have embedded microchips and digital controllers that also are date-sensitive. For instance, numerous "smart" building maintenance systems (heating/cooling systems, fire and intrusion alarm systems, and so on) rely on correct date usage for proper operation.

Because of society's heavy reliance upon computer technology, it should be evident that the year 2000 problem stands to cause legal troubles as well as technical ones. The first year 2000 cases already have hit the courts. In the California case of Atlaz International Ltd. v. Software Business Technologies Inc., users are suing an accounting software company for selling nonyear 2000-compliant software and requiring payment of upgrade fees to obtain a compliant version.²

In the Michigan case of Produce Palace International v. TEC-America Corp. and All American Cash Register Inc., a retailer suffered heavy losses after its new cash register system refused to accept credit cards with expiration dates after the year 2000, and the retailer is looking to the cash register manufacturer for reparations.³ More cases are certain to come. In view of the risks involved, attorneys must be able to advise their clients how to protect against others' failure to account for the year 2000 problem, and how to minimize clients' exposure to liability.

Determining vulnerability

Your clients should inventory all their software, hardware, and online data services. Clients should ask the vendor/supplier of each product and service to provide a written reply as to whether the product/service is year 2000 compliant. A response that a vendor has some form of "year 2000 certification" from a trade organization does not necessarily mean that the software and hardware in question meets year 2000 needs unless a detailed review of the certification process leads to this conclusion.

Apart from addressing vendors of software, hardware, and data, it also may be appropriate to request compliance information from other parties involved with the design, manufacture, selection, and installation of software and hardware. For example, if a consultant chose or installed software and hardware to your client's specifications and requirements, the consultant may best determine whether the software and hardware are in compliance.

Contract issues

Since the sale and use of software and hardware generally is mired in contracts ­ hardware and software licenses, maintenance and repair agreements, and so on ­ the next step is to inventory and analyze all materials relating to the software/hardware to determine their representations, warranties, and limitations on liability. This analysis will allow you to determine your client's remedies if his or her systems are not year 2000 compliant.

Statements in sales contracts regarding software and hardware or their performance may be treated as an express warranty so long as they were part of the "basis of the bargain."⁴ Since such express warranties also can arise in materials relating to the software and hardware, such as advertising, operation manuals, and other literature, these materials also should be closely reviewed. However, take care to identify any merger/integration or disclaimer clauses excluding statements in these materials from the sales contract. If no express warranties apply, a remedy might be available through the implied warranty of merchantability⁵ and the implied warranty of fitness,⁶ provided these warranties are not disclaimed.⁷

If it appears that your client's software and hardware are not year 2000 compliant but are warranted as such, the vendor should be given written notice of your client's expectations. If your remedy is limited to repair or replacement, as it will be with most sales contracts, repair or replacement should be demanded along with a timetable for doing so. Where repair or replacement is unduly delayed or impossible ­ a very real possibility where the year 2000 problem is involved, owing to the magnitude of the problem and the limited time for correction ­ you may be able to assert that a failure of essential remedy has occurred, thereby potentially allowing your client's recovery of consequential, incidental, or special damages (such as loss of customers) even in cases where contracts limit or exclude them.⁸

Vendor reliance on force majeure clauses or other clauses disclaiming liability for "Acts of God" and the like may be deterred if you provide a clear statement of your position that the vendor made the software and hardware noncompliant, not God, and that compliance could have been achieved with the exercise of due care.

It is possible that a vendor will initiate (or has initiated) contact with your client, stating that its software and hardware are not year 2000 compliant. This statement will trigger your client's obligation to mitigate damages once a contract breach is apparent, and even where vendors have no contractual obligation to fix your client's software and hardware, such notice could lessen their exposure to tort liability. Where vendors do have a contractual obligation to fix your client's systems, pay close attention to the terms of proposed fixes: Will they meet your client's compliance timetable, or is there a failure of essential remedy? Are the vendors attempting to modify their obligations (for example, requesting payment for compliance measures that appear to be required under warranty)?

Regardless of whether a fix is proposed, vendors should be put on written notice of your client's expectations so they cannot later claim your client waived remedies or acquiesced in modifications to contract terms. If your client is bound to a vendor by a long-term contract, the vendor's failure to help your client attain year 2000 compliance may allow your client's escape.

Statutes of limitation problems can arise where noncompliant software and hardware are older than the limitations period.⁹ Breach (and running of the statute) occurs upon delivery of the defective good, unless a warranty explicitly extends to future performance.¹⁰ Thus, where noncompliant software and hardware are older, it is prudent to review all documentation relating to the systems, particularly long-term maintenance and service contracts, to locate any warranties of future performance. Despite any length of time remaining in the limitations period, you should promptly request contractual remedies once breach is noted since delay may give rise to claims of waiver.

More difficult contract issues may arise when contracts do not involve sales of goods, or when they otherwise are outside the scope of Article 2 of the Uniform Commercial Code (UCC) and Chapters 401-407 of the Wisconsin Statutes, which generally are based on UCC Article 2. Many software and hardware contracts are nongoods related (for example, contracts for data processing services), or are in the form of a license rather than a transfer of title. Nevertheless, courts generally have treated software licenses and data transaction arrangements under UCC Article 2 principles, and thus it can be expected that these principles will continue to control in most cases.¹¹ However, commentators have noted that Article 2 sometimes provides a poor fit when software and hardware contracts are involved.¹² Article 2B of the UCC, dealing with software and hardware licenses and data transactions, has been under construction in earnest since approximately 1995, but has not yet been completed. Where application of UCC Article 2 principles provides unwanted results, reference to the draft Article 2B and its surrounding commentary may be a helpful reference in formulating policy arguments for different outcomes.¹³

If your client is a software or hardware vendor rather than a user, you should anticipate the events described above. You should analyze your client's supply contracts to determine liability in case the client's lack of year 2000 compliance causes damage to others. If compliance is lacking, your client's customers should be notified as soon as possible, and your client should attempt to mitigate potential damage by suggesting alternate or remedial systems where available.

Tort issues

Copyright and patent issues

If your client's software and hardware providers will not bring products into compliance, your client may try to attain compliance through self-help executed personally or through hired consultants. Self-help can be problematic in that it may void warranties in your client's software/hardware contracts (thus also voiding your client's remedies).

More important, self-help also can give rise to liability under copyright law. Even if your client owns software and hardware, your client may not own the underlying copyrights unless he or she has a written agreement to that effect with the authors.¹⁶ If your client doesn't own the copyrights, modifying the software and hardware may create infringing "derivative works" under copyright law.¹⁷

Copyright law generally reserves the exclusive right to create such derivative works to the owner of the copyrights in the preexisting works. Thus, you should carefully review all licenses or other agreements relating to software and hardware to see whether they allow your client to make modifications. If no express allowance for modification is given, you should seek written permission. Permission for modifications must be obtained even if consultants are hired to perform the modifications, since any copyright infringement by consultants may constitute their employer's contributory infringement. Further, any sophisticated consultant will demand warranties that the party requesting software/hardware modifications owns the underlying copyrights or has obtained clearance for modifications, and will demand indemnification for any infringement problems.¹⁸

If your client resorts to self-help, you should review available defenses to copyright infringement. Owners (but not licensees) of software and hardware are allowed to modify programming if such modifications are "an essential step in the utilization of the computer program in conjunction with a machine."¹⁹The copyright defense of "fair use"²⁰ also might be available, but since its application often is complex and uncertain, it may be risky to rely upon the fair use defense as the sole basis for making modifications. If software and hardware providers refuse to repair year 2000 problems or offer solutions, it may be easier to present a fair use defense.²¹

The question of copyright ownership in modifications also should be addressed. While copyrights in works created by employees within the scope of their employment will belong to their employers, absent a written assignment, copyrights in works created by independent contractors will belong to their employers only in rare situations.²² As a protective measure, your client should secure written assignments of copyrights in any works created by consultants, or at least a written nonexclusive royalty-free license to exercise any of the consultant's copyrights so long as such copyrights exist.

Depending on the "fix" being implemented, patent infringement issues also could arise. Several patents on year 2000 problem solutions have been issued by the U.S. Patent and Trademark Office,²³ and more can be expected. Whereas copyright infringement requires copying, patent infringement is more problematic in that it is a strict liability offense which is not excused by lack of "copying" (or independent development).

Employment issues

Anticipate potential employment and labor claims if your client retains any new employees or independent contractors to address year 2000 problems, particularly where it is known that staffing down will occur after year 2000 problems are solved. As the year 2000 approaches, skilled programmers will be in demand and likely will receive many competing employment offers. Thus, it it may be wise to draft employment contracts with an emphasis on retaining personnel who are essential to your compliance program, with rewards being given when certain compliance milestones are completed on schedule. Some employers may be tempted to take an opposite approach and attempt to limit employees' ability to leave by seeking covenants not to compete. Under Wisconsin law, such restrictive covenants have a high risk of being declared invalid unless they are vitally necessary for the employer's protection, for example, where the employee is likely to disclose the employer's trade secrets to competitors.²⁴

Trade secret issues

If your client hires consultants to implement compliance measures on software and hardware, you should review your client's licenses and contracts to be sure that allowing others to access these systems does not breach any covenants to maintain the confidentiality of the software and hardware. If confidentiality provisions are present, seek written waivers. Additionally, your client's own confidentiality must be protected. Year 2000 consultants may be delving deeply into your client's business data and could become intimately acquainted with your client's operations. Written agreements with consultants (and employees) should alert them to the existence of trade secret material, bind them to confidentiality, and obligate them to inform your client if they have been retained by competitors (or if they are so retained in the future). Limit information supplied to contractors to "need-to-know" material, safeguard withheld information, and mark all materials as "confidential."

Liability for managers of business entities

State law imposes fiduciary duties on corporate officers and directors. Failure to perform these duties can lead to derivative suits by shareholders and legal action by the corporation itself, seeking to hold the officers and directors personally liable for damage to corporate assets. The duty of care aspect of these fiduciary duties will likely be most relevant to the year 2000 problem. The duty of care requires officers and directors to act diligently to protect corporate assets from damage caused by foreseeable and material events, and to make decisions on an informed basis after gathering and considering all relevant available information. Thus, officers and directors should locate and address any potentially damaging year 2000 problems, assess their risks and costs, and make contingency plans. Since the year 2000 problems of others could materially affect the corporation's business, the inquiry extends beyond the corporation to companies in which the corporation invests, and to the corporation's vendors and customers.

Matters relating to year 2000 compliance measures should be documented to establish a defense under the "business judgment rule": that officers and directors acted in an informed basis, in good faith, and in an honest belief that their decisions were in the best interests of the company. Any documentation should be sufficiently clear that a nontechnically oriented judge or jury can readily find support for your client's position. It also is advisable to prepare any such documentation with the assistance of counsel so that a claim of privilege might be established (and to better ensure that a record of diligence is established rather than a "smoking gun").

Since many officers and directors are not knowledgeable about software and hardware technology or year 2000 issues, it may be easier to show they met their duty of care if they appoint a committee to appraise year 2000 problems and make compliance recommendations. Such a committee should include one or more outside experts knowledgeable about year 2000 technology issues. The selection of goods and services with "year 2000 certification" from the Information Technology Association of America (ITAA) or other qualified sources also may help establish that the duty of care was met, though the certification process must be scrutinized to determine whether it addresses the corporation's particular year 2000 issues.

Next Page