A version of this article appeared in
Distributed Computing, September 1998
©1998 Distributed Computing, all rights reserved; reprinted with permission.
By now, all of us have heard ad nauseam about the perils of December 31, 1999. Centuries ago, sages warned that we would not survive the night. Years ago, the style sections chided that we'll never get a decent restaurant table or a babysitter. And now, the big software crash -- on the bluest of blue Mondays, January 3, 2000, we will sulk into work with great trepidation (and a week's supply of ATM cash), after surviving the debris of failed air and ground traffic control systems, and turn our first thoughts to . . .
The legal department.
Just like a good neighbor, the legal department is there to address the company's brewing crisis. And senior management is there too, wishing that an ounce of prevention in 1998 could be traded for the current ton of legal and technical cure. And while the company's senior technical staff will, of course, work double-time throughout the spring of 2000, its best value to the corporation is right now, when it can spearhead company efforts to prevent major liability from arising after D-Day. Most technical managers have already joined or been conscripted into Year 2000 strategy committees and audit teams and are cramming new full-time jobs into their already-overloaded schedules.
The technical staff understand better than anyone -- certainly me -- how all the company's software does work, should work, or will not work, in terms of accurately processing dates reflecting the millennium change, and why the "drop dead" date for testing and fixing the software keeps marching inexorably closer in 1999. After all, these guys (or their comrades in spirit) wrote all the programs in the first place. Yet a solution to the Year 2000 problem must be integrated across company departments. The lawyers can best use the technical knowledge so as to limit the company's ultimate liability to myriad parties on myriad legal theories if a software crash occurs. The sales force is critical to advise on which customer relationships are so important that the company cannot even think of suing if a crash occurs, making a business solution mandatory. Meanwhile, the human resources department needs to pinpoint which scarce labor resources are critical from now until summer 2000 and how best to attract and retain key employees.
After the company assembles proper staffing, a complete Year 2000 corporate strategy involves much more than just "patching" the affected software, including at the least: (i) taking inventory of the company's software agreements with third parties; (ii) ranking the importance of all software and the need for its replacement, modification and/or obsolescence, and (iii) designing a company-wide policy for future testing, contract negotiations and disclosure involving Year 2000 issues.
Initial Contract Review
Is it a bird? Is it a plane? Is it a bug? When it comes to software, almost no modern company is a self-contained universe. Most corporations serve simultaneously as software vendors and vendees, licensors and licensees, maintenance providers, client customization partners and the like. All of these relationships are governed by licenses that are long, tedious, filled with legalese, and at times vanish like Hoffa after signing.
Daunting as it seems, a thorough inventory of third-party software agreements is critical to assess the company's potential liability to, and expectations of service from, all other parties. A caveat emptor-style license may provide that, if the licensee's entire system explodes, the licensor need only send a replacement floppy. Others may bind the licensor to fix damaged software promptly (whatever that means in January 2000) or to procure substitutes. Some may say the software comes "as is," but an attached work order may make quality assurances that incur liability. Then again, certain contracts may have disappeared altogether, even though the company still uses the software. If this situation arises, alert the legal department immediately. Separate from the Year 2000 issue, using software beyond the scope of the license grant may create liability for copyright infringement.
When reviewing software agreements, the following provisions will be most relevant to the company's Year 2000 analysis:
- Truth or Consequences -- Representations and Warranties. A software license usually has the parties "represent and warrant" the truth of certain statements made therein, e.g., that the licensor actually owns the licensed software, or that the software is free of viruses. If a representation or warranty is later proved untrue, its maker may have to pay damages to the other party, indemnify such party against any related lawsuits or provide whatever remedies are set forth in the agreement. Going forward, the Year 2000 issue is generally covered separately and explicitly in software agreements. But for most pre-1997 agreements, the parties probably "repped and warranted" only as to more general software problems, such as whether the software had any defects, viruses, bugs or errors.
Therefore, for such agreements, the licensor has "repped and warranted" as to Year 2000 compliance only if the Year 2000 problem can be fairly defined as a "defect," "virus," "bug" or "error." Only the juries of 2003 have the final answer. (Or perhaps earlier ones -- the first Year 2000 case, alleging that a food store's computer system could not process credit cards expiring after 1999, was filed in Michigan in June 1997.) A "defect" suggests a design malfunction, so what about software that programmers designed long ago to last only 10 years, but is being used for far longer, until after 2000? A "virus" is generally caught from outsiders, such as kindergarten classmates or downloadable files sent by Internet friends. This doesn't seem to cover the Year 2000 problem, but what if another party's software "infects" the company's Year 2000 health via its interaction? (Actually, a good contract would excuse a party from Year 2000 damages if the other party's own software were to blame.) An "error" or a "bug" suggests a minor programming imperfection to be cured later through testing and new releases. Can a "bug" not be a bug for decades and acquire "bugness" only on January 1, 2000?
- Vexation without Representation. In addition, the Uniform Commercial Code (the commercial law in all 50 states covering qualifying software sales and licenses) allows lawsuits for breaching contract warranties that are never stated but nonetheless implied, such as whether the software is fit to be used for its contemplated purpose. But is this implied warranty breached if software was contemplated to be used only for the time period before 2000? Of course, for some implied warranties, one party may have waived or disclaimed them all, ending the Year 2000 question (absent a really good lawyer). Such disclaimers and waivers are usually in ALL CAPITALS or bold, signals that you better read this part or you'll be really unhappy later.
- Service with a Smile. Most software licenses obligate the licensor to maintain, support, test, upgrade and/or install the software, via on-site visits, training and/or telephone back-up. Whether these obligations create Year 2000 liability depends on what triggers them -- is maintenance provided in the ordinary course of business, or only to correct "defects" called to the licensor's attention? Even if a licensor is on the hook to keep the software functioning, most licenses probably do not contemplate the crisis support scenario expected in January 2000, and provisions for "prompt assistance" may be of little practical value.
- Tours de Force. Most contracts, software or otherwise, contain a "force majeure" clause that excuses a party for failing to perform after the occurrence of extraordinary events beyond that party's control, such as fires, wars, famine, pestilence, disease, labor disputes and Acts of God. It's unlikely to help in software-related accidents, which usually lack such vestiges of catastrophe. Nevertheless, a taxpayer once convinced the Tax Court that he could take a casualty deduction when the garbage disposal munched his wife's engagement ring, because the disposal was a "fortuitous event over which he had no control" and had "destructive force" akin to fire, storm, shipwreck and the like. But is the Year 2000 problem a "fortuitous or extraordinary event outside the company's control" given the current focus on, and resources devoted to solving the problem?
- Spare Some Change? While all contracts can be amended, this generally requires the consent of the party to be disadvantaged by such amendment. No company can expect to amend away easily its Year 2000 liability. Yet some amendments come in sheep's clothing. For example, a new work schedule appended to a contract may spell out a Year 2000 assistance procedure and liability limit, and thus be incorporated into the main agreement. Or, the contract may state that if the company creates a new (perhaps "patched") release, it is no longer liable for the old version. This provision is gaining prominence -- two class-action lawsuits were recently filed in California alleging that software companies improperly forced users to buy costly upgrades to correct the Year 2000 problem, rather than fixing users' existing software for free.
Prioritizing the Company Response
After a thorough contract review, the company's Year 2000 committee should use the results to reduce promptly and efficiently any Year 2000 liability, both in dollars and customer relations. The contracts' terms are only part of this "real world" story. Whatever a contract states, its promises have value only if the company is willing to sue, or threaten suit to enforce them. This may be unwise if the other party is a powerful and/or friendly player in the field. In addition, suing someone in 2001 may be "too little, too late" if the company undergoes severe business interruption in January 2000. What the company may need most is a guaranteed "cut in line" at the help desk in January 2000, no matter what the cost. On the flip side, if the company rushes save its licensees in January 2000, it may never be sued for any initial software failures, even if that technically breaches the company's contracts. Meanwhile, some contracts may not be worth saving at all -- the software should be obsoleted or the contract intentionally breached and the damages "hit" taken now, before the other party's case really adds up. The business and sales staff is invaluable in this analysis area.
One would think the company could quantify its options regarding Year 2000 liability on its contracts, because the maximum liability for breach can usually be fairly estimated. Contract law generally does not allow contracting parties to sue each other for punitive damages; the goal is to "make whole" the non-breaching party or to give it the "benefit of its bargain" in making the contract. Therefore, the business side can help estimate various licensee (and the company's) costs for software failure, replacement and business interruption, and all other expenses likely to ensue (and thus be sued upon) from a Year 2000 failure and use these costs as a high-water mark for any contract renegotiations or obsolescence decisions.
Of course on this point, leave it to the lawyers to ruin everything. Non-contract theories of liability could make any Year 2000 lawsuit much more expensive for the company. For example, punitive damages and other costs may be available if a product contains a "design defect" or the company did not adequately warn the public about a product's dangers, if the product later causes personal (rather than property) injury. This situation may arise if Year 2000-impaired software causes hospital or pharmaceutical factory equipment to fail. In addition, the recent Year 2000 lawsuits in California allege violations of federal and state consumer protection laws, fraud and deceit, because the software-makers allegedly made improper attempts to evade Year 2000 liability.
Write for an audience. The company's Year 2000 compliance program, once in action, needs to anticipate its future audience -- the juries of 2003 and the lawyers to deter from suing the company. Carefully documenting the company's compliance progress will strengthen any arguments that the company acted responsibly to solve the problem and acted in "good faith" when it told the press or shareholders that everything was under control, even if this later proves false. In addition, any written evidence that the company informed licensees as to the problem and invited their input hurts their future claims for damages, since they may not have properly mitigated them or may have "assumed the risk" of the Year 2000 problem. Disclosure issues are also a huge concern of management, which faces liability under the federal securities laws and the threat of shareholder lawsuits if misleading disclosures or non-disclosures are made about Year 2000 problems and the company's stock price later suffers.
Don't write for an audience. Beyond the company's formal documentation process, Year 2000 issues should be neither seen nor heard. While the general topic has been splashed across newspapers for months, the company's specific plans in this area should be treated as highly confidential, given the huge liabilities at stake. In this regard, any questions from outsiders -- vendors, customers or reporters -- should be answered only by centralized, pre-authorized company spokespeople. This goes double for written materials -- any memos and notes (and, of course, e-mail -- see Legal Bytes 3/98) by non-legal personnel will certainly be handed over to the other side in a future Year 2000 lawsuit. In addition, an informal note on the Year 2000 may turn into a binding contract for the company, whether or not this was intended. Contract law holds that all sorts of written and oral statements can be considered "warranties." For example, if someone in Purchasing checks "yes" on a vendor checklist asking about a product's Year 2000 compliance, that vendor may argue later that checking "yes" was a warranty, even if the company had a separate 70-page contract on the product. If employees are asked even to nod or grunt an answer on Year 2000 compliance, tell them to just say no and call legal.
Technical workers of the world, unite behind your company's Year 2000 program. You have nothing to lose but a massive expenditure of company funds, which could be better spent on bonuses for your department and thus your fancy dinner on December 31, 1999. If you can find a babysitter.