The Act contains a sunset provision of December 31, 2000.

_______________

Author: Thomas D. Lupo is a Partner in Seyfarth, Shaw, Fairweather & Geraldson, www.seyfarth.com . He is also a member of the firm's Litigation Practice Group, and its Year 2000 Task Force serving the firm's clients. He can be reached at tlupo@seyfarth.com.

 

Statutes of limitations in Y2K warranty claims

By William T. McGrath

If it all goes terribly wrong at midnight on 1-1-00, we can expect a tsunami of litigation. Most of those cases will involve a claim for breach of warranty. Purchasers of software systems or products containing embedded chips will undoubtedly look to their vendors for relief if the products crash as a result of the millennium bug and cause economic loss. Those purchasers will assert breaches of express or implied warranties.

The statute of limitations will have a major impact on warranty claims in Y2K litigation. It is fair to assume that older systems are more likely to fall prey to the millennium bug since most newer systems have avoided the problem through the use of four-digit date fields. Yet the older, non-compliant systems are the very ones which will face statute of limitations problems.

Sale of software or contract for services?

If the breach of warranty claim relates to a "sale of goods," the applicable statute of limitation is §2-725 of the Uniform Commercial Code, (see 810 ILCS 5/2-725) http://www.ilga.gov/ilcs/ch810/ch810act5articles/ch810act5Sub9.htm. Even though most software is licensed rather than sold, the majority of cases have held that a sale or license of software constitutes a sale of goods, and therefore comes within the scope of Article 2 of the U.C.C. See, Nimmer, The Law of Computer Technology, ¶6.02[1]. (For purposes of this discussion, we will refer to "sales" of software, rather than licenses.) However, if the transaction is clearly a contract for services, the U.C.C. will not apply. In situations where there are elements of both sales and service, the court must determine which aspect predominates. RRX Industries, Inc. v. Lab-Con, Inc., 772 F.2d 543, 546 (9th Cir. 1985). If a contract is deemed to be primarily one for services, remedies for Y2K problems will be governed by state and federal law, and the terms of the contract.

Sale of software

Four-year statute of limitations--Section 2-725(1) of the U.C.C. requires that "an action for breach of any contract for sale must be commenced within four years after the cause of action accrued. Section 2-725(2) explains that a cause of action accrues when the breach occurs. http://www.ilga.gov/ilcs/ch810/ch810act5articles/ch810act5Sub9.htm. A breach of warranty occurs "when tender of delivery is made." Subsection (2) explicitly states that the cause of action accrues at the time of breach regardless of the claimant's lack of knowledge of the breach. Thus, in most cases the four years statute of limitation begins to run upon delivery of the software, not upon discovering the defect or at the time the system crashes. It is important to realize when advising clients that the limitations period is ticking away right now, even though the system may operate perfectly well before January 1, 2000. Owners of systems, products or software delivered more than four years ago will in most cases be barred from bringing a breach of warranty claim if the system crashes in January, 2000.

Warranties of future performance extend statute of limitations--There is one important exception. Section 2-725(2) provides that "where a warranty explicitly extends to future performance of the goods and discovery of the breach must await the time of such performance the cause of action accrues when the breach is or should have been discovered." A company that purchased a software system in 1995 with an explicit warranty that the system will function properly for 10 years will probably still have a viable warranty claim in January, 2000 if the system crashes at that time. Undoubtedly, issues will arise in such cases as to whether discovery of the breach must await the time of the future performance, and when the breach should have been discovered. If the purchaser discovered in late 1995 that the software definitely would not function properly after the turn of the century, the exception would not come into play and a warranty claim made after 1999 would be barred. Substantial energy will be devoted in future Y2K litigation to the question of "who knew what, and when?" See, Weikers, Y2K State of the Art, Computer Litigation Journal (ABA), Vol. 5, No. 9, p. 16 (April, 1999).

Illinois caselaw offers little comfort--Illinois cases which have addressed the "warranty of future performance" exception and other attempts to circumvent the four-year limitation period of the U.C.C. have provided little comfort to plaintiffs. Three cases, although not involving computers, are illustrative. In Tomes v. Chrysler Corp., 60 Ill. App. 3d 707, 377 N.E.2d 224 (1st. Dist. 1978), plaintiff purchased a boat which developed a serious defect over time. The plaintiff sought to avoid the four-year bar date by arguing that the fitness of the product could not have been determined at the time of delivery, since the boat took on water over time. The court rejected the plaintiff's argument that the "discovery" rule should apply. The court also held that there was no "explicit" warranty of future performance.

