This brief is a shareware legal defense treatise for the purpose of helping programmers and software companies prepare a legal defense against Year 2000 lawsuits. The legal industry is positioning itself to rip off the computer industry for as much as one trillion dollars over the millenium bug. And when I say rip-off, that's exactly what I mean. Without a good legal defense the computer software industry is vulnerable to slick legal arguments that would mislead a jury into awarding damages against software companies that are unjust.

I feel the time has come for me to write this brief and start defining what the legal issues are with respect to Y2K liability so that this document can be used as a legal defense to Y2K millenium bug litigation. This document is intended to be used by programmers and software companies in court so that the judge and jury can more fully understand the complex technical issues involved when it comes to determining Y2K liability. If you get sued for a Year 2000 bug, you're going to want your lawyer to be familiar with the legal issues contained herein.

This document can also be used to prevent lawsuits and litigation from occurring in the first place. By showing the lawyers that software vendors have a strong legal defense, many lawyers will realize that Y2K litigation isn't a pot of gold where lawyers to get rich quick off the backs of programmers and software users. This document is a weapon. Sometimes all you have to do is show the weapon to prevent and attack. This document has that kind of power.

Overview of Y2K *

Understanding the Y2K Background Issues *

Understanding The Y2K Legal Issues *

Avoiding Y2K Lawsuits *

Dealing with the Courts *

Summary - Things to Remember *

Miscellaneous *

As you read this there are teams of lawyers putting together legal strategies to get your money. There are people in the legal industry that think the year 2000 is going to be the biggest windfall for lawyers in the history of the planet. These people are holding seminars on how to sue you. How to make it look like you are responsible for not producing perfect and flawless software, when perfect software has never been nor will it ever be the standard expectation of the industry.

The reality is that the early lawsuit establishes precedent and later lawsuits are often judged by the outcome of preceding suits. It is therefore necessary to bring these ideas into the argument early and establish an argument that is based on reality rather than an illusion created by lawyers. It is therefore necessary to get this in the hands of lawyers representing companies in early lawsuits. If you know of an action that's been filed, please help make the defense attorneys aware of this document.

This document is written for everyone who is interested in Y2K litigation. Its primary focus is for lawyers who are defending software companies against Y2K lawsuits and software companies who might be sued. It is written in common language so as to explain the complex legal issues in a way that people who are not legal experts can understand. This document is a tutorial on law and legal issues relating to Y2K in particular and software in general.

It is also targeted at the press, especially the computer industry press. It is written so that those who report on Y2K litigation can have a better understanding of the underlying legal issues from the perspective of the computer industry. If you are a reporter and want to understand the complex legal issues surrounding Y2K, but want something written in common language, this document is for you.

If you are a programmer or own a software company and want to understand what you are facing, this is written for you as well. I believe the client should be fully informed. These are issues you should show to your lawyer and discuss with him should you be unfortunate enough to be sued. Don't assume your lawyer knows what he's doing. We are in uncharted legal territory where you are more likely to create precedent than to rely on it. Lawyers are lawyers, not programmers and most of them don't know about the legal arguments contained in this document. This will help bring your lawyer up to speed on the issues. However, you might want to edit out some of my candid statements about what I think of some lawyers first if your lawyer has a sensitive ego.

I have searched the web on Y2K legal issues and there are lots of Year 2000 legal sites on how to sue programmers with a variety of theories to make programmers and software companies pay. Some of these sites offer some legal defenses that are viewed as obstacles for them to get your money. No where did I see anything like this document. As far as I can tell, this document is the most advanced compilation of Year 2000 defense legal theory on the planet. I have done a lot of work on this and these legal defense theories are the kind of ideas that can be expected only from the nations best and most expensive law firms. Most of whom are working against you on Y2K, not for you.

The reason I'm so good at this is that I'm a programmer who was forced to learn the law. I'm somewhat of a mental mutant. As a programmer I've written some of the most advanced script languages that exist. Good programmers learn to think "out of the box" and can use the limited resources of a computer to create new and complex programs. The legal industry is very much an "inside the box" culture based mostly on repetition than innovation. Lawyers find a niche and do the same think over and over again. Programmers are generally much smarter than lawyers so the idea that a programmer can rise quickly to become a highly advanced legal mind is not that unusual. This document might well be the most advanced Y2K legal defense on the planet. The fact that I'm not a lawyer may, in fact, make it better.

