Year 2000 Legal Issues FAQ
Answers provided by Daniel Hassett, Partner in the Technology Section, Williams, Mullen, Christian & Dobbins, Washington, D.C.
Q: Are the hardware and software vendors legally responsible for the cost of fixing this mess?
A: In many cases, the original vendors of hardware and software will face no legal responsibility for the Year 2000 problem. Actual liability will depend on a variety of factors, including the terms of the original license agreement, applicable laws, and the whims of the courts. The viability of any particular claim can be determined only by your legal counsel after review of your contracts, the facts and applicable law. A few general legal principles will come into play, including:
1) Local statutes of limitations will bar claims after a period of time.
2) Contractual limitations of liability and waivers of warranties will prevent any significant claims.
3) When contracts are between substantial, commercial players, courts are hesitant to by swayed by policy-based arguments.
The real wild card in this analysis is the liability of vendors to home consumers and small businesses. In this context, the courts are more likely to take the side of the "little guy" and shift the economic burden to those that are perceived as capable of handling it.
Q: Can my company hire a third party to work on the source code or otherwise assess or modify the problem software?
A: Third-party service providers (not the original vendor) can, and will, remediate systems for you. However, there is a strong line of case law that should be considered to avoid liability. In general, any efforts by such a third party may breach existing license terms, and may violate copyrights of the original vendor. In an ordinary context (non-Year 2000) use of third-party service provider should be avoided unless legal rights are clear. The Year 2000 problem introduces an interesting twist that the courts will be required to sort out.
First, the easy case. Original Vendor ("OV") agrees to fix User’s ("U") system free of charge. Without OV’s consent, U hires a Y2k Vendor ("YV") to fix it, contrary to the original license rights. Outcome: Probable breach of license, violation of copyright (by U and YV).
Tougher case: OV declines to fix your system and refuses to consent to allow YV to fix it. Without alternatives, you proceed with YV. Outcome: Difficult to guess, but there is an argument that the activities of U and YV were permissible due to extreme circumstances, and also constitute "fair use" for copyright purposes. This case could, however, go the other way.
Toughest case: OV agrees to fix your system, but the price is extremely high or OV imposes other conditions U does not like. U instead selects YV to fix it, without OV’s consent: Impossible to say — and very fact specific. How expensive must OV’s offer be to render it a non-offer? How desperate does U have to be?
Q: Why are lawyers involved in this issue? Isn’t it just a technical problem?
A: Although the cause of, and the fixes for, the Year 2000 problem are technical (software assessment, re-engineering and testing), minimizing potential liability, assessing legal rights and pursuing valid claims are legal issues. A company’s failure to focus on the legal issues relating to the Year 2000 may cost the company far more than the company’s expenditures for its technical fix. Legal risk control should be a central component of any significant Year 2000 remediation program.
Q: My vendor calls its software "Year 2000 Ready." Can I rest easy now? What about "Year 2000-Compliant?
A: There is no universal definition of Year 2000 "compliant," "ready," "capable" or "compatible." The actual meaning will be determined by the context of the statement. Two "compliant" systems may be completely unable to exchange data involving dates after 12/31/1999. A "ready" system may be unable to work in the Year 2000 without additional modification (but it's "ready" for that modification. A good warranty should define these terms in language that a court could understand).
Reprinted with permission from BCI's Enterprise Systems Journal, November 1998.