Similarly, in Beckmire v. Ristokrat Clay Products Co., 36 Ill. App. 3d 411, 343 N.E.2d 530 (2d Dist. 1976), the court refused to find that the cause of action accrued upon discovery of the defect. Plaintiff had purchased a supply of bricks, which began to deteriorate over time. The plaintiff sought to avoid the statute of limitations by arguing that the nature of brick is such that a buyer can reasonably expect it to last for many years. The court rejected that argument, stating that "the mere expectation, however reasonable, that due to the nature of a particular product the statute of limitations begins to run on discovery, is not an adequate basis for ignoring the clear language of the statute." 343 N.E.2d at 532. The same rationale would appear to apply to software with Y2K defects which may not be manifest until after January 1, 2000.

The Illinois Supreme Court came to the same conclusion in Moorman Mfg. Co. v. National Tank Co., 91 Ill.2d 69, 435 N.E.2d 443 (Ill. 1982). Plaintiff had purchased a grain storage tank that was warranted to "withstand 60 lbs. per bushel grain and 100 m.p.h. winds." The court held that this warranty did not constitute a warranty extending to future performance, stating, "The mere expectation that a product's warranty extends for the life of the product does not delay the point at which the statute of limitations commences to run. 435 N.E.2d at 454.

Most software licenses and sales in past years have warranties with a relatively short duration. Consequently, for older software systems, the exception for warranties of future performance may have limited applicability in the Y2K context.

New Y2K warranties--An interesting question to be litigated in the next century deals with the effect of the newer strain of Y2K warranties. In the past few years it has become common for purchasers of software to demand that the vendor expressly warrant that the software is "Y2K compliant," e.g.:

"Licensor represents and warrants that the Software is designed to be used prior to, during, and after the calendar year 2000 and that the Software will operate during each such time period without error relating to date data, specifically including any error relating to, or the product of, date data which represents or references different centuries or more than one century. . . ."

If this type of language is construed to be a warranty that "explicitly extends to future performance," then the exception to the rule that breach occurs upon delivery will come into play and the discovery rule will apply. See, Cooke, Beware of the UCC Statute of Limitations When Drafting or Litigating Y2K Warranties, Computer Litigation Journal (ABA), Vol. 5, No. 10 (July, 1999) , suggesting that such warranties "are likely to fall within the future performance exception."

Other causes of action?--Rigorous adherence by courts to the language of §2-725 will bar many of the warranty claims in future Y2K litigation. Plaintiffs will be forced to look for alternative causes of action, perhaps claiming that the U.C.C. does not apply to the transaction in issue or perhaps trying to establish liability under a tort theory. These alternatives may not be available, depending on the fact situation. The four-year statute will therefore become an important consideration in any litigation involving Y2K warranty claims.

_______________

Author: William T. McGrath is a Partner at Davis, Mannix & McGrath in Chicago, .http://www.dmmlaw.com/where he practices copyright, trademark and information technology law. He is an adjunct professor in the LLM. Program at John Marshall Law School, teaching both Copyright Law and Legal Aspects of the Year 2000 Problem. Mr. McGrath was recently elected President of the Intellectual Property Law Association of Chicago. http://www.iplac.org. He can be reached at WMcGrath@dmmlaw.com .

 

General and transactional Y2K disclaimers--Limiting the lawyer's liability for Year 2000-related problems

By Annie E. Thar

General disclaimer:

"Lawyer is not an expert on Year 2000 matters and any advice regarding Year 2000 measures is outside the scope of this representation."

Specific disclaimer for transactional matters *:

"As you know, technical experts are predicting serious problems with computer systems in connection with the arrival of the Year 2000, sometimes called the "Millenium Bug.". The transaction is which you are engaging may involve the acquisition or transfer of computer systems and software or machinery or equipment that is dependent on computer systems. In addition, there may be critical business issues to consider in connection with this transaction that are significantly affected by the Year 2000 problem, such as whether or not your company (or another company upon which you rely), will be able to meet its contractual commitments due to Year 2000 problems.

It is our firm's goal to provide you with superior legal services and to help you evaluate legal issues related to the Year 2000. We are not however technology experts and we strongly recommend that you consult with appropriate experts for advice concerning the technology issues related to the Year 2000."

_______________

*Portions reprinted with the permission of the Professional Liability Fund.

DISCLAIMER: This material includes recommendations designed to reduce the likelihood of being sued for legal malpractice. It is not the intent of these materials to suggest or establish practice standards or standards of care applicable to a lawyer's performance in any given situation. Rather, the sole purpose of these materials is to assist lawyers in avoiding legal malpractice claims, including meritless and frivolous claims. To that end, the intention is to advise lawyers to conduct their practice in a manner that is well above the accepted norm and standards of care established by substantive legal malpractice law. The recommendations contained in these materials are not necessarily appropriate for every lawyer or law firm and do not represent a complete analysis of each topic.

© 1999 Illinois State Bar Association Mutual Insurance Company