This document is not free. Although I would like to donate it to the cause, I have to eat. The way I see it, this document is going to save the computer software industry billions of dollars, and I want my piece of it. If you are being sued the cost of using my ideas is one tenth of one percent (1/1000) of the amount you are being sued for. A lawsuit for one million dollars will cost you one thousand. I have a not-for-profit organization (People's Legal Front, http://www.plf.net) that you can donate the fee to and deduct it if you need that kind of deduction. Or, if you're not facing litigation and you like the work I've done and you don't want me to starve, you can make a donation. If I were rich enough I'd just give it away, but I can't.

I have a lot of work in this document and I am posting it on the internet on the honor system. I would appreciate it if those of you who benefit from this will pay me for my efforts. As a programmer I made a lot of money distributing my software on a shareware basis, trusting people who use it to pay for it. This document should be considered shareware legal ideas. Obviously other people are likely to come to the same legal conclusion I have come to, and I would have a hard time knowing where you learned what you did. I am therefore hoping that those who benefit from this will be honorable about sharing in the benefits.

This document is also likely to undermine the efforts of lawyers to bring Y2K lawsuits in the first place. You are likely to benefit from this as lawyers realize that Y2K isn't going to be as profitable as they originally thought. If you consider this work a good thing I would appreciate it if you made a donation to the cause. I would normally not ask but I'm broke. My legal expertise came at the expense of my software company.

Most lawyers aren't programmers, nor are programmers lawyers. Very few people are good at both. I'm not a lawyer, but I was forced to learn the law. My bio is at the bottom of this page. Because the issues here are very complex and technical, most lawyers will not know or understand the issues of law involved in representing you. With Y2K it is much easier for a lawyer who doesn't know anything to make an argument as a plaintiff than as a defendant. As a plaintiff it looks simple on the surface. It looks like a standard product liability suit. "My client bought this software product from the defendant and on New Years the product failed and cause the plaintiff damages. Software is supposed to continue to work." Many defense lawyers, without this document and a poor knowledge of computer technology would advise you to settle, or try to defend you and lose. That's why this document is important. This is here to educate you and your lawyer as to the underlying technical issues viewed from a legal perspective. This document will give your lawyer a fighting chance.

I had an unfortunate experience during my divorce being represented by a lawyer who was totally clueless as to what software is. My ex-wife's lawyers didn't know what it was either and the judge wasn't sure what a computer was. Because I was represented by counsel I couldn't just have a conversation and explain these technical issues. My fate was decided by people who were totally clueless about what they were talking about. That's why I had to learn it all myself. A clueless lawyer can cost you everything you own and then some. And in a Y2K suit, I think a clueless plaintiff is more likely to win over a clueless defense lawyer in front of a clueless judge. With this document your lawyer won't be so clueless.

I don't see this as a vendors vs. users battle. Historically, vendors and users have always cooperated. Solving problems with computers has always been our mutual goal. Y2K is our mutual problem and, with few exceptions, we have been working together cooperatively to face this natural disaster.

The lawyers are the third party. They are trying to insert themselves into the situation in order to create a battle for which they can profit. And like an arms merchant who sells weapons to both sides, lawyers really don't care who wins. They make their money from the fight.

I therefore urge all vendors to go the extra mile and try to prevent the software from crashing in the first place. If it does crash then fix it as quickly as possible and do it for free or at a reasonable cost. Don't leave customers with their systems down.

Likewise, I urge customers to be patient and realize that Y2K is the biggest single obstacle in the history of computer software. Probably the biggest event that will ever occur (Until the Y10K bug where software needs to handle 5 digit dates). You have to realize that not everything can be anticipated and if your program fails, try to understand that cooperating with your vendor and being understanding will probably get your system back up quicker than freaking out and threatening to sue. Many vendors who have Y2K problems may have their phone lines flooded with calls and their web sites might be overloaded for some time. It is therefore important that you have your system backed up, that you're running the latest upgrade, and that you have a contingency plan if your system is down for a few days.

If you know a hurricane is coming you prepare for it and endure it. Afterwards you fix the damages and rebuild. Y2K is properly viewed as a hurricane. You should prepare for it any way you can.

If users and vendors cooperate in good spirits and good faith then we will all get through this thing together without having to give a bunch of blood sucking lawyers a trillion bucks. If these lawyers win, society loses. We vendors and users must work together to defend ourselves from our common enemy and avoid the real Y2K disaster, Y2K litigation.

The purpose of this document is not to give vendors the legal advantage over users, but to give both vendors and users knowledge so as to undermine litigation before it occurs. This document will inform users so that they put their efforts into working with vendors to keep their computers running rather than legal hostilities that hurt both camps. It will help discourage users from being seduced by lawyers into thinking that litigation is a ticket to a magic pot of gold. It is my hope that this document will serve to show lawyers that vendors have the legal tools to mount a formidable defense and that challenging us will be unprofitable.

This document is intended to provide general information and to raise reader awareness and is not intended to provide specific legal advice on anyone's particular set of facts. It is important to realize that your situation may be very different in many aspects than the generalizations I've made here. You have to apply the law to your set of facts. The author of this document, Marc Perkel, is not a lawyer. Although I think I'm pretty smart, it may turn out that I'm not. This is my opinion and I may be wrong. I don't warrant the fitness of this advice for any particular purpose. This document is sold "as is" and it's up to you to determine if it's of benefit to you and your situation. All legal advice should be scrutinized. Especially if it comes from lawyers. Additionally, the advice in this document may fail after January 1^st 2000.

Before we can really get into the legal issues of Y2K we must first understand the underlying background issues in the computer software industry itself. We have to understand the history of software and program development as well as the standards of the software industry. Once we know what we are talking about, we can then apply the law and compare and contrast legal issues relating to Y2K and software with legal issues relating to other products, standards of practice in other industries, and liability in relation to customs and standards of the computer industry.

In my opinion, Y2K is a grossly over hyped disaster that I think will be more of an inconvenience than a real problem. Because of the media attention, a huge effort has been made to prevent crashes. Because of this I believe that the actual problems that are missed will be minimal. But, I have to admit that I don't know that a catastrophe might occur. It's just not very likely.

At the moment the clock hits midnight there will be some computers that will crash, but five minutes later when they are restarted they will be fine. Of the few that aren't fine, almost all of them will be fixed by the next morning. Of the few that aren't fixed by the next morning, most all of them will be fixed by Monday when the business week starts.

For computers that don't run 24 hours a day many of the Y2K bugs will be discovered on the first business day. Most of those problems will be solved within hours. There will be companies with tech support lines jammed. A record number of upgrades will be sold. Within a week almost all Y2K problems will be fixed.

The next event will be the month end billing at the end of January. Surely there will be programs somewhere that calculate negative 100 years of interest and send someone an invoice for minus ten million dollars. Generally this will be caught and corrected. Within a week or two these problems will be corrected.

Then there will be the unknown and unpredictable events. We live in a highly networked society where computers and programs are tied to other programs and data on other systems. A computer somewhere with a bug can generate strange Y2K results that affect other computers that rely on the information on that system. This causes the other computers to crash or behave unpredictably. Most of these systems will be of a more critical nature and may interrupt some services. But the in house programmers will be on site and most all those services will be restored in a matter of hours.

There will also be bugs that are discovered the first day of the new year. Programmer will be scrambling to fix the code. Many of these programs will be easily fixed. Most Y2K bugs only require altering two lines of code and are easily found and fixed once the problem occurs. Most of these problems will be solved within days with a patch available on the internet. This is where liability can occur. The quicker the fix is delivered to the users, the lower the damages will be.

I also predict that there will be a lot of programmer on the job over the New Year's weekend. While the rest of the world is getting drunk and having orgies, computer programmers will be up all night checking and fixing systems to make sure the world doesn't collapse. I believe that these programmers are heroes and that society owes them a debt of gratitude, or at least money as a form of symbolic gratitude.

Then there will be old programs crashing that have been used for 15 years and the programmer is long gone. Some software companies will be out of business. Maybe the programmer has died or the source code is gone. These people are going to suffer. But that's just something that's going to happen.

Then you'll have left a few companies that are just irresponsible. These companies will be covered in industry news magazines and their customers may have to switch to a competing market. There will be some pain and suffering over that. However, these irresponsible software companies will lose their reputation and won't be able to stay in business. And if they are sued they will probably lose, but they won't have any money to collect.

Then there will be some sabotage where company insiders will work with crooked lawyers to create artificial disasters for the purpose of manufacturing a lawsuit. People will try to rip off their employers and blame it on Y2K. I think there will be more damage from fraud than from bugs. I'm sure there are going to be Y2K software viruses. Perhaps some released by vendors of virus software.

When the dust settles and the damaged it totaled, I think that it will be a non-event as far as computer related problems are concerned. More people will be damaged by Y2K scams than by Y2K problems. There will be more Y2K suicide cults than large scale computer failures. The real Y2K disaster will be the lawsuits where lawyers try to rip off the computer industry for one trillion dollars. I see this document as a form of Y2K disaster prevention.

One thing that's important to realize is the Y2K has enjoyed a lot of media hype. A trillion dollars in lawsuits makes a good news story. Computer software issues are very complex and are generally beyond the mental bandwidth of the average reporter and juror. The public has a lot of wrong preconceived ideas about Y2K that play into the hands of those who are suing you. This wrong information works to poison the jury pool against the software industry and will require effort to reeducate the public. Current Y2K publicity will help create a highly emotional and unsophisticated jury pool that is likely to return bad verdicts.

I believe that it would be worthwhile for the software industry to strike back early and to launch a media campaign to educate the public about the reality of software and to move the concept of a Y2K event as an "Act of God" rather than the fault of lazy and negligent programmers. The public needs to know that software is a changing environment and that software consumers are responsible for upgrading and backing up their systems. Right now the legal industry is defining the problem. It would be a mistake if our voices are not heard as well. The software industry needs to invest in some Y2K public relations.

One of the things that is important for the public and a jury to understand is how software is developed and how software development has evolved over the years. In order to fully understand Y2K issues you first have to know where software comes from and how it's produced. Once you understand that you can understand the answer to the question, "If we knew that 2000 was coming, why didn't programmers fix it years ago?"

The first step in writing a program is that you have a concept of a program you want to write that is intended to accomplish a task. In your mind you have a set of features and a rough idea of how it's going to work. You start coding the features and laying out the interface trying to get the core of the program working.

As you develop the program it becomes apparent that you are going to have to add many more features than you originally thought of. Some are things that are necessary to make the program functional. Some things you have to add because you know the users are going to ask for them and you're going to have to add them eventually. Some features you add because it becomes a software solution to a broader market. Eventually you get the core of the program working, more or less. It's good enough to show.

Once it's barely working the sales people start getting copies to show to customers. The customers get excited about it and start asking for new features and changes. You add the features and make the changes and the customers are really excited. They have to have it just as soon as it's functional enough to barely work. The pressure is on. The programmer holds off as long as he can and then releases a beta copy to the waiting buyers.

The code has a lot of bugs but the customers know this. They find problems and the programmer fixes them. Most people don't realize it but writing the core program and getting it working takes about one third of the programming time and debugging, polishing, and adding features in order to get the program marketable takes the other two thirds of the time. And that just gets you up to version 1.0 and no one trusts version 1.0 of anything. In fact it is known that any dot zero version of software is assumed to be buggy.

Although programmers try to anticipate every problem they can imagine, there are always things that you'll never think of. You add a new feature, it breaks something else, or you have to add another feature to go along with the new feature. Often users are trying to use your program in a way you never anticipated, or with more data than you ever thought possible. They break it, you fix it. You're always adding new features and fixing bugs as you go. Although you try to anticipate problems, generally problem solving involves first running into the problem, then finding a solution. More often than not, the first event in fixing a bug occurs when a customer discovers something doesn't work correctly and notifies the programmer.

In between bug fixes is the constant demand for new features and better performance. You are in a race with your competitors and looking for new markets. The custom in the industry is to get the product out now and fix it later. This isn't to say that software vendors are sloppy, but that the customer wants the software, ready or not. In the computer industry, the demand for technology if far greater than the demand for perfection. Buggy software, patches, work arounds, and crashes are the accepted norm. Of course, different situations have different standards. The more critical the system, the higher the standards.

Rarely ever is a program ever "done". Programs live in a dynamic environment where the program usually has to be changed and maintained in order to keep it functional. New operating systems create a new environment for programs to live in and the programmer has to make changes to fix bugs and take advantage of new features created by the new environment. Sometimes it's the new hardware that creates the bug. A program may crash because the processor is too fast and at the time the program was originally written, processors that fast didn't exist. Even things like too much free memory or hard disk space can cause a bug to surface. But this is normal and the customer buys upgrades to deal with new and unexpected problems created by new environments.

Changing laws creates other changes. If you have an accounting package and the government changes the tax laws then your program has to change to deal with these new laws. Sometimes new advances in technology requires program changes because consumers require your software support the latest and greatest toys on the market. There is an old saying that "Necessity is the mother of Invention". But in the computer industry the new saying is, "Invention is the mother of Necessity." Once someone invents something, everyone's got to have one. Programming is a fight to constantly keep up with a changing environment.

Because software maintenance is a never ending process and software continues to change and evolve, programmers expect users to buy regular upgrades to keep the software current with a changing environment. It's been the custom of the software industry for users to expect to have to upgrade just like people expect to get a new phone book every year. A changing environment requires a changing program.

People ask the question, "Why wasn't the Y2K problems fixed years ago?" The reason is that 15 years ago programmers thought that they'll get around to it eventually. It wasn't pressing at the moment. They figured they had 15 years to deal with it so why do it now? Everyone will upgrade before then. And in general they were right. Most all software is substantially Y2K compliant. By substantially, I mean that if there is a bug it's not an apparent bug and will likely be fixed with a minimum amount of pain involved. Another quick upgrade as problems surface. But this is the industry custom and realistically it's just a necessary part of the process. Many of the advancements in software come from the suggestions and complaints of the software users. Users have been and always will be part of the software development process. It's the way things are.

Rarely ever does a computer system and all the software come from on manufacturer. A programmer usually writes a program that counts on a lot of other software to run. On the lowest level of software is the microcode programmed into the processor that teaches the processor to do basic functions, like add numbers. Actually a computer contains many microprocessors that control accessories like disk drives, video displays, modems, network cards, and CD ROM devices. Even the motors in the fans that cool the computers have microprocessors built in these days.

Computers first load the operating system. The operating system is a software program that interfaces with the screen, keyboard, mouse, disk drives, and other devices and allows you to load and execute application software. The operating system also provides software services for application programs. An application programmer need not know how to draw windows on the screen or read sectors from the disk drive. The application asks the operating system to do these jobs. Thus the programmer need only be concerned about reading and writing files and not worry about how files are actually written to disk. This makes it easier to write programs because the operating system does a lot of the work for you. Examples of common operating systems include Windows, Macintosh, Linux, OS2, DOS, and Unix.

Many applications are written in programming languages like C, Pascal, Forth, Basic, FoxPro, or MarxMenu. These languages do a lot of the work and isolate the programmer from having to use "Machine Code" to talk directly to the processor. These languages are routines that provide the programmer with a "high level environment" so that he can put applications together without having to get "under the hood" to get work done.

Many applications interact with other applications and share code and data between different programs or over the internet. These applications depend on other programs or parts of programs to function correctly in order to work themselves. As time goes on, software continues to become more interdependent on other software.

As these interactions and layers of software were developed, programmers became reliant on other programmers to get their parts right. If the operating system has a bug it can affect all the programs that run under that operating system. That operating system might be interacting with other operating systems over the internet sharing information and supplying services to each other and their applications. A failure in one environment might cause a failure in environments that depend on and interact with the failing computer. These interaction can cause other systems to fail merely because they are on the same system.

Programming environments also can have bugs. In windows many applications share code in DLLs that come for other applications. Many operating systems are multitasking, which allows many unrelated applications to run at the same time. A crash in one program can damage other programs that were running at the same time. Multitasking has been around for a long time and has always had these problems. As programs get better, the number of crashes is reduced. Operating systems and processors are becoming better at isolating and offending program and shutting it down without crashing the entire system.

Another thing that's changed in the computer industry is the computer user. The people who use computers are not the same as they used to be. Back in the good old days when computers were expensive and limited, only sophisticated users could afford them. These sophisticated users understood software and programming and were used to bugs, crashes, and upgrades. Back in the 1980s and when programmers felt they had 10 years to become Y2K ready, the type of users that were buying computers upgraded their software on a regular basis.

As computers became more powerful, more stable, easier to use, and more affordable, a broader base of people became computer users. People who can't set the clock on their VCR were buying computers at the grocery store and running powerful applications. These computers today are a million time more powerful than the computer that was on board Apollo 11 that landed men on the moon. In fact, the computers in children's toys that sell for under $20 are more powerful than the ones on the lunar missions. Computers are everywhere and consumers have become dependent on them.

These new unsophisticated users posed new problems for programmers. Software has been evolving to become easier and more reliable to accommodate users who are not as sharp technically as users used to be. These users have higher expectations of computers than their predecessors did and programmers are in the process of trying to keep up with a demand for higher reliability and ease of use.

Although some of the new consumers might expect perfect bug free software that is Y2K perfect and has all the features you would ever want, that software hasn't been invented yet. The reality is that software is an evolving process and software has only evolved so far. New technology creates new problems that are solved after the new technology is put on the market.

When cars were invented people could drive where they wanted. But then you needed better roads. Cars created traffic accidents. There were no drunk drivers before there were drivers. The blessings of technology come hand in hand with the curses of technology. As technology creates solutions it creates new problems to be solved. If not for computers, Y2K would only be another day. But we have all reaped the benefits of computer technology and now we are faced with the challenge of solving those problems. Y2K is the price society has to pay for enjoying the benefits of computers. It's part of the growing pains associated with any new technology. It isn't anyone's fault. It's just the way things are.

Liability is based on standards of care in the industry. For example, a doctor is held to a high standard compared to a TV repairman. If a doctor makes a mistake, people die. If your TV is out, you may miss a few shows. Different people are held to different standards.

Drug companies are another example of an industry that is held to a high standard. Before a drug is put on the market it is sometimes tested for ten years. And even after it's been in use for years there are times when it is removed due to some side effect that no one noticed until it was tried on the public. Drug companies are held to a very high standard of quality before their products can be marketed.

But what of software companies? What is the accepted standard for software? Obviously, that depends on the program. But in general, the industry standard is very low. Why is it low? Because the consumers of software are so eager to run the latest and greatest version that they are willing to put up with the bugs. In the software industry, in general, new features and performance generally take precedent over software quality.

Obviously this depends on the program you are using. If, for example, you write software that controls insulin pumps for diabetics and on the turn of the century the software decides to pump 100 years worth of insulin into a person and kills thousands of diabetics, you're screwed! But if you run a month end report and notice the date is being printed 01-01-0 instead of 01-01-00 you're going to have to buy an upgrade.

Dealing with bugs is part of the industry standard. Microsoft was actually selling copies of Microsoft Windows 95 Beta 3 before Windows 95 was released. Major companies were upgrading their computers to Beta 3 because Beta 3 was significantly more stable than Windows 3.11. There was even books out called "Using Microsoft Windows 95 Beta 3" it was so popular. The need to get the new features and performance for many users outweighed the bugs. Consumers of software clearly want power over stability.

The alternative would be to run software companies like drug companies and keep the software out of the hands of the customers until it is thoroughly tested and deemed bullet proof. If we did that the computer industry would be 5 to 10 years behind where it is now and software would cost 20 times as much. Is it worth giving up the cost savings and technology in order to avoid the bugs? No way! Software consumers have been willing to put up with bugs in order to use the program now, and Y2K is no exception. I therefore contend that the demand for power from the software consumers makes them partially responsible and mitigates the liability of Y2K related problems.

If you are sued it is likely they will argue that there is an implied warranty that the software will continue to run after the year 2000. But if you can fix it and make it run, there's no implied warranty that the software is going to be bug free or that you won't have to buy an upgrade to be Y2K compatible. After all, because software often is so buggy, one of the reasons a user buys upgrades is to get rid of bugs. Many software vendors publish lists of bug fixes as a way to sell their upgrades. So I contend that if the vendor can fix the bug with an upgrade, he has met his responsibility under an implied warranty.

The users of software have responsibilities as well. A user should go to the effort to make sure that they have the latest Y2K version of the software they are using. If, for example, you are running a 1986 version of a Lotus spreadsheet and it crashes, and you failed to upgrade, that's your fault. Consumers should at least make an effort to check the web sites of their software vendors to make sure that they are running the latest and greatest so as to avoid that unexpected crash. Many old programs aren't Y2K compliant because back in the 1980s the programmers figured they still had 10 years to fix Y2K bugs and that they expected all their users to upgrade in that period of time. It would be a mistake to assume that old software isn't going to have a problem.

Additionally, computer systems and data should be backed up just before the end of the year so that if something does happen, you can back up the clock, restore your system, and install the fixes, and recover. If your system crashes and you don't have any backups, then it's your fault that you can't recover. Y2K is a known predictable event and you should take reasonable precautions to ensure that you are protected. If you go into court and you didn't have any backups, I would hope that the judge would laugh at you and throw your case out.

Y2K is like a storm you know is coming. When you know it's coming you have to take steps to protect yourself. If you know it's going to rain and you leave the windows open on your car and the seat gets wet, it's not the fault of the car manufacturer or dealer you bought it from. Users need to take responsibility and make a reasonable effort to protect themselves and to prepare.

Upgrading often involves dealing with new problems. It is better to upgrade now than to wait till the year 2000. It is likely that the web and support phone lines will be overloaded with traffic and calls just after New Years and you may not be able to get through. You might get stuck for several days trying to fix problems that could be fixed now.

Software is a digital program and doesn't rot or deteriorate with time in that it is a file containing a list of numbers that would be the same one million years from now as it is today. However, operating system change and computers change, and the environment in which a program is run changes. Because the environment around a software program changes with time, a program that was bug free when it was sold may not be bug free in an environment that didn't exist at the time the program was sold. When viewed for the perspective of a stable program in a changing environment, software rots like vegetables. Neither a programmer nor a software user can know of a program bought today can be expected to continue to run in the future without being upgraded.

It is a clearly established fact that the computer industry is an environment of change and that software is more accurately viewed as a subscription rather than as an item. It can be compared to the telephone book. The phone book represents, for the most part, an accurate list of published phone numbers in your area on the day the list was compiled. However, people change their numbers, move out of the area, new people move in, people die, and although that phone book doesn't change, the environment changes making that phone book less and less accurate as time goes on. After 50 years it is almost entirely useless, yet it has not changed. For all practical purposes, the data rots. If you don't upgrade to the new phone book every year, it becomes useless.

Software can also be said to rot. Like a phone book, as the environment changes, the program might function differently. For example, in 1985 I wrote a program with a friend of mine called Directory Master. In it's day it was a very cool program. At the time, a 5 meg hard disk was a big drive. A drive as big as 30 megs was unheard of. We all knew that some day big drives would be common, but none were available for testing.

Directory Master had a feature that displayed how much free space a drive had available and that feature work fine. However, over the years drives got bigger and there came a point when I learned that if Directory Master was run on a computer with more than 65 megs of free space it would crash due to a numeric overflow error. Directory Master couldn't deal with more than 65 megs of free space. But I didn't know that at the time.

In hindsight I can see clearly what my problem was and it took all of 20 minutes to fix the problem. At the time I wrote the program, big drives wasn't an issue. When it became an issue, I fixed the problem and users upgraded. Directory Master has been changed many times to adapt to a changing world. Y2K is just one of many adaptations that software has to adjust to.

For example, no software today is going to be Y10K compliant. What will happen in the year 10,000 when people start using 5 digit dates? It's all going to crash. Will Directory Master still show the right amount of free space on a 5 googlebyte drive? Not a chance. If you are going to buy software, you're going to buy upgrades, not just for new features, but to fix bugs as well. You don't really buy software, you subscribe to software. This is the nature of software and has to be taken into account when determining liability.

The first thing that comes to mind is that it must be the fault of computer programmers and software companies. If it's a software bug and it can be fixed with correct programming, then it's natural to conclude that if the programmers did their job right in the first place, Y2K would never have happened. Therefore, the programmers are at fault for not doing their job right in the first place. This creates the presumption of guilt in the minds of the public; a presumption that must be overcome.

However, consumers are unwilling to pay high software prices and wait for years for a program to be thoroughly tested. They want their software now and are willing to live with the bugs. Y2K is no exception. The public has accepted a reasonable number of crashes as standard and Y2K is an extraordinary event. I contend that in most cases the consumer has assumed the risk of running the software and the vendor only has an obligation to provide a solution in a reasonable amount of time. Y2K is not anyone's fault. It's just something that happens. You deal with it and move on.

When a contractor builds a home, there is an expectation that the home isn't going to fall down, even in a storm. However, no one expects the home to withstand a level five tornado. The reason that the contractor isn't held responsible is because the tornado is an "Act of God" and contractors aren't expected to build houses that can withstand a tornado without damage. (The term, "Act of God" or "Vis Major" is a legal concept and has nothing to do with believing that God actually did something or even exists. This is not a religious argument and has nothing to do in any way with what God did or didn't do.)

