|Cem Kaner, Ph.D., J.D.
||P.O. Box 1200
|Law Office of Cem Kaner
||Santa Clara, CA 95052
Can I Sue Thee?
Oh, Let Me
Count the Ways!
Copyright © Cem Kaner, 1998. All rights reserved.
In press, Software QA Magazine.
I'm not a Y2K expert, just a lawyer with a lot of
software experience who's trying to make sense of the legal issues being
raised in the land of Y2K.
The legal situation is plenty puzzling. One the one
side are lawyers telling me that there will be virtually no Y2K litigation
because it will be almost impossible for software customers to sue software
vendors for Y2K-related bugs. On the other side are consultants and lawyers
screaming that the sky has burst and "The lawyers are falling, the lawyers
are falling!" Estimates of $1 trillion in legal costs are common, though
I pointed out in my last article in Software QA on Y2K service contracts
(Kaner, 1998), that this number seems wildly overblown in terms of the
maximum capacity of the American legal system.
The technical situation is even more puzzling. Why
are companies so slow to address this problem? Here are a few articles
from Information Week: Study: Poor Year 2000 Showing For Largest Companies
(Caldwell, 1998; "A study of financial filings by the nation's 250 largest
corporations scuttles any notion that large companies have their year 2000
projects well in hand."); Most Fortune 500s Not Working On Year 2000
Fix (Patrizio, 1997; "Only 16 percent of Fortune 500 companies surveyed
have begun to implement a full-fledged strategy to become year 2000 compliant,
and only 24 percent have a detailed plan in place.); Year 2000 Vendors
Looking for Work, ITAA Survey Says (40% consulting firms are not meeting
their Y2K sales and revenue projections). If you want to get much more
depressed, just go to www.infoweek.com and search on "year 2000."
It seems plausible to suppose that some companies
will not be ready on January 1, 2000. So, what will happen (in legal terms)
if these companies have serious problems? Probably, those companies will
find themselves in a mess.
Before looking further at the legal issues, let's
review some technical issues. What is this Y2K problem anyway?
The Basic Year
The first set of problems are the obvious date-related
errors. Simply put, many computer programs will misinterpret dates. They
will treat 2000 (00) as 1900. This section provides some examples of the
kinds of consequences that this has brought or will bring.
The thing to note is that, as bugs go, these look
like fleas. Pests. A few of them will spread serious disease but the rest
are relatively small, if annoying. Individually, they can be dealt with.
The problem is that there are so many of them.
Granny (born in 1900) might stop receiving her pension checks because the
computer decides that she is a newborn, not 100 years old.
Can’t do future things
some stores can't process credit cards today, because their expiration
dates are 00 or 01. (Produce Palace v. Tec-America Corp., 1997)
comes from the first Y2K lawsuit, described by Warren Reid, who was a consultant
in the case (Scott & Reid, 1998). A magazine publisher sold subscriptions,
often five-year subscriptions, to teenagers. Y2K-related bugs made it impossible
for the publisher to sell subscriptions that ended later than December,
1999. So the subscriptions became four years long, then three years, rather
than five years. Teens' preferences change as they grow older, so a person
who is willing to buy a five-year subscription today will probably not
be willing to renew a three-year subscription to the same magazine three
years from now. The magazine simply lost all that business.
For example, some medication is marked "Best Before
01/01/01" or "01/01/99". An inventory control program might misinterprets
the 01 or the 99 and decide that the medication is almost a century old.
It will then flag to the warehouse staff that they should discard the medication.
This has already been a problem for food vendors.
Another example: You might buy an extended warranty
for your car. It is supposed to expire in 2002, but the auto dealer's computer
might decide that it expired in 1902.
For example, tests of some old telephone billing
software revealed that a call made at 11:59 p.m. on December 31, 1999 and
ending at 12:01 a.m. on January 1, 2000 would be interpreted as having
lasted a full century.
Y2K and Maintenance
The problem that concerns me more than the original
Y2K bug is the side-effect of the Y2K bug fix. We know that when we fix
one bug in a program, there is a significant probability that the fix will
not be fully effective or it will cause something else to break. Kaner,
Falk & Nguyen (1993) cite some statistical estimates of average side-effect
probabilities, but many IT shops will be in worse situations.
Some companies no longer have source code for their
main applications. Or the source is so badly commented, badly organized,
and badly variable-named that it is impossible to figure out the program
from the source. What are the chances that a bug fix to this type of code
will be successful?
In his keynote address to the 10th International
Software Quality Week (San Francisco, May 1997), Boris Beizer described
the principles of nonlocality and nonproportionality. These are important
principles for Y2K:
Nonlocality (and an example)
In the physical world, if you tweak one thing and
thereby break something else, the thing that you broke will probably be
located near to the thing you tweaked. In the software world, if you tweak
one thing and thereby break something else, that broken thing might be
anywhere in the code. This is the principle of nonlocality.
Every moderately experienced tester has experienced
nonlocality the hard way. But here is a Y2K example to illustrate the point.
Suppose you have a fixed-length
record database, with the following fields in each record:
charsLOCATION-NAME = 1
charsLOCATION-BDAY = 61
charsLOCATION-SSN = 67
charsLOCATION-OTHER = 76
We can create
pointers to the starting point of each field within each record. For example,
NAME starts at the first location of the record and so we set LOCATION-NAME
= 1. The total length of each record is 176 characters. Let's create a
variable, RECORD-LENGTH and set it to 176.
Now suppose that
we give this database a Year 2000 fix. BIRTHDAY now gets 8 characters (4
digits for the year instead of 2). LOCATION-SSN will now be 69, because
SSN starts at location 69 in each record. RECORD-LENGTH is now 178 instead
Suppose that you
want to look up the Social Security Number in the third record. In the
original version of the database, this was on the disk, 419 through 427
bytes from the start of the file. In the new version of the database, this
field will be at locations 425 through 433. (I'm ignoring the file header,
record headers, etc. These are just more constants.)
One way to calculate
the location of this field is to compute it through the variables. The
location of the third Social Security Number is 2 * RECORD-LENGTH + LOCATION-SSN,
which is 352+67=419 (in the old file) or356+69=425
(in the new file).
You might think
that this is silly. Today, people would look up this information using
a database management program or standard database management routines,
rather than writing code to skip through the file one record at a time.
But that's today. In the old days, data management programs were slow,
buggy, hard to use, buggy, badly documented, buggy, and expensive. So many
of us wrote our own access routines instead.
I did my first
years of serious programming on PDP-8 computers that had between 4K and
12K of memory. We used a lot of tricks to squeeze big problems into itty-bitty
places. Suppose that you were programming in 1976 (when I was) on a system
like this and you had to write a critical error handling routine for this
database. This routine must make an emergency write of the record in memory
to the disk. You have a choice. You can compute where to save the record
by looking up the values of RECORD-LENGTH and the location variables. Or
you can blast your data to disk using values that you hard coded after
the database design had stabilized. This is faster, requires less memory,
and it will make a horrible mess if you change the structure of the database
without updating this variable.
Back in the 1970's
some of us sometimes rationally decided that the wisest choice under specific
circumstances (such as critical error handlers) was to use hard coded values.
Whether you think this could ever have been rational is up to you. The
fact is, though, that we did it.
Now let's move
forward in time 22 years to today. A generation ago, someone else wrote
code (our database) that you have to fix for Y2K. The program was so useful
that it is still in service. People have patched it over the years and
the current listing of the code (if you have one) is unintelligible. So,
you hire a software archaeologist to figure out how the program works and
how to fix it.
(or her Y2K find-and-fix tools) might find the usual reads and writes to
the database, but she might easily miss a critical error routine that reads
and writes directly to disk without once mentioning the BIRTHDAY date field.
If so, every time the error routine runs, it will corrupt the database.
Changes in one
place in the code can have an impact far, far away.
Suppose that you have a ball on the table. If you
push it, the ball moves. Push it gently, the ball rolls a little. Push
it hard, the ball moves far and fast. Apply more force, have a bigger effect.
Suppose that you have a program on the table. If
you make a little change, you might just have a little effect or you might
have a big effect. A big change (in terms of numbers of lines of code)
might have a modest impact on the program. In contrast, a one-line change
took down much of the nationwide phone system a few years ago.
Little changes can have big impacts.
Have you ever worked on a project in which several
programmers developed different parts of a system? If so, were you involved
in the integration tests? Did the program pass them the first time?
During development, a programmer gets his own code
working (he thinks) and then he brings his code to the larger group and
tries to run it in conjunction with the rest. This attempt is the integration
Systems typically fail integration tests the first
Some companies do incremental integration. They
write some code, add it to the system, test, fix, write more code, add
it, test, fix, and so on. The groups that do a new build every day or every
week are doing some type of incremental integration. Others write all of
their code first and then put it all into integration testing at the same
time. We call this approach "big bang testing." Load everything into the
system together and watch it blow up.
Think about all these companies working on Y2K upgrades
to their systems. It looks to me as though the world is working on the
largest integration test in history. We're building or revising a huge
number of systems that (for financial systems, for example) have to work
together. As we put them in service, we are testing (intentionally or uh-oh,
the hard way) our system's compatibility with the other systems that are
Because so many companies are delaying their Y2K efforts,
we are soon to be facing the biggest big bang integration test in history.
Let's add some more fun.
Definitions of Y2K-compliant vary. Several definitions
of Y2K compliance explicitly state the assumption that all inputs to the
program will provide properly formatted date data. (See, for example, the
Information Technology Association of America definition and the IEEE (1997)
draft standard and the United States Federal Acquisition Regulation.) The
program can be "compliant" even if it can't handle bad input data. Other
definitions require the program to cope with bad data. (See, for example,
New York State Government, 1997), So, we have conflicting or incomplete
requirements, and thus we have more opportunity for the big bang to be
a really big kaboom.
Many date-related Y2K problems might be analogous
to fleas, but in the process of nuking these bugs, we might be creating
No one knows how many failures we'll see in 2000,
nor how serious they'll be. Our collective software maintenance process
might yield Godzilla or it might merely yield a few coderoaches. Only time
Why Are There
A lawsuit arises
out of a failure to live up to a responsibility (duty). Duties arise:
the laws of public safety (such as criminal law and products liability
the laws of fraud and deceptive practices
the laws of fiduciary (caretaker) responsibility (such as the laws that
define the responsibilities of the Board of Directors to a company's shareholders.)
The critical thing
to recognize is that if there is no breach of a duty, there are no grounds
for a lawsuit.
When lawyers analyze
a situation to determine what lawsuits are likely or possible, their typical
analysis involves a few general questions:
are the potential parties (people in the lawsuit)?
are their duties?
duties might be breached due to a Y2K failure?
actions can aggrieved parties take as a result of a Y2K breach?
with Y2K is this: Any relationship or duty that can be interfered with
by a Y2K problem can become the subject of a lawsuit.
Because we don't know how many relationships or duties
are likely to be interfered with, we don't know how to estimate how many
lawsuits there can be or will be.
A Look at the
Insert Figure 1 about here
Any relationship that is polluted by a Y2K bug could
turn into a Y2K lawsuit.
Businesses have a lot of relationships with people
and with other organizations. Figure 1 illustrates four classes of relationships.
Here are a few notes on some of the relationships.
Suppliers of Goods, Data, and Services
Your company might wish to sue a supplier who has
caused you Y2K grief. Some examples of suppliers include software
suppliers, software intellectual property owners, software service suppliers,
outsourcing vendors, Y2K remediation services vendors, data suppliers,
landlords, facilities managers, health services providers, insurers, suppliers
of diagnostics and other tools, hardware vendors for computers and non-computer
hardware, legal and financial service providers, utilities, shippers, and
transportation companies. Here are a few examples.
Software suppliers and intellectual
your supplier's code has a Y2K bug, you might want to sue them, but you
might be surprised. If you have a signed contract with them, it probably
has a sharply limited warranty, with limited damages. (In a mass-market
product that hides these terms inside the box, these limits might not be
enforced by a court. But signed contracts are usually enforceable.)Further,
you might not be able to collect much even if there is a warranty, because
you have a duty to mitigate damages--once you are aware of a problem, it
is your duty to minimize your losses from it. You can only sue for what
you couldn't avoid. Also, you have a limited time in which to sue a supplier,
probably between one and four years after delivery of the software. That's
why we see suits against companies like Intuit and Symantec today. If the
plaintiffs waited until 2000, it would probably be too late to sue. There
might be very few successful suits against software publishers.
these software suppliers might be able to sue you (the customer). Suppose
that you buy software that has Y2K defects and you decide that you want
to fix it. Your software license might prevent you from fixing it. Kaner
& Pels (1998) discuss licensing terms that restrict customers from
fixing bugs themselves or finding third party maintenance organizations
to fix bugs in software.
Nuara, Benard, & Rydberg (1998)
provide an excellent discussion. Some
lawyers are now staking out the position that these terms are fully enforceable
as long as the original vendor is willing to fix the bugs in its software.
Of course, you have to be willing to pay them to fix their bugs. Now Y2K
becomes a revenue generator, rewarding companies that published defective
code. Not surprisingly, the upcoming amendments to the Uniform Commercial
Code (Article 2B, see NCCUSL, 1998) will reinforce the legal basis of these
controversial restrictions. Also, not surprisingly, there will be a major
effort to pass this bill in 1999. (Article 2B was scheduled for 1998. It
took a huge amount of work, but several of us have succeeded in convincing
the organizations supervising the drafting of Article 2B to continue revising
2B for another year before submitting it to state legislatures. For additional
information, see Gillmor (1998), Gleick (1998), or my website, www.kaner.com.)
I wrote about the legal risks of software consultants,
especially Y2K-related consultants, in Kaner (1998).
Suppose that your company outsourced its data processing.
The outsourcer signed a contract to do the data processing. Now it's saying
that "you" have a Y2K problem because its software (which it might have
gotten originally from you as part of the outsourcing arrangement) is not
Y2K ready. Depending on your contract, the outsourcer might be fully responsible
to process your data accurately, without interruption, despite the Y2K
Landlords and facilities management
I understand that some elevators will fail on January
1, 2000. Apparently, these have a built-in clock. The elevator uses it
to track how long it has been since it was serviced. When the clock's year
switches to from 99 to 00, the elevator will decide that it hasn't been
serviced for a century. It will close its doors and descend to the bottom
floor, waiting for the repair technician to show up, do regular maintenance,
and reset the service clock. I'm not sure how often this will happen--other
smart elevators use a 365 day counter rather than a clock tied to the actual
But suppose that you end up in one of these elevators.
How long will it take before the technician arrives? There might be a lot
of elevators in your city, so the technician might be pretty busy.
And here's hoping that your technician is local.
If she has to fly to your city, she might not be able to make it for a
while. My understanding is that some of the FAA (Federal Aviation Authority)
computers are not being updated and that at least one airline is talking
about not flying on January 1, 2000. You might be in that elevator for
a long time. When you finally get out, you might sue everything and everyone
Insurance companies are scared and upset. They are
not happy that their customer companies are postponing and postponing and
postponing Y2K remediation activities. If your company doesn't do much
Y2K fixing, and then all of your systems crash in January, 2000, the insurance
company won't want to pay you off on your Business Interruption Insurance
policy. They'll feel that you could have prevented this problem and therefore
it should be your risk, not theirs.
Insurers are writing limitation after limitation
into their policies, trying to control their Y2K-related risks.
But what if you make a diligent effort to fix your
Y2K problems, allow appropriate time, do the best you can, but your system
still decides to take a vacation on January 1, 2000? Now, you're uninsured.
It would be like having your flood insurance cancelled for fall/winter
1997-1998 because the insurance company read weather predictions about
I mentioned (Kaner, 1998) that some companies were
pushing consultants to sign indemnification and insurance clauses in their
contracts. Since then, some attorneys have coined a new buzz-phrase, OPI.
Other People's Insurance. The idea is that if you can't get your own insurance
for your own company, you should demand insurance from your consultants.
This could allow you to pass through to them any litigation expenses associated
with anything that they were involved with in any way, whether your problems
are their fault or not. A neat trick, born of desperation.
customers and other recipients of your products include customers of goods,
software, and services, receivers of bills and payments, owners of warranties
(which expire prematurely) recipients of scheduled services (such as checkups),
third party users (who buy your product from a reseller) and strategic
A company might end up in litigation with customers
for many reasons. I'll only mention one class of situation.
Some companies are going to triple bill you for
products, demanding payment even after they've been paid. Some restaurants
will run your charge card through their system twice. Some will take your
orders and forget to ship your merchandise. Maybe you'll sue them.
Some of these companies will make mistakes like
these because their software is broken.
Other companies will do this intentionally, in an
effort to defraud you. There are plenty of scam artists in the world and
Y2K will give them a new opportunity. When they're caught, they'll plead
"Oh, but my Y2K bug made me do it. I didn't mean to cheat anyone."
Governments and Regulators
and regulators include (for example) local, state, and federal tax authorities,
state and federal securities regulators, overseers of corporate management
(such as organizations that regulate or monitor nonprofits), financial
auditors, labor and plant safety regulators, advertising regulators, product
safety regulators, courts and administrative agencies, and certification
compliance auditors (such as ISO 9000 auditors).
example, banking regulators are urging banks to develop better data processing
controls. A bank that has weak processes and loses a fortune might not
be able to maintain its status with the Federal Deposit Insurance Corporation.
stakeholders include (for example) employees, shareholders, lenders, employment-related
insurers, unions, officers and directors.
that you are the chair of a corporation that loses a great deal of money
in 2000 because your company did not take adequate measures to make itself
you personally be sued because you are a director of this company?
your company be sued by its shareholders?
The Business Judgment Rule
required to perform their duties with reasonable care, but they are allowed
to make honest mistakes. The business judgment rule protects decisions
that are intended to serve the corporation's business purposes and that
do not involve fraud, illegality or a conflict of interest. A decision
can be attacked if it is not based on a reasonable investigation--if the
company doesn't take reasonable measures to estimate the extent of its
Y2K problems, directors might be at risk if they make bad Y2K-related decisions.
Also, some directors are on bonus-for-profits plans. They stand to lose
bonus money if they spend money (that would otherwise be classed as profit)
on Y2K repair. If these people are involved in a decision to economize
on Y2K remediation, their decision can be attacked as based on a conflict
Publicly traded companies are now required to disclose
their Y2K-related risks in the reports they file with the Securities Exchange
Commission. These disclosures are available to all shareholders. If these
statements are falsely reassuring, and people buy the company's stock on
the basis of these statements, then they can sue the company. If the executives
knew or should have known that the statements were false when they made
them, or they had no way to know whether the statements were true or false
when they made them, then the shareholders might prevail in the lawsuit.
Roles for Testers
We can help our companies survive this mess.
Companies may or may not turn to their software
testing staff for help. Publishers' testers are, in the main, still testing
new products rather than Y2K'ing. Software testers have special skills
that will help companies limit their risks of Y2K litigation. First, here
are some of our skills:
We know how to look for data to answer technical questions.
(end use) orientation:
We know how to ask the question, "Will this work for the end customer?"
and how to prove that it won't (if it won't).
to cope with insufficient information:
We don't need detailed specifications and well documented code. They are
desirable, of course, but we've been working without them for years already.
to dealing with tight schedules:
The ship date is January 1, 2000 or some business-specific date before
that. We have to do the best we can within the schedule constraint. Sound
to bad data and strange code:
Welcome to testing.
reporting skills: Our
primary work product is a report (bug report) that describes a technical
problem. We constantly write reports that deal with troublesome technical
Now, some of the ways that we can help the company.
Every corporation needs an assessment of its Y2K-related
risks. This includes:
associated with defects in your company's IT (in-house, information technology)
software that runs the business;
associated with defective software and data of other companies that will
interact with your company's code and data;
associated with defective software in code that you sell, whether COTS,
customized, or embedded in some other product.
The Board and the Executives need this assessment
in order to make a reasonable business decision about their Y2K investment
strategy. The company needs good data to shield itself under the Business
Judgment Rule. Werder (1998) notes that the government's dominant strategy
in prosecuting bank and thrift officers and directors was to attack the
extent to which they made their decisions on an informed basis.
Additionally, publicly held companies need good data
so that they can publish it to their shareholders. The more accurate the
company's disclosures, the less likely it is to be sued. If the disclosures
(predictions of Y2K ramifications) are inaccurate, then the better the
process used to arrive at the predictions' estimates, the easier it will
be for a company to defend itself against a claim of securities fraud.
You company should also test its billing software.
My bet is that a whole lot of con artists are going to do a whole lot of
creative billing and then defend themselves with a Y2K-related excuse.
A few months into 2000, the regulatory agencies are going to be sick, sick,
sick of hearing "But Y2K made me do it." Unfortunately, it's entirely possible
that your company will also do some creative (that is, erroneous) billing,
by accident. If you make those mistakes, your best defense against someone
investigating you for deceptive trade practices is a solid set of test
documentation that shows that you made a good faith effort to find errors
in the code and prevent errors in the bills. Your company's goal will probably
be to convince the investigator as early as possible that there
is no case here. A good set of test documentation can help your company
achieve that goal.
If your company makes embedded software, you should
be testing, testing, testing for Y2K-related safety. A primary rule of
products liability law is that if you can't make a dangerous product less
dangerous, you should warn people against hazards that they might not expect.
For example, a big sign at the elevator that says, "Do not use this elevator
after 11:00 p.m. on December 31" might save the company from costly, wasteful
litigation.(If no one gets trapped in the elevator, no one sues.)
Some of you
know me well enough to know how much I despise spending time documenting
test efforts. My goal is to do the minimum necessary, to leave more time
for testing and advocating. Unfortunately, for Y2K, the minimum might
be far from zero. In the
face of a credible litigation risk, documentation can provide valuable
defensive evidence. It makes a lot of sense to talk with your corporate
counsel about the style and depth of test documentation and test results
documentation that she would like to have available, in the event of a
lawsuit. More detailed test documentation might not help you find more
bugs, more quickly, or in a more organized way. But it might save your
company from a devastating lawsuit.
I think that there will be a lot of Y2K-related
litigation because so much business-critical code (and some safety-critical
code) is being revised to deal with Y2K issues. The errors can affect almost
any relationship that the company has with any other person or company.
Despite that, I doubt that we'll see anywhere near as much litigation as
we see threatened in the most common predictions.
But no matter what happens to everyone else, we
don't have to treat Y2K like deer looking at headlights. We can help our
companies take reasonable measures that will go a long way toward protecting
them from the most expensive types of lawsuits (the ones involving fraud
or breach of a fiduciary duty or injury to other people). We can help by
doing what we do best, by investigating critically and reporting results
"Year 2000 Vendors Looking for Work, ITAA Survey
Says." Information Week Daily, September 5, 1997. (As cited in Unger,
Caldwell, B. (1998, April 22) "Study: Poor Year
2000 Showing For Largest Companies", Information Week, www.techweb.com/wire/story/TWB19980422S0004.
Coffou, A. (March 20, 1997), "Testimony of Ann Coffou,
Managing Director of Giga Information Group."U.S.
House of Representatives Science Committee. www.itpolicy.gsa.gov/mks/year2000/hearing.htm.
FDIC (Federal Deposit Insurance Corporation) (March
18, 1998) "Year 2000 Risk." Financial Institution Letters. www.fdic.gov/banknews/fils/1998/fil9829.html.
Frazza, P.J., R.J. Jinnett, & M.D. Scott (1998)
Year 2000 Crisis: Legal Issues Conference. Glasser LegalWorks Seminars.
Gillmor, D. (May 26, 1998) "Software Industry Wields
Fine-Print Attack." San Jose Mercury News, www.mercurycenter.com/columnists/gillmor/docs/dg052698.htm.
Gleick, J. (May 10, 1998) "It's Your Problem (Not
Theirs)", New York Times.
Information Technology Association of America, "IT
Product Able to Meet the Year 2000 Challenge." www.itaa.org/proquest.htm.
Institute for Electrical and Electronics Engineers
(1997) Draft Standard for Year 2000 Terminology P2000.1/D3.4, section
3.2.4, "Year 2000 Compliant Technology."
Kaner, C. (1998) "Contracts for Y2K Services: Traps
for the Software Testing Consultant." Software QA, in press.
Kaner, C., J. Falk, & H.Q. Nguyen (1993) Testing
Computer Software, 2nd Ed. ITCP.
Kaner, C., D. Pels (April, 1998) "Copyright Laws and
Y2K Maintenance." Innovations in Software Support: Journal of the Software
Support Professionals Association, p. 2.
Kerr, C.L. (Ed., 1998), Understanding, Preventing
and Litigating Year 2000 Issues: What Every Lawyer Needs to Know Now,
Practicing Law Institute.
MAI Systems Corp. v. Peak Computer, Inc. (1993)
Reporter, Second Series, Vol. 991, p. 511, United States Court of Appeals
for the Ninth Circuit.
Moskowitz, H. & Wallace, R. (March 7, 1996) "Loser
Pays. A Deterrent to Frivolous Claims." The New York Law Journal,
NCCUSL (National Conference of Commissioners on Uniform
State Laws) (1998) Uniform Commercial Code Article 2B—Law of Licensing.
The latest draft is always at www.law.upenn.edu/bll/ulc/ulc.htm.
New York State Government (1997) Year 2000 Warranty
Nuara, L.T., H.P. Benard, & D.K. Rydberg (1998),
“Year 2000: Problem or Opportunity?” in Kerr (1998).
Patrizio, A. (1997, October 10) " Most Fortune 500s
Not Working On Year 2000 Fix." Techwire,
Produce Palace International v. Tec-America Corp.
(1997), Complaint filed with the Circuit Court for the County of Macomb,
State of Michigan.
Scott, M.D. & Reid, W.S. (1998) Year 2000 Computer
Crisis: Law, Business, Technology, Glasser Legalworks.
Unger, T.A. (1998) "Legal Issues for Year 2000 Software
Compliance." In Kerr (1998).
United States Government (August 22, 1997) "Federal
Acquisition Regulation Final Rule on Year 2000 Compliance." Federal
Register, vol. 62, No. 163. www.comlinks.com/gov/farf897.htm.
Werder, R.I. (1998) "Preparing to Defend 'Millenium
Bug' Litigation." BNA Year 2000 Law Report, vol. 1, No. 1, p. 39.
Figure 1: A Business and its Relationships