Author: Annie E. Thar is Vice-President and General Counsel of the Illinois State Bar Association Mutual Insurance Company www.isbamic.com . She received her undergraduate degree from Mount Holyoke College in South Hadley, Massachusetts in 1979 and her law degree from Northwestern University School of Law in 1983. Before joining ISBA Mutual, Ms. Thar practiced privately for several years, primarily at Hopkins & Sutter. Ms. Thar concentrated her practice at Hopkins & Sutter in insurance and corporate law, and was instrumental in the formation of ISBA Mutual. She is a prolific speaker and author on malpractice avoidance.

 

Y2K for the Small Business (or Law Firm)

By Donna J. Cunningham

I. Y2K Red Flags - What to Look For

II. The Y2K Disclosure Law - How You Can Use It

III. A Triage Checklist for the Business Manager

IV. Resources

I - Y2K (Year 2000) red flags - what to look for

You know that the "Year 2000 computer bug" (Y2K) refers to the problems arising when a computer can't tell the difference between the 1900's and the 2000's because dates have been programmed and recorded as two digits (98) rather than 4 digits (1998). But what, exactly, does that mean for the owner or manager of a small business? And what can you do about it?

Introduction

Computer hardware & software--To begin, the problem must be addressed on two fronts: hardware and software. First, you must check the computer itself (the hardware), because if it's not ready for Y2K, it will send the wrong information to the software programs loaded onto the computer, and the software won't work either. Second, you must check each and every software program on your computer, beginning with the operating system.

Devices with embedded computer chips--The Y2K problem isn't limited to personal and mainframe computers. It also potentially affects every device that uses an embedded computer chip to perform any part of its functions. A typical business, for instance, might depend on any number of such devices: elevators, security systems, fire alarms, fire suppression systems, parking lot gates, vaults, heating and air conditioning systems, thermostats, lighting systems, phone systems including PBX, voicemail, switching and fax services. Those are the general devices.

Then there are also the programmable trade fixtures and those with embedded chips such as printers, presses, stampers, metallizers, conveyors, painters, and other devices too numerous to mention. The loss of any one of these systems could close the doors of your business. And consider the other devices upon which we rely: electronic timeclocks, coffee makers, landscape watering devices, vending machines, postage meters, copy machines. Any of these might fail to work properly if they are not Y2K compliant, causing anything from slight inconvenience to major difficulty.

Suppliers and other third parties--Even if all of your computers, software and devices were fully Y2K compliant, your company could still fail to meet its obligations if a necessary supplier or other third party on whom your company relies, fails to meet its deadline for compliance. To give you an example, if your businesses uses "just in time" inventory control, think what would happen if, inventory depleted, you placed your usual order with a supplier who was not Y2K compliant, and your supplier failed to deliver in January, 2000. Now think of all of the other businesses your business relies on, starting with your bank. Each one of them must also be compliant, or it will affect you. Are they ready? You need to know.

It's time for triage--If you haven't started to address Y2K yet, you probably won't get it all done. You need to prioritize. This is triage, so start with the critical systems--those that you need to keep the doors open--and expand from there. You should do everything you can to prepare in the time remaining, but also plan that something will go wrong, and prepare for that, as well. You're going to need professional help with both legal and technology issues, although there may be some things you can do on your own. Code programmers and Y2K consultants are in short supply, and their prices will be rising. Hire sooner, if you're going to, rather than later. But don't sign any contract until your business lawyer reviews it, and stay in close communication with your lawyer regarding all Y2K issues. There's more to this than meets the eye. As for your computer systems, here's what to look for:

Hardware

Will your computers recognize the year 2000?--A computer knows what date it is first of all because of its hardware. Every personal computer has two devices that govern the date: the Real Time Clock (RTC/CMOS), and the Basic Input/Output System (BIOS). Most people who know about the BIOS assume that if the BIOS is Y2K compliant, then the computer will be. Not true. The CMOS must also be Y2K compliant. If you want the Techie details in plain English, read the next paragraph. Otherwise, skip to "Leap Years". Just remember that both the CMOS and the BIOS must be Y2K compliant.

Techie details (in plain English)--Ordinarily, when you turn on a computer, the BIOS talks to the CMOS, which talks to the operating system, which talks to the software applications. The BIOS tells the CMOS the correct date, and the CMOS passes it along. But if the CMOS is not Y2K compliant, when the year 2000 comes, it won't understand the date it gets from the BIOS, so it will pass along its own date, which will be wrong. Both the CMOS and the BIOS must be Y2K compliant.

Leap years--Even if your computer is ready to handle the transition from December 31, 1999, to January 1, 2000, it still may not recognize that 2000 is a leap year. 1900 was not a leap year, but 2000 is. If your hardware is not Y2K compliant, it will think the year is 1900--not a leap year. Be sure your computer includes the date Tuesday, February 29, 2000, and that the next day is Wednesday, March 1, 2000.