Generally we think of "Acts of God" to be random and unpredictable events because most "Act of God" cases are based on disasters that happen unexpectedly. But sometimes a disaster is predictable, but there's nothing you can do to completely protect yourself from it. Suppose, for example, that NASA looks out into space and sees a small asteroid that is going to hit San Francisco in one year. They know to the second when it's going to hit and have a rough idea of how much damage it will do. Clearly this would still be an "Act of God" even though we know exactly when it's going to happen. I contend that Y2K is an asteroid.

Like an asteroid, we know exactly when it will hit. As any programmer knows, you can test and test and in a complex system, you're not going to catch everything. Today's software is often connected over the internet to thousands of other systems. These other systems could fail and cause your program to fail because of data that no one could have anticipated. Things are going to occur that no one could have predicted. Although we know when it will happen, no one really knows what is going to happen, or where it will happen, when we cross into 2000. I personally believe that 90% of the Y2K problem will have nothing to do with computers, but that's just my opinion, and I don't know what will actually happen.

Massive amounts of money are being spent on Y2K readiness. In spite of all that money there will still be failures, things that are missed. I contend that the fact that even after this massive effort, the fact that there are still bugs is further proof that fixing all bugs is something that is beyond the ability of mankind. Thus supporting the "Act of God" or force majuere argument.

