The Great Computer Crash of 2000

• Year 2000 Internet Resources

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 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

Tort law may provide remedies where contract law principles fail. Where personal or property damage occurs from the year 2000 problem, rather than purely economic damage,¹⁴ products liability claims based upon negligence or strict liability theories might be alleged for design flaws, failure to warn of product dangers, and misrepresentation of product qualities. Where purely economic damage occurs (for example, loss of profits, customers, or damage to the software and hardware itself owing to its asserted defect), a claim of fraudulent misrepresentation may be available if you can show that the purchaser detrimentally relied upon a deceptive representation that a vendor intentionally made. Where the intent element cannot be proven, a claim of negligent misrepresentation may be available. If the actions of professionals (for example, engineers) caused year 2000 damages, claims of malpractice also may be possible.¹⁵

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.

Year 2000 disclosure issues

Federal and state laws generally impose a duty on the officers and directors of corporations to disclose to current and potential investors all facts that are "material" to the corporation's present and future financial health. The scope of material information is broad, and generally is regarded to be any information that a reasonable investor would consider important. Disclosure failures can lead to corporate liability and personal liability of officers and directors. Thus, you should review securities laws and common and statutory laws relating to fiduciary duties and disclosure requirements to determine whether a duty to disclose year 2000 problems is present. Where uncertainty exists, disclosure may be the best option to avoid government enforcement actions and investor suits for fraud or other violations.