New Computers--Even if your computer is brand new, it may not be fully Y2K compliant. Don't rely on the fact that it is new. Check anyway. If you find a problem, the computer will probably still be under warranty, and any fix should be covered at no cost.

Software

Operating systems--Every computer requires an operating system to make all of the other software work. Some of the most common operating systems are Windows 98, Windows 95, Windows 3.1, MS-DOS, and Mac OS8. Your operating system must be fully Y2K compliant. If it's not, it will pass along the wrong date to your software applications.

Windows 98 is apparently Y2K compliant. Windows 95 is mostly, but not entirely, compliant. Neither are Windows 3.1, MS-DOS, and Novell Netware 3.11 and earlier versions. Mac OS8 is fully Y2Kcompliant, and will operate until the year 29,640, or close to it. DOS and Windows 3.1 systems are not Y2K compliant and will need to be upgraded. If your operating system is not compliant, contact the operating system manufacturer. The easiest way may be to log onto the manufacturer's website, such as www.microsoft. com , or to call the manufacturer for information.

Software programs--Software applications are the computer programs we use to perform various functions. Such programs might perform timekeeping, billing, calendaring, accounting and checkbook functions, word processing, spreadsheet and database functions, scanning, faxing and graphics functions, online research, e-mail, website hosting, internet browsing, internet conferencing, automatic deposit and payment banking transactions, and much more. Each software program you use must be fully Y2K compliant.

1993--A benchmark year--If your time to address software issues is limited, try prioritizing which programs you should check first. Use the year 1993 as a kind of signpost. Was the software developed after 1993? Check the software manufacturer's website on the Internet for information about its compliance status. Many software developers will provide a patch or "fix" at no cost. Was the software written in 1993 or before? It's probably not compliant, and you will probably be required to upgrade or replace these programs. Check them first, and contact the software manufacturer if they are not compliant.

Some commonly used programs that are known not to be Y2K compliant are Microsoft Word 6.0, DOS Word Perfect 5.1, 6.1 and 6.2, WordPerfect 6.1 for Windows 3.1. If you have one of these, you know it will need to be updated.

Leap year--Just as you must check your hardware to make certain it reads the year 2000 as a leap year, so you must check your software programs. Again, make sure the program reads the date Tuesday, February 29, 2000, and that the next day is Wednesday, March 1, 2000.

Other date limitations--In addition, many software programs have been written with internal date limitations.

* For instance, many popular 32-bit programs such as those that are used with Windows 95, Windows 98 and Windows NT, will be unable to process dates beginning in the year 2036. This one problem alone affects every software program written in the popular C++ programming language.

* Microsoft's Excel 95 cannot handle dates after 2078.

* Windows 95's Win32 runtime library fails after 2099.

The chances are, however, that you will have upgraded your software by that time. But then that's what yesterday's programmers thought about the programs we're still using today.

Date-dependent functionality or tech support eligibility--Some software programs have embedded in them the dates through which the product will function, or the date until which you are eligible for technical support either for free or pursuant to a paid program. If the program can't make the transition to January 1, 2000, you may well lose the ability to run the program or to qualify for tech support, for at least some portion of time. Suppose your program stops working on January 1, 2000, which is a Saturday, and on Monday morning, you call tech support for help. Now imagine how many others will be on the phones (providing they work) calling tech support for help with their programs. This is something that you must fix now.

What if the manufacturer says the software is compliant?--As you check your software manufacturer's website for compliance details, pay special attention their definitions of "compliant" or "ready." Virtually every manufacturer conditions its compliance on the compliance of all of the hardware and every other software program on the computer. If your software programs are compliant, but your operating system is not, all of the programs will fail, because they are dependent upon the operating system. In a case where you suffer a failure, each manufacturer is likely to be pointing the finger at the other.

Custom programs --Many industries depend heavily upon custom-created software specific to their needs. After years of modifying the software to suit your particular business, you may find that it will not work after January 1, 2000. Contact the custom manufacturer immediately to determine if the program is compliant, and if it is not, whether it can be made compliant. Depending upon when you commissioned the program, and the terms of your contract, you may be able to get this work done at no cost. Contact your lawyer as soon as possible.

Data--Often the data files your company has saved have been stored in a date format that is not Y2K compliant. If you try to retrieve them after January 1, 2000, without fixing them, they may be lost, corrupted, or simply inoperable. These stored files are usually the most costly to fix because each one has to be fixed manually, and that requires many hours of labor. However, at least one new Y2K product on the market purports to be able to fix all of the data files from certain applications. See "Resources" below.

Devices with embedded computer chips

There are a number of devices with embedded computer chips that businesses routinely rely on, including elevators, security systems, fire alarms, fire suppression systems, parking lot gates, vaults, heating and air conditioning systems,

previous page

next page