This is also a "glass is half full" vs. "glass is half empty" argument. On the surface a user see one bug and it's the fault of the programmer. What the user doesn't see are the 999 other bugs you fixed. If you catch 999 bugs out of 1000 it looks like you're doing a good job. That's a lot higher than the customs and standards of the software industry. It can be argued, especially from the perspective of hindsight, that any one Y2K bug was probably foreseeable and preventable. However, are all 1000 bugs foreseeable and preventable? I contend that catching all of them is beyond human ability, and anything beyond human ability can be categorized, from a legal perspective, to be and Act of God. When viewed from the Act of God perspective, it's like surviving a tornado. You're thankful it wasn't worse.

From Uniroyal v. Hood, 588 F.2d 454

Under this definition I contend that Y2K is an Act of God because it is an extraordinary event that is going to test every piece of software on the planet at the same time and the interaction of programs that share data and resources may cause problems that can not be predicted or avoided within the ingenuity of man. Our best minds are making our best efforts within reasonable limits and a lot of what will happen will be things that no one would have thought of, without the benefit of hindsight.

One of the weaknesses that lawyers will exploit is that the event was predictable in that we know when it will happen. Most Acts of God occur without warning, but not all. We know when it will happen, but not where it will happen or what will happen. The what and where aspect being unknown supports the element of randomness which undermines an argument of predictability.

Another weakness is that they will argue that there can be no human involvement in Acts of God. That if the act was partially an act of a human, that it is therefore excluded as an Act of God. This is a misleading argument. The standard is an event that could not have been prevented by the exercise of prudence, diligence, or care. (See Blacks law dictionary definition of Vis Major) This is an area where it's real easy for them to confuse a jury because of the hindsight factor.

For example, they could say that "If the had just added those two lines of code before the end of the year the problem would never have happened." If you knew the bug was there you would have added them. What you have to keep in mind is that fixing a specific bug is usually easy. Finding all bugs and fixing all of them is "wholly above the control of human agency". I've written very few programs that just worked the first time and had no bugs. It scares me when that happens because it's so hard to believe. Writing a program with no Y2K bugs is similar with programs that heavily depend on dates. And don't let them compare your program to others that don't depend on dates.

The thing that makes Y2K an Act of God is that it triggers all Y2K bugs in all software at once. Other bugs occur on a random basis and are spread out evenly over the year and are therefore manageable. Y2K can be compared to getting 30 inches of rain in a single day. It's not the rain that does the damage. What does the damage is the quantity of rain in such a short period of time. Normal debugging can be compared to rain. It's something that you can live with and get used to. Likewise, Y2K can be compared to a big storm and a flood. It's not the bugs that make Y2K an Act of God. It's the quantity of bugs occurring at the same time that makes Y2K and Act of God. That's the legal issue that distinguishes Y2K from normal debugging. Y2K is a bug hurricane, or a bug flood.

A doctor, for example, is expected to provide patients with a high quality of professional care. However, suppose there is a disaster and an explosion injures thousands of people and the hospitals are overrun. The limited number of doctors does everything they can to treat the patients. However, a number of people die who would have survived had they not had been part of a flood of patients who overwhelmed the hospital's ability to provide medical services. Do the quantity of patients provide the doctors a legal defense for a lower standard of care? You bet it does.

I contend that the fact that the legal industry anticipates a trillion dollar windfall is an admission that they expect an overwhelming number of simultaneous bugs to occur. I think that everyone would agree that a trillion dollars is a lot of money. So if you know that a trillion dollars in damages is about to occur at a known specific time, obviously you're going to use due diligence and ordinary care to stop it, if you can. And if you can't do something to stop it, then isn't that the very definition of "Force Majeure"? The fact that we know it's going to happen and can't stop it proves it's an Act of God from a legal perspective. The software industry as a whole will be able to show that hundreds of billions of dollars were spent to fix the problem and the effort still failed. If I were a defense lawyer representing a software vendor and the plaintiff's attorney had a web page that predicted a trillion dollars in damages from Y2K, I would argue that the plaintiff is estopped from denying that Y2K is something that is beyond human ability to prevent. Surely it would be at least beyond the defendant's reasonable control.

I would argue that the fact that Congress, by enacting special Y2K legislation, has made a finding and a decision, recognizing in law, that Y2K is a "Bug Flood" and therefore is an Act of God and that standard liability rules do not apply to Y2K.

As of now Congress has tried and not yet succeeded to pass a Y2K bill. Clearly members of Congress are attempting to do this because they recognize that there is a difference between Y2K and other software bugs. They can see that this is different and that a lower standard of liability should be imposed. I contend that if Congress passes any Y2K legislation that it is fair to interpret it as a recognition that Y2K is correctly viewed as a natural disaster, an asteroid, and that it would be proper for the courts to make the same observation.

This Y2K bill is an important piece of legislation for several reasons. Most important is that it gives Y2K bugs a special liability status and raises the bar for Y2K liability claims. Secondly, it creates a 90 day delay in Y2K lawsuits giving programmers plenty of time to fix the problems created by Y2K bugs. That way companies can spend their resources fixing problems rather than defending lawsuits. It seems to me that most all Y2K bugs will be fixed in 90 days and that a suit brought after the problem was fixed would likely fail to reap a big bucks award in most cases.