Regarding public companies, the primary laws of concern are the Securities Act of 1933 and the Securities Exchange Act of 1934. These laws require the disclosure of material information in connection with the registration, offering, and sale of securities and the solicitation of proxies, and also require the reporting of financial conditions in annual 10-K, quarterly 10-Q, and other reports. This can include the reporting of not only past and current financial conditions, but information that could have an effect on future financial conditions. The Securities Exchange Commission (SEC) has stated that year 2000 problems and costs often will be material and that their existence and ramifications should be noted in MD&A (Management's Discussion and Analysis of Financial Condition and Results of Operations) sections of annual 10-K and quarterly 10-Q reports,²⁵ as well as in any other SEC forms and reports requiring such disclosures. Unfortunately, the SEC has not yet offered specific advice regarding the scope of necessary disclosures. Companies seeking more specific guidance may want to review 10-K and 10-Q reports of larger corporations, particularly those in the finance and insurance industries, to learn what other companies are doing.²⁶ Where questions arise regarding the sufficiency of proposed disclosures, it is wise to err on the side of excess detail.

Other disclosure obligations to investors may arise owing to reporting duties imposed on accountants, auditors, and other professionals, or from contractual obligations to creditors or other parties. Additionally, business entities whose activities are highly regulated by particular government agencies should determine whether these agencies have promulgated any rules or guidelines specifically relating to the year 2000 problem. As an example, pursuant to notices issued by the Federal Financial Institutions Examination Council (FFIEC),²⁷ financial institutions may be subject to closer scrutiny if disclosure sufficiency questions arise.

Insurance coverage

You should inventory and analyze your client's insurance policies to determine whether they could cover damage caused by year 2000 noncompliance, help pay for compliance efforts, or provide protection if claims arise from your client's noncompliance.²⁸ Many standard policy terms exclude from coverage most year 2000 problems: Solely financial damage may not be covered; definitions of "property" may exclude loss of computer use and data corruption from property damage (and "property damage" may extend only to damage to property apart from the software/hardware itself); year 2000 problems may not be a specified peril for which coverage applies; and so on.

Policies covering damage from "unanticipated" or "unpredictable" factors arguably may not apply since the year 2000 problem was created purposefully by software and hardware engineers to conserve expensive memory space; thus, it can be said to arise owing to an economic design choice rather than an error or accident. However, some provisions relating to property damage and damage to business records may allow recovery.²⁹

Review policies also for more subtle year 2000 problems that could affect coverage. For example, if property insurance is contingent upon maintaining an operative fire or intrusion detection system, consider whether insurance coverage will become inoperative if these systems are affected by the year 2000 problem. Finally, owing to increased insurer awareness of the year 2000 problem and their eagerness to avoid further claims, it is important to review all policy renewals to determine whether new exclusions or changes in terms adversely affect year 2000 coverage.

Tax issues

Careful tax treatment of year 2000 compliance costs could decrease their burden. Recent Internal Revenue Service (IRS) guidelines generally allow same-year expensing of costs rather than capitalization and amortization.³⁰ Document the steps taken to attain year 2000 compliance to support the preferred tax strategy in the event of IRS inquiries.

Export and foreign law issues

Be aware that a slew of international tax and contract issues can arise if your client looks to "offshore" consultants to solve year 2000 problems. Export problems also can arise where sensitive technology such as encryption algorithms are involved.³¹

Will you be prepared for the year 2000?

This article summarizes only the most basic year 2000 legal issues to provide a starting point for a year 2000 compliance program. Each year 2000 situation is unique and requires careful analysis for additional issues. As you help your clients work towards compliance, keep an eye on the Legislature, government agencies, and the courts to see whether new developments in the law mandate further precautionary measures.³² With reasonable diligence (or better yet, a high budget for software and hardware upgrades), you and your clients should be able to attain substantial year 2000 compliance in time to take off the weekend following Friday, Dec. 31, 1999.

Endnotes

¹ The question asked by all: How old is old? (That is, is my system safe?) ISO-8601, adopted by the International Standards Organization in 1988, was the first widely recognized date standard advocating the use of four-digit year data. However, this does not mean that post-1988 hardware and software is safe. Many programmers and hardware designers did not use four-digit years until the mid-1990s, and there are probably some that still do not use it. Regardless of the age of your hardware and software, you cannot assume that they are free of the year 2000 problem unless their manufacturers (or other reliable sources) have so stated.

² No. 172539, Marin County Superior Court, Calif., filed Dec. 2, 1997.

³ No. 97-3330-CK, Macomb County Circuit court, Mich., filed June 12, 1997.

⁴ Wis. Stat. § 402.313(1)(a) (which parallels U.C.C. § 2-313).

⁵ Wis. Stat. § 402.314(2)(c) (which parallels U.C.C. § 2-314(2)(c)).

⁶ Wis. Stat. § 402.315 (which parallels U.C.C. § 2-315).

⁷ Wis. Stat. § 402.316 (which parallels U.C.C. § 2-316) controls the disclaimer of implied warranties.

⁸ See Wis. Stat. § 402.719(2) (which parallels U.C.C. § 2-719); Murray v. Holiday Rambler Inc., 83 Wis. 2d 406, 430, 265 N.W.2d 513, 525 (1978).

⁹ Wis. Stat. section 402.725(1) applies a six-year statute of limitations running from the date a breach of warranty occurs. In contrast, many other states follow the four-year period applied by U.C.C. § 2-725(1). Thus, in some cases choice of law may be critical. See Office Supply Co. Inc. v. Basic/Four Corp., 538 F. Supp. 776 (E.D. Wis. 1982) (applying the Wisconsin six-year period to a computer hardware/software sales contract despite a California choice-of-law provision (California applying the four-year U.C.C period)). Also note that under both section 402.725 and U.C.C. § 2-725, the limitations period can be shortened by agreement.

¹⁰ Wis. Stat. § 402.725(2), U.C.C. § 2-725(2).

¹¹ See, e.g., ProCD Inc. v. Zeidenberg, 908 F. Supp. 640 (W.D. Wis. 1996), rev'd, 86 F.3d 1447 (7th Cir. 1996). But see Micro-Managers Inc. v. Gregory, 434 N.W.2d 97, 147 Wis. 2d 500 (Wis. Ct. App. 1988) (a contract for development and delivery of custom-programmed software was found to be primarily for services rather than goods, and thus outside the scope of the U.C.C.).

¹² See, e.g., Prof. Raymond T. Nimmer, Preface, Dec. 1, 1995, draft of U.C.C. Article 2B.

¹³ The Article 2 Drafting Committee is making new drafts of Article 2B available as they are completed, and is soliciting and posting commentary by attorneys and the information systemsindustry. As of January 1998 materials can be found on the World Wide Web at www.law.uh.edu/ucc2b.

¹⁴ Wisconsin, like most jurisdictions, has adopted the economic loss doctrine that precludes negligence and product liability tort claims in a commercial transaction where the damages are failure of the product itself and there is no personal injury or damage to other property. Sunnyslope Grading v. Miller, Bradford & Risberg Inc., 148 Wis. 2d 910, 437 N.W.2d 213 (1989); Northridge Co. v. W.R. Grace & Co., 162 Wis. 2d 918, 471 N.W.2d 179 (1991).

¹⁵ See Monique C.M. Leahy, Computer Malpractice, 32 Am. Jur. Proof of Facts 3d (1995).

¹⁶ Under 17 U.S.C. § 202, ownership of copyrights is distinct from ownership of the materials in which they are embodied. 17 U.S.C. § 204 provides that transfers in title to copyrights generally must be in writing to be valid.

¹⁷ The right to create derivative works, as defined in 17 U.S.C. § 101, is reserved to the author(s) of the underlying work per 17 U.S.C. § 106(2). Note that even before any changes to the program's functionality are made, the preliminary task of decompiling software object code to higher-level (and easier-to-repair) source code can itself create a derivative work.

¹⁸ Employers should obtain warranties from consultants that their modifications do not infringe any copyrights and patents.

¹⁹ 17 U.S.C. § 117(1). See, e.g., Aymes v. Bonelli, 47 F.3d 23 (2d Cir. 1995).

²⁰ 17 U.S.C. § 107.

²¹ 17 U.S.C. § 107(4) considers "the effect of the use upon the potential market for or value of the copyrighted work." Thus, if modifications do not "supersede" a provider's products, fair use may be more easily found.

²² The ownership of works made for hire, as defined in 17 U.S.C. § 101, is controlled by 17 U.S.C. § 201.

²³ U.S. Patent 5,600,836 to Harvey Alter (issued Feb. 4, 1997); U.S. Patent 5,630,118 to Daniel Shaughnessy (issued May 13, 1997); U.S. Patent 5,644,762 to Thomas Soeder (issued July 1, 1997); and U.S. Patent 5,668,989 to Decao Mao (issued Sept. 16, 1997).

²⁴ Wis. Stat. § 103.465.

²⁵ SEC Staff Legal Bulletin No. 5, Oct. 8, 1997. MD&A statements are covered specifically in item 303 of SEC Regulations S-K and S-B.

²⁶ Another helpful reference is Beth Duncan, Companies Take a Variety of Approaches to Disclosing Y2K Problems to Investors, 66 U.S. Law Week 2339 (1997). While the risk of preparing disclosures with respect to events that may affect future financial conditions was lifted somewhat by the Private Securities Litigation Reform Act of 1995, the Act provides a "safe harbor" only where future projections (for example, predictions of year 2000 compliance) are coupled with "meaningful cautionary statements identifying important factors that could cause results to differ materially from those in the forward-looking statement."

²⁷ The Dec. 17, 1997, FFIEC Safety and Soundness Guidelines is available on the World Wide Web at the FFIEC home page. Apart from being of interest to financial institutions and their investors, the Guidelines offer information that should assist almost every business entity.

²⁸ For in-depth background of this subject, see Christopher Vaeth, Annotation, Loss of Information Stored in Computer System or on Computer Disk Cartridge, Computer Tape, or Similar Computer Storage Media as Within Coverage of Liability Policy, 85 A.L.R. 4th 1102 (1996).

²⁹ See, for example, Centennial Ins. Co. v. Applied Health Care Sys. Inc., 710 F.2d 1288 (7th Cir. 1983) (finding that the property damage clauses of a controller manufacturer's comprehensive general liability policy covered damage from data loss of a third party who used the controllers).

³⁰ Internal Revenue Service Rev. Proc. 97-50, I.R.B. 1997-45 (Oct. 21, 1997). This scheme agrees with the generally accepted accounting principles (GAAP) for year 2000 costs recommended by the Financial Accounting Standards Board (FASB).

³¹ Certain encryption algorithms are effectively regarded to be munitions under the Arms Export Control Act and cannot be legally exported without permission of the U.S. Department of Commerce and/or Department of State.

³² As an example, on Nov. 10, 1997, Sen. Robert Bennett (R-Utah) introduced Senate Bill 1518 (the Computer Remediation and Shareholder Protection Act of 1997 or CRASH Protection Act) that would require disclosures of year 2000 problems by public companies in somewhat greater detail than SEC guidelines require.

Wisconsin Lawyer