I think a smart lawyer who is defending a Y2K suit should definitely assert the fact that Congress has passed special Y2K legislation, and this legislation has given Y2K a special status of liability protection and that normal product liability standards do not apply to Y2K. Congress has clearly decided that Y2K deserves special consideration by the courts and that the courts should not rely on traditional product liability standards. I think it's the intent of congress that the courts form new standards that apply to Y2K specifically and perhaps software in general, and that those standards of liability require a significantly higher standard of proof than what is traditionally expected.

Depending on what happens, Y2K litigation could have a lasting impact on society and every life on the face of the planet. That's why this information is so important. I contend that the biggest impact on society from Y2K won't be because of computer crashes, but because of Y2K litigation. The real Y2K problem isn't with the programmers, but with the lawyers. A number of news accounts have estimated the costs of Y2K litigation at one trillion dollars. If a trillion dollars is shifted from the software industry to the legal industry, our future as we know it will be very different.

It doesn't take a genius to figure out that our present economic recovery and prosperity comes from the computer software industry. Almost every new electrical device has a microprocessor in it. This includes your TV, stereo, watch, phone, microwave, clock, exercise machine, VCR, thermostat, toys, games, greeting cards, cars, and bicycles. Even the cooling fan in your computer has it's own microprocessor. And some programmer somewhere had to write the code that runs these computers. Programmers are the heroes behind our technologically advanced society.

If programmers and software companies are successfully held liable for Y2K it will wipe out many of the software companies we depend on. Lawyers, not programmers, will control the releases of software and the costs will skyrocket. Consumers will be paying higher prices and getting less buggy, but much less powerful programs than they are used to. Small companies won't be able to afford the litigation costs to stay in business and creative programmers will not want to program for fear of being sued. We need to make a choice as a nation about what is more important to us. Do we choose technology, or litigation? Clearly the answer is technology.

The computer and software industry is directly responsible for the strength of our economy. If not for us, this country would still be running deficits rather than surpluses. We would never pay the national debt and our spiraling deficits might have led to World War III. We are now faced with the issue of paying for Social Security for the "Baby Boomers" who retire. Will it be there? Maybe. It depends on the health of the computer software industry. If lawyers are allowed to steal a trillion dollars from the computer industry, it will likely result in a severe depression and cause the economy to fail to increase in a way to pay off the debt and stabilize our retirement budget. When I grow old I don't want to be eating dog food because lawyers raided the software industry in the year 2000.

In the next 50 years we're going to see high speed data access to every home on the planet. Computers will bridge the language barriers. Computers will aid us in genetic research allowing us to cure every disease and stop the aging process itself. We will be able to replace organs by growing new ones. Life spans will go into hundreds of years. We will be able to go to the Moon or Mars and we will have giant space telescopes outside the orbit of Jupiter allowing us to pear back in time and space to the moment of creation, and maybe answer the question, "Why does anything exist?" Or, we can give a trillion dollars to lawyers and spend all our days in court instead.

In deciding these liability cases, and argument needs to be made to weigh an individual's right to sue against the good of society as a whole. Would we have an auto industry if Ford were held liable for every traffic death? Would we have telephones today if the phone company were sued for every crime committed in which a telephone were involved? Small aircraft companies were held to a standard that was far higher than normal and it virtually wiped out the entire industry. Even today, if you buy a small plane, 3/4^th of the cost goes to pay lawyers. We should not allow lawyers to do to software what they did to small airplanes. Not if we don't want to eat dog food when we retire.

The case of Roe v. Armour, 414 F.2d 862 seems to be on point on the issue of liability where an "Act of God" is mixed with acts of man. In this case the court had to decide the issue of what caused oranges to freeze. A chemical release caused oranges to be more likely to be damaged by a freeze, which is an Act of God. The court made an interesting mathematical calculation that resulted in the increased amount of damages resulting from the freeze and held the company liable for the increase in freeze damages.

In that case the defendant was not held jointly and severally liable which would have made them entirely responsible because you can't collect from God. I believe that this case can be cited as a defense so that if a jury finds that a software company wasn't as diligent as they should have been, that the judge can proportion the damages between God and Man so that Man isn't stuck with the whole bill. Thus if the software company is found to be 1% liable, they only have to pay 1% of the damages.

Therefore, it is important that you realize that if you are found to be partially responsible, you want to cite this case and others like it so that you are not held 100% responsible for the damages because you were 1% responsible for the tort.

Contributory Negligence or Comparative Negligence is another common legal factor in calculating liability. If the injured party didn't use ordinary care to protect himself from loss, the damages can be reduced proportionally by the negligence of the injured party.

For example, if a hard drive fails, loss of data may occur. If the user backs up his data daily, his losses would be limited to one day's work and the time it took to restore the data. If they never made any backups then they didn't take reasonable care to protect their data and the manufacturer of the hard drive can not be held liable for losses suffered because the user failed to make backups. If someone sues you claiming a loss, a defense to damages is if the end user failed to exercise reasonable care.

If, for example, you sent the user a letter warning them to upgrade and they failed to upgrade, and the upgrade would have averted the disaster, it may be their fault. However, if you failed to inform them of a known catastrophic problem when they had reason to believe that they were fine, you could be held responsible. Thus it is prudent to show that you were diligent before the disaster occurs.

Under the theory of comparative negligence a jury can assess a portion of the damages to the negligence of the plaintiff and reduce your liability by the percentage amount that attribute to him. Thus if the plaintiff is deemed 50% responsible for his own negligence, you would only have to pay half the damages.

Although we would like to believe that people are honorable, sometimes they are not. One thing we have to watch out for is sabotage. There are people out there that are setting up Y2K disasters the same way people fake car accidents and collect on the insurance. The bigger and richer the company is, the more likely they are to be a target of a Y2K setup.

You may also have employees that are stealing from you who are going to create a Y2K crash to destroy evidence of stealing. I suggest having some off site backups that no one knows about, just in case.

I'm not an expert on the matter as to how to prepare for that. However, I think the first step is to realize it is a possibility and to be aware that it can occur. I think there are a number of sins that will be blamed on Y2K and that it will be an opportunity for mischief. So if you can watch out for that you might get lucky and catch it before it occurs.

I also believe there will be a number of fraudulent Year 2000 crashes that are staged for the purpose of collecting insurance claims. In fact it is my opinion that the number of fraudulent claims will be far greater than the number of real claims. These fraudulent claims will put programmers in a bad light and have a collateral affect on Y2K litigation.

Lawyers in California representing Tom Johnson, a Concord, California resident, have targeted software retailers such as Circuit City and CompUSA for selling software that isn't Y2K compliant. The plaintiff claims he was mislead because some of the software isn't Y2K ready.

I contend the defense to this is that consumers have assumed the risk when they purchase software because it is commonly known that software often isn't perfect and often has bugs that need to be fixed. Upgrading and downloading bug fixes are accepted customs and practices in the computer industry. This case should be dismissed because Tom Johnson has not been damaged and he therefore has failed to state a claim for which relief can be granted (Federal Rule 12(b)(6)). For all he knows, every program might work perfectly or require only a free patch that he will be able to download from the web and fix it just like any other bug. No one sells software that is bug free.

If Tom Johnson actually experiences Y2K problems and his program fails to operate and he can't get a software fix, then he has a cause of action. But if he were to win his case, retailers would be forced to stop carrying software because they couldn't afford the liability of selling software with any bugs, Y2K or not.

I do think that it would be wise for software retailers to distribute a pamphlet about Y2K readiness. This pamphlet could include a warning that some software might break in the year 2000. It might say, for example, "We have no way of predicting for sure that some programs may fail or partially fail after New Years, and the user should be prepared to upgrade the software or download a patch from the internet to fix the problem. A user might want to delay software purchases until the end of the year if they are truly concerned. The user should make a backup of their hard disk shortly before the end of the year. We are having a sale on tape drives to help you to become Y2K ready." Consumers should understand that Y2K is coming and take precautions. Do I think it's the responsibility of software retailers to inform their customers? Actually no I don't. I think the consumers have a duty to prepare themselves. But even though I don't think the retailers are responsible, I do think it would be a good idea for them to take an active position in preventing Y2K related problems.

Should retailers be forced to disclose vulnerabilities to customers? I think not. The reason is that the best place to discover software problem disclosures is on the web site of the companies that wrote the software. It would be far more efficient for retailers to provide a list of web sites where Y2K disclosures can be accessed. I contend that consumers should take an active role in making sure that they know about patches, upgrades, and known bugs. Retailers should not have to be a conduit for Y2K information that is better handled by the software writers themselves. If I were a large software retailer, I would have a web page with links to all the web pages I knew of where Y2K disclosures can be found. I would provide my customers with a pamphlet that gave the URL of my disclosure links page, and a coupon for 20% off on a tape backup. But that's my opinion, and it may not apply to you.

Most stockholder lawsuits to date have been filed against Y2K companies who were going to get rich quick dealing with Y2K problems. These people probably deserve to be sued. But what worries me are stockholder lawsuits against software companies that are manufactured lawsuits, or lawsuits where lawyers have conspired to create the circumstances of the lawsuit itself. I hope that in saying this I'm not giving crooked law firms any ideas. Surely I'm not the first one to think of this. I'm talking about it so publicly traded software companies can somehow defend themselves from crooked lawyers.

Suppose, for example, a mythical software firm, Acme Software, has a market capitalization of 4 billion dollars with stock trading at $40 a share. And unforeseen Y2K event occurs that causes little damage but gets a lot of publicity. Perhaps the reason it gets publicity is that some crooked law firm causes the publicity to occur. A class action suit is filed against the company on behalf of users. In reality, the lawsuit will eventually be found to be bogus because Acme Software corrected the bug within hours and posted it on its web site. Within days all the users were back up and the damages resulted in the loss of a few hours of a few employees time and was a inconvenience. However, before is it decided the crooked law firm makes sure Acme gets a lot of bad press and attacks their reputation.

The lawsuit and the media attacks result in a temporary dip in the stock price and on January 6^th Acme shares have dropped to $25 a share. Because of the dip in stock prices, a second law firm who are friends of the first crooked law firm files a class action lawsuit against Acme. This second suit causes shareholders to panic because of the known litigation costs involved in defending shareholder law suits. The stock drops to $18. This second drop causes all the big shareholder lawsuit firms to jump on board and drive Acme Software into the dust.

I think one of the biggest threats to the Computer Software industry will come from a combination of lawsuits that start out as bogus Y2K suits and grow into self feeding stockholder lawsuits. Even if the software company wins they still end up broke. Ethical standards of lawyers in America as enforced are so low that even if crooked lawyers were caught, nothing would be done about it.

Officers of a corporation are not liable under the applicable states "business judgement rule" unless plaintiffs can prove the defendants guilty of fraud, bad faith, abuse of discretion, of being uninformed or guilty of gross negligence. This would be very hard to prove and a good lawyer should be able to win easily upon showing due diligence.

There are a number of theories of liability that software companies are likely to be sued under. Most of these are common product liability themes that are used to compensate users who are harmed by products. There are a lot of lawyers who are traditional product liability lawyers who are paying a lot of money to take Y2K classes to learn how to get rich suing you. Many of these lawyers will try to employ the strategies they learned in Y2K school and find out that this document completely undermines their cases. A lot of lawyers are going to realize these Y2K schools ripped them off because some computer programmer (me) wrote this legal brief. I hope they sue their schools. Lawyers suing lawyers would be a wonderful outcome.

The defenses I list here are based on the idea that the software company gets the user back up and running in a reasonable amount of time with a minimum of damages. What's reasonable varies with different sets of facts. This defense may not apply to your situation. This is to help software companies defend against unfair litigation. If the litigation is fair however, this information may not help you. It may, in fact, hurt you.

These are intentional torts and they are very hard to prove. In order to win they have to prove that the software deliberately and knowingly misled the user or that the problem could have been avoided using common care.

The defense is that Y2K is a force majeure or Act of God. It was an event that was beyond the ability of man to predict and prevent. It was recognized as such by the Congress who enacted special laws to protect software companies from traditional liability claims. Bugs and fixes are part of the reality of owning computers and software and that the users have assumed the risk based on customs and traditions of the computer industry.

It's not the custom of the computer industry to guarantee bug free software. In most cases if the software vendor gets a fix out quickly then he should win on the basis that this happened to a lot of people and was a widely known catastrophe. It's like when a tornado wipes out a neighborhood, you fix your homes and move on. So I don't believe there is a warranty to survive Y2K with no bugs.

I do believe however that the vendor does have an obligation to fix the problem and make the program Y2K compatible under an implied warranty. However, not necessarily fix it for free. But I think it would be unreasonable to charge more than the usual costs of regular maintenance upgrades. Fixes should be quick and affordable and it would be a good business practice for the vendor to eat a lot of the costs on Y2K problems discovered after 01-01-2000.

If a software company put out any reasonable effort at all they should be able to defend against this claim. However, if your program dies hard at midnight or shortly thereafter and it happens every time, you could be held responsible. For example, I think it was negligent that Novell even put out a version of NetWare 4.10 when the system date jumps back to 1988 the moment it crosses the end of the century. If they had not fixed the problem and provided a free patch, which they have, I'd say roast them. However, they have discovered the problem and have taken remedial action. I'm still not happy with Novell, but I think they have redeemed themselves. If your program dies hard and you haven't even tested it, you could lose big on this issue.

There is no single, uniformly accepted legal definition of what it means for a product to be "Year 2000 compliant." Because of the nature of software I think that the courts will forgive an "honest mistake". An honest mistake is more honest the more obscure and unpredictable the problem is.

To me the claim of "Year 2000 Compliant" means that the software vendor has an obligation fix the software at their own cost and to perhaps cover all or part of actual damages resulting directly from the bug beyond the reasonable costs of computer maintenance. I think that a Y2K ready claim is not a warranty that it actually is Y2K ready as much as a warranty that the company believes at the time that they are Y2K ready and will make it Y2K ready quickly and for free if it fails. A Y2K ready claim ups the liability exposure of the software company and expectations of performance under implied warranty theory are higher. Vendors who claim to be Y2K ready and are not better have a good reason they missed the bug and better take remedial action to solve the problem, for free.

The defense to this is to act in good faith and deal fairly when a problem arises. And by fair you should be more than fair and document it. It's cheaper to be more than fair to avoid litigation and maintain good customer relations. If you screw your customers, it will cost you in the long run. Anyone can create a web page and tell the world how you screwed them. However, I think a claim of "Failure to exercise good faith and fair dealing" should be dismissed if their only complaint is that the program had Y2K problems that were later fixed.

There are lawyers who will claim that your Y2K bug is a virus or a logic bomb because it damaged your computer at a specific time. In order to make that claim they'll have to prove you did it knowingly and deliberately. This kind of claim shouldn't survive a motion to dismiss and you should, in theory, be able to bring an action against the plaintiff's lawyer for abusing the legal system. I say, "in theory", because lawyers almost never can be sued for bringing a frivolous action.

The best way to avoid Y2K liability is to diligently work to prevent the disaster from happening in the first place. No disaster, no lawsuit. However, Y2K by nature is an Act of God and if you're being sued, it may be because something happened that you didn't expect. If this is so, one of the issues at your trial will be how much trouble you went to to try to avoid the catastrophe. If you show that you were diligent and that you worked as hard as can be reasonably expected, based on industry standards, then you may be in the clear or your liability will be reduced. The point is that you should perhaps document your testing efforts in case something comes up. And, if there are known bugs, disclose them to your users so that they can prepare.

Remedial action refers to what you do to provide a remedy after the disaster occurs to fix the problem and limit the damages. If you have a bug in your software that causes a computer to crash, but you get it going again by the Monday after the new year and the user is open for business, then there are no serious damages. If they sue you and win, they won't win much money. The longer a customer is down, the greater the damages will be. You have to get on the problem right away and show you are making your best effort to fix it. If the bug was unforeseeable, and you worked hard to fix the bug, you might not be held liable even though the user has suffered significant losses. But if you ignore the user and leave him down while you party on, it can get expensive.

I believe that if you have a Y2K bug and you fix it promptly it will undermine most all lawsuit possibilities against you. However, if you fail to fix the problem or take too long to fix the problem then you are more likely to be sued and lose. The fact that a Y2K bug occurred is of less significance than if you fail to promptly fix it. If you have customers down, you better get them back up as fast as you possibly can.

If you have known Y2K problems or you suspect that you might have unknown problems that might surface at the end of the year, you should disclose this to your customers so that they can prepare themselves and avoid damages. If, for example, you know that an old version of a program will crash and/or destroy data, you should make a reasonable effort to inform your users of the problem and what they should do to avoid trouble. At a minimum you should have these instructions posted on your web site.

Disclosure is very important and I think you are more likely to be found liable for failing to disclose a known bug than having an unknown bug cause damage. Keeping you mouth shut about known problems it probably the worst thing you can do. If you find you have a problem and you take remedial action to prevent damage from the problem you are likely to not be found liable. However, if it is discovered that you concealed a problem that resulted in damages, you're in big trouble. Hiding problems is a very bad idea.

Many consumers contend that the software companies have a responsibility to provide all their users with free software upgrades, I disagree. Software companies tend to charge money for new versions of their software which contain bug fixes. If consumers have paid for bug fixes all along, why should this bug be an exception? If you decided to save your money and not upgrade to the Y2K compliant version of the software, it's your fault.

Having said that, it also depends on the severity of the bug and the damage it would cause. If your software is running a heart monitoring machine, you'd better make sure that upgrade is installed. If you're playing Doom and it crashes at midnight, live with it. However, I do think it would be smart for software vendors to provide free or discounted Y2K upgrades so as to create good relations with their customers and create good will. Good will can help keep you from being sued. It's better to be smart than to be right.

My advice, for what it's worth, is that if the bugs are minor then the user should pay. But if the bugs are major then the vendor should absorb most or all of the cost. I also think that if the software were written later in the 1990s that the later it is the more responsibility should be placed on the vendor.

If Y2K is an Act of God then it's something that just happens that you have to pay for. My opinion, in the spirit of fairness, is that the costs should be split between the vendor and the user. But how they should be split depends on each individual situation. In general, it's cheaper to work it out rather than to litigate. I suggest using good sense and looking at the long term view of your relationship with your vendors and your customers.

Intuit is being sued because older versions of its software are not Y2K compliant. The upgrade is only $35. The upgrades also include new tax tables that need to be upgraded every year anyhow. Pay the damn $35.

Some software is constantly evolving where other software is static. An example of an evolving program would be a telephone book database that would be upgraded every year. If a user is using a 1990 version of the program he should not be able to complain that the program has Y2K bugs because the phone numbers would mostly be obsolete anyway.

On the other hand, if you've made broad claims about your product and there is an expectation that your product is Y2K ready, you better make it ready free of charge. As a vendor you should consider what the good will of your customer is worth and the cost of defending a lawsuit as opposed to providing a free upgrade. Such bad vibrations could cost you business in the future. Often it's easier to upgrade than to fight and not have to worry about it for another 100 years.

An example that comes to mind is Novell NetWare 4.10. I had a copy of it and I was testing my NovSync program to ensure that it was still Y2K compatible. NovSync is a device driver that keeps the workstation clock in sync with the file server clock. I set the server to 12-31-99 at 23:59 and waited and watched the last minute of the century roll by. The instant it got to midnight, the clock jumped back to 1988. I went to the server to see what it was set for fearing my program had a bug and found out it had set itself back to 1988. I reset the time manually to 2000 and it jumped forward to 2037. My workstation jumped to 2037 as well. My program was propagating the NetWare problem to all the workstations.

I got on Novell's web site and downloaded the patches. It was a known bug and the patches appear to fix the problem. The patches were free, which is the right price. However, NetWare 4.10 is a product written in the 1990s and this was no obscure bug. This happened every time the instant the clock hit 2000. I think it's inexcusable and negligent that a company as big as Novell would be putting out software in the 1990s that screws up so bad the instant it hits 2000.

They have however put out free fixes on their web site and thus have taken remedial action. For those who know about it, Novell has fixed their mistake. They have put it out there where anyone can fix it. However, there will still be a lot of people who get caught on January 1^st. But as soon as they figure out they have a problem, they can get it fixed with a minimum of downtime. If Novell were smart they would give them a free upgrade to NetWare 5 for those who really get stung.

One problem is that my program propagates the error to the workstations. I have changed my program to detect the error and not copy the date if it's wrong. My new version of NovSync is smarter and doesn't contribute to Novell's mistake. My upgrade is also free. And although I think Novell should have known better, how could I have known. I wrote NovSync on NetWare 3.12 that worked correctly. I never thought that Novell would break something that was working.

I've looked at a number Y2K of cases that have been filed and there are some common themes. Here are some of my opinions of current litigation and hypothetical examples.

In August 4, 1997, a Detroit-area produce supplier filed what is regarded as the first case uncovered by the press that revolves largely around Year 2000 compliance issues. In Produce Palace Int'l v. TEC-America Corp., the produce supplier filed suit after the computer system that it purchased to network its cash registers, inventory and accounting systems failed to process credit cards – especially credit cards that expire on or after the year 2000. The credit card transactions crashed the system and prevented the user from being able to check out goods. The software vendor failed to fix the system.

This is an example where I think they deserved to be sued. In this case, from what I understand, the system crashed hard, shut down the users business, and the vendor failed to fix it. The suit was settled for $250,000.

On April 28, 1998, the first of many suits was filed against Intuit, Inc. The complaint alleges the software maker of breach of warranty in connection with its popular Quicken personal finance management software. Intuit is faulted for selling a product that it knew or should have known would be rendered obsolete before the end of its useful life. In April 1998, Intuit began shipping early versions of Quicken 98, a Year 2000-compliant version of the software. Widely distributed prior versions like versions 5 and 6 for Windows and versions 6 and 7 for the Macintosh are non-compliant. The complaint seeks damages and injunctive relief to make Intuit fix the problem free of charge.

On August 27, 1998, after consolidation of the three cases, a Santa Clara County judge dismissed the claims without prejudice. The court found that no damages could be proven in the case. Specifically, Intuit argued that the complaint was premature because it assumed that the program would malfunction at a future date and that Intuit would not provide acceptable upgrades in the meantime. Damages in this situation, according to Intuit, would be merely speculative, and the plaintiffs needed to provide Intuit with a reasonable opportunity to cure the program’s flaw.

This is a case like many other cases where the users are trying to get an undeserved free upgrade. Intuit's upgrades are very reasonable.

Vendors should not try to take advantage of users over Y2K problems. There are some lawsuits where the vendor is claiming to discontinue the non Y2K software and substitute a new medical billing program that is Y2K compliant, charging the customer full retail price for the new product. I think that is a rip off and the customer can rely on an implied warranty of fitness of use. I think that the implied fitness of use warranty theory can not be used to sue for unexpected Y2K crashed that are fixed within a reasonable time at a reasonable cost. Nor does it justify even a free upgrade. But I think the vendor has a duty to have a fix available at a reasonable cost. By reasonable cost I mean that the cost should be in line with expected software upgrade and maintenance costs. The idea that users should have to buy a new program just to make it work is outrageous.

However, if the user has been running a very old version of the program and hasn't bought any upgrades for 10 years when they should have stayed current, then they shouldn't complain about having to pay more than a user who has stayed current.

Lawsuits aren't limited to just software companies. Software users could face liability for failing to upgrade their programs. If you're a hospital or provide other critical services you could become liable for failing to upgrade.

Suppose you are a hospital and you're running a program that schedules maintenance for medical equipment. Because of a Y2K bug some equipment isn't serviced when it's supposed to be. Later a patient is connected to the equipment and it fails and the patient dies. An investigation reveals that had the equipment been serviced as scheduled the failure wouldn't have happened. The patient sues you for wrongful death and you turn to the software vendor for relief only to find that they sent you several notices and upgrades to correct the problem and you failed to install it. In this situation, you're in trouble.

There are a number of companies that have formed around the Y2K problem. Many of these companies sell bogus products and bogus solutions and are as well grounded in reality as an end of the world suicide cult. These companies have sold stock and ripped off investors and not investors are suing.

The news media has lumped these lawsuits in with Y2K lawsuits against software vendors as if they are somehow related to Y2K software bugs. They aren't. I wish the media would separate out Y2K scam companies from the computer industry. Not every problem in the year 2000 is a Y2K bug or Y2K related lawsuit. I urge reporters to get their facts right.

Most people in the United States are under the mistaken illusion that the courts are fair and just. Believing that is a serious mistake. If you haven't had first hand contact with the courts you may be in for the surprise of your life. In America, the term "Justice" is merely a marketing word to promote the illusion that our court system is fair, wise, and honorable. It is not.

When the computer industry goes to battle with the legal industry in the next coming year over the one trillion dollars of the computer industry's hard earned money, the computer industry should realize that the courts are the lawyers home turf. All judges are lawyers as well and tend to see things from a lawyer's perspective. And from a lawyer's perspective, we programmers can be fairly categorized as food.

Even your own lawyer might not be on your side. This is especially true if the lawyers on both sides are being paid by the hour. In this situation the two opposing law firms might be cooperating to keep the litigation going at your expense. When lawyers are paid by the hour the lawyers win even when you lose. That's one of the reasons I'm writing this document so that you can understand the issues and determine if your lawyer is doing a good job or ripping you off.

Lawyers are supposedly subject to the "Rules of Professional Conduct". If you ever actually read these ethical standards you'll quickly realize our legal system is a joke. Most people don't know this but a lawyer is prohibited from making a misleading argument in court. If the Rules were actually enforced we would have the finest courts on the planet.

Judges are supposedly held to high ethical standards as well, however, judges also have immunity from lawsuit. You can have a video tape of a judge taking a bribe and you can't sue him. Supposedly a judge would be removed from the bench for such conduct, but 99.9999% of the time they get away with it. They know they have immunity and many of them don't care what the law or the rules say because for all practical purposes, it doesn't apply to them.

As a programmer who has been forced to learn the law against my will, I have found that programmers are generally more able to understand complex legal issues than most lawyers. That is because programmers do logic for a living and have to be able to comprehend problems and situations that are far more complex than lawyers. I find that I can explain a complex legal issue to a programmer and he follows it easily. The same issue explained to a lawyer takes three times as long to comprehend the same thing. That's why programmers need to read this document and explain it to your lawyers in the context of the facts of your case so that your legal counsel understands it. Especially considering that you are much more familiar with the technical issues involved and your lawyer probably is not.

Having said all this, not all lawyers and judges are crooks. Most are good honest hard working people who are often the victims of a corrupt judicial system as well. Many of my friends are lawyers. Once you have a lawyer that you trust and respect, work with your lawyer and help him understand your case.

However, the judicial system breads fraud and corruption and because the courts don't enforce ethical standards, the least honest lawyers are rewarded and tend to win. This makes the successful practice of law a race to the bottom. He who cheats best gets the most money. America's courts are an embarrassment to a country that was founded on high principles. It's a bad situation and something that every person on the planet should be concerned about.

I could rave on forever. For more information about lawyers and judges, visit my People before Lawyers site at http://www.perkel.com/pbl/index.htm.

Most large and medium size companies have a legal presence in most every state. Therefore a plaintiff can sue you in state court in any state they want unless Congress passes laws to put Y2K lawsuits in federal court only. What many plaintiffs' attorneys do is find a state with a set of laws most favorable to their positions. Some law firms have "special arrangements" with local judges more commonly known as bribes. There are states where lawyers write contribution checks to judges and supreme court justices right there during a trial. I've heard Alabama is the worst and lawyers like to bring class action product liability suits there.

Here is a brief summary of the important concepts covered here. As always, these statements may not apply to the facts of your situation and are intended to be general concepts.

• This is war. The legal industry is using the courts to rip off the computer industry for one trillion dollars. The computer industry has to actively resist this.
• The biggest and most costly damage likely to come from the Y2K crisis will be due to litigation, not computer or software failures. Lawyers, not programmers, will be responsible for the bulk of Y2K losses.
• Lawyers are well organized and are working hard to prepare legal theories to take your money away. The judicial system is their home court and judges, who are lawyers, are clearly on their side not yours.
• Y2K is an "Act of God" and is not the fault of programmer negligence.
• Congress has passed laws to put Y2K in a special status of liability due to Y2K. The courts should recognize this and treat Y2K bugs differently from other product liability cases.
• Software users have generally put priority of features and performance and have assumed the risk of bugs. Y2K is no exception.
• Software bugs are common and an accepted problem in the software industry. It's important to understand that because of the demand for power that bugs are an established and accepted industry custom.
• Selling software with bugs can not be characterized as "unlawful, unfair, deceptive, sales practices" because everybody knows that "bugs happen".
• The impact of Y2K litigation should be considered in evaluation damages. Precedents of liability could cripple the software industry, making software development slower and more expensive.
• Generally, there is no implied warranty that a program will have no Y2K problems. Should problems occur, the vendor is obligated to fix the problem promptly and at a reasonable cost.
• Your liability can be reduced by the rules of comparative and contributory negligence as well as taking remedial action and disclosing known problems before they happen.
• If a vendor is aware of Y2K problems, especially serious ones that can cause damage, they should disclose them as soon as possible.
• Once you discover a Y2K bug you should take remedial action to fix the problem and reduce your liability. Be responsible.
• Good will is one of the strongest defenses in reducing the likelihood of being sued.
• If the software industry is held to a high standard of product liability for Y2K bugs it will have a severe negative impact on society and the economy.
• Programmers need to have their voices heard and to counter false and misleading statements about Y2K from the legal industry. This means the ideas contained here need to reach the press. Especially computer publications.
• The public believes that Y2K is the fault of programmers and negligent software vendors. We must work to change that public perception long before Y2K strikes.
• If this document has been helpful to you in any way I would appreciate it if you could make a donation so that I can continue to eat and live indoors.

I, Marc Perkel, am not a lawyer; I am a computer programmer. I wrote a number of DOS utilities to control large networks including the Computer Tyme Network Survival Kit, MarxMenu, IniTyme, BatZap, NovSync, and WhoHas. In 1994 my ex-wife decided to cash me in. She filed for divorce and I spent $15,000 on lawyers and ended up with a judgement against me for more than 100% of everything I own. My lawyers did a piss poor job, and we're dealing with a court system that is corrupt beyond belief. For all practical purposes, lawyers have taken marriage away, and now they want to take software away. Lawyers are getting involved in every aspect of human activity. They are in a large part a cancer on society, and we need to draw the line.

As a result of a judgement bigger than I could pay, I decided to learn the law and do it myself. As a programmer I deal in logic that is far more advanced than what lawyers are used to and have been able to function effectively in a system that is complex and crooked, and heavily biased against me. I have been in every court that exists and have even appealed causes of action as high as the United States Supreme Court. I am still trapped in the legal system and I don't know if or when I'll ever get out.

However, in the process of being legally abused, I was forced to learn more about the law than I ever wanted to know. I became very good at it and they created a Frankenstein. Forcing a programmer to become a lawyer was a serious mistake on their part. In the mean time my software company went to hell. Now that I had to learn it, I might as well see how I could make use of it. With lawyers positioning themselves to rip off my industry to the tune of a trillion dollars, it seemed to me that writing this document and stopping them is a good way to even the score.

I'm not saying that I hate all lawyers and that lawyers don't have a legitimate place in society. They do, and some of my best friends are lawyers. However, some of the worst snakes on the planet are also lawyers, and because of them I have these legal skills. So, if you are a lawyer, and this document screws you out of a windfall, I want to give credit where credit is due. My legal skills would not be what they are today if not for the Law Firm of Wear and Sharp who represented my ex-wife in her divorce. I also want to mention the crooked and incompetent judges of Greene County Missouri and the Chief Disciplinary Counsel of the State of Missouri who lets lawyers get away with everything. And I would credit the Missouri Supreme Court who, in spite of my writs, continues to support the cover up efforts of the disciplinary counsel.

And I want to thank programmers who created the Internet. If not for the legal research material I have access to on the web, none of this would be possible. If not for the Internet, I would be broke, homeless, in jail, or dead. Instead I have access to the legal resources to make it possible to fight back against the lawyers who would dominate every aspect of life itself.

Our liberties and freedoms don't come free. It is only maintained by the diligence of people like me who put myself on the line to protect what the framers of the constitution gave us 200 years ago. I would rather be writing software, but I'm so far behind that I can't afford to catch up, nor do I have the focus. Therefore, I'm trying to make a living out of what I've been forced to learn. And that's why I produced this document. But I'm really broke right now and if this helps you I'd really appreciate it if you could return the favor. If I can't make a living, I can't help save you all a trillion dollars.

If you like what I've done here and you want to hire me as a consultant or an expert witness, feel free to contact me. I'm not a lawyer, but I can consult with your lawyers to help prepare a legal strategy. God knows I need the work.

This document is far from complete. If you have any suggestions or contributions to improve it, feel free to contact me about it. We can use all the help we can get. The more we can build this common defense the more we avoid becoming the legal industries next meal. I'd like to see software vendors and software users come together and keep the trillion dollars for ourselves rather than funding a judicial system that is little more than a den of self serving thieves. Your well reasoned suggestions could help save someone billions of dollars.

Spread the word. This document is state of the art legal thinking and needs to be widely disseminated. It is especially important that it make it into the press because it counters the legal arguments that the lawyers are trying to put forward about Y2K. Your jury is hearing the lawyer's side of the argument now and is being exposed to their propaganda. This is part of their plan to extract the one trillion dollars from our industry. We need to show the press that we can defend ourselves and that there will not be one trillion dollars worth of litigation. That the legal arguments in this lawsuit will undermine the ability of lawyers to bring lawsuits in the first place and that the battle the legal industry is staging for us will not occur.

This document is a weapon. It's like a gun. You don't always have to actually shoot someone to use a gun to protect yourself. In most cases it is only necessary to show the gun to your adversary to get him to back down. More lives are saved every year by showing the gun rather than using the gun.

There are a lot of lawyers out there that think they are going to get rich off of Y2K. Like the defense lawyers, the lawyers representing the plaintiff are clueless as to the legal complexities of the computer software industry. Many of them look at this as a simple product liability issue. However, once they see this document they will realize that this is not a simple issue or easy money. They will see that the arguments contained herein are sufficiently powerful to undermine most any legal attack. (The exceptions being the few software vendors who legitimately deserve to be sued.) Once they see this defense, many will choose not to attack. The best way to win a lawsuit is to never be sued in the first place. Therefore, the more publicity this document gets, the less Y2K litigation will occur. If you get this published, it may directly or indirectly result in you you’re your company not being sued. We need to show them our weapon. You need to help me make that happen.

Everyone has permission to copy and distribute or reprint this document as long as it's complete. In fact, I encourage distribution. Keep in mind that this document is growing and evolving. If you want to reprint only parts of it then call me for permission. Generally any news story that prints quotes and contains the URL of the entire document is going to be fine with me. I'm seeking news and media exposure over this so as to thwart the efforts of the legal industry to rip off the computer industry.

Copyright © 1999 by Marc Perkel, All rights reserved.

Marc Perkel

309 North Jefferson #220

Springfield Mo. 65802

417-866-1222

Y2K home page: http://www.ctyme.com/y2k/index.htm

This Document: http://www.ctyme.com/y2k/brief.htm

This Document as Microsoft Word File: http://www.ctyme.com/y2k/y2kbrief.doc

Preparing for Y2K: http://www.ctyme.com/y2k/prepare.htm

About Marc Perkel: http://www.perkel.com/marc.htm

Marc Perkel's Home Page: http://www.perkel.com

People before lawyers: http://www.perkel.com/pbl/index.htm

People's legal Front: http://www.plf.net

Computer Tyme: http://www.ctyme.com

Email Marc Perkel: marc@perkel.com