 |
There are less than two years until the year 2000. In this day and age of information and technology, January 1, 2000 may turn from absolute celebration to absolute pandemonium. Two seemingly insignificant digits will confuse computers into mistaking the year 2000 for 1900. Dated information will affect all businesses and individuals who rely on it. As of this moment, companies are spending millions of dollars to reconfigure the ir systems to recognize the year 2000. It is a global problem that is closing in fast.
The year 2000 problem is also known as the Y2K, century-date change, or millennium bug problem. So what exactly is the problem? Put quite simply, "we programmed computers to store the date in the format dd/mm/yy. This means that we’ve allowed two digits for the day (dd), two digits for the month (mm), and only two digits for the year (yy)."1 The first two digits that signify the 20th century, 19, was hard-coded into computer hardware and software. When the clock strikes midnight at the start of the new millennium, computers will roll forward and reset from 1999 to 1900! The year 2000 has no meaning to them.
Imagine all the chaos that would ensue on January 1, 2000. All computer programs around the world would come to a screeching halt. "There would be no air traffic, no traffic lights, no lights in your company, companies could not produce goods, no goods delivered to the stores, stores could not send you bills, you could not send bills to anyone else."1 This may sound extreme. However, the basic gist is that since computers run almost everything today, things that we take for granted like traffic lights and electricity will be adversely affected by the Y2K bug. Also imagine making a loan payment in 1999 for a bill due in 2000. The change from 99 to 00 could mean your payment was due in 1900, leaving you with 99 years worth of late charges. Perhaps the hardest hit though, will be large companies. "The modern world has come to depend on information as much as it has on electricity and running water. Fixing the problem is difficult because there are two years justify to correct 40 years of behavior."1 Economist Edward Yardeni at Deutsch Morgan Grenfell in New York feels that "just as oil is a vital resource for our global economy, so is information. If the supply of information is disrupted, many economic activities will be impaired, if not entirely halted."3 The Gartner Group, a Stamford, Connecticut consulting firm, estimates that the worldwide costs for fixing the Y2K problem could reach $600 billion2.
The Problem
In a nutshell, the Y2K problem is a result of the two-digit convention used to represent the year. The obvious question arises, "Why did we use only two digits when we knew that we would need four digits at the turn of the millennium?" Back in the late ‘60s and early ‘70s, computer memory was very expensive--$600,000 per megabyte compared to just 10 cents per megabyte today. It was costly in terms of how much data the computer could store and how fast it could process the data. The slightest increase in either term came with a hefty price tag.
One method of storing data was by using cardboard called the Hollerith card. These cards consisted of holes punched into patterns. Using a beam of light to read the patterns, one can store and receive data. The typical Hollerith card had enough space for only 80 characters. When it came to storing dates, programmers compromised. A date like 12/25/1998 was stored in the form 122598, omitting the 19 of 1998.
Programmers compromised accuracy versus cost when using only two digits to represent the year. However, one must consider the point of view programmers took in the ‘60s and ‘70s. To them, the year 2000 did not pose a considerable threat since it was 30 or 40 years away. They never imagined that the software they wrote would still be around by the turn of the century. Consequently, much of the software then was used for massive database and mainframe systems. Unfortunately, more recent software adhered to the two-digit convention to complement those systems and use their data. Programmers also made their compromises through conspiracy or collaboration. If clients wanted the four-digit representation of the year, computer managers replied that they would need bigger computers that ran much more elaborate software. All this, of course, came with increased costs. It was highly unlikely that clients were willing to shell out millions of dollars for the extra two digits. Since no foreseeable problem would arise in the next 40 years, they may have gone as far as to even push for single-digit year representation and save even more money! From the vendors’ point of view, the focus as well was on immediate cost reduction, profits, and consequences.
Applications currently using the two-digit year representation dominate those using four digits in the ratio of 20 to 1. Applications using two digits ran on systems intended for immediate use rather than long-term predictions. They exist in operating systems, embedded applications, and many government and business software applications. The worst Y2K problems will occur at or near the turn of the century. Embedded software in power plants, telecommunication networks, and specialized equipment will encounter hidden date problems. In particular, companies and government agencies whose fiscal years decouple from the calendar year will experience problems well before the millennium.
The natural inclination is to say, "Why not just put the two digits back in? How difficult could it be?" It is very difficult, as a matter of fact. There are two cases to consider. First of all, one has to find the dates. The average company may have more than 100 million lines of code. Compound this with the number of such companies in the past 30 or 40 years to understand the quantity of existing code. Suppose that it took an individual one second to examine one line of code. Assuming 40-hour weeks, one would need over 13 years to look through 100 million lines of code. From another perspective, it would take 13 people to do the same job in one year.
Secondly, one needs to determine what a date is. Machines are pure number crunchers. They see a number like 1998 just as it is, an integer. They have no conception of years. With the Y2K problem, a date operation such as 1950 subtracted from 2000 would be interpreted as 1950 subtracted from 1900. Without fuss, the computer would compute -50. The operation is correct until we as programmers render the negative result meaningless. If all dates were named by some standard, then the task of locating dates within code would be much simpler.
The Solutions
It is now 1998 and there is no longer time to actually go into software and databases to convert date fields from the two-digit representation to four-digit representation. Although there are strategies to accomplish this, other strategies do not actually change date formats, but rather use masking techniques. These techniques involve external software to manipulate dates entering and exiting an application. The following is a rundown of the different strategies for tackling the Y2K problem4.
The first strategy is date field expansion. This is the classic brute-force method of permanently converting date fields from two-digit format to four-digit format. Often there are numerical representations such as xxx98xxx, where 98 refers to 1998, in an eight-digit serial number. If we rely on date field expansion, it would take 36 to 40 months to complete all changes. This repair strategy is obviously unfeasible in the time between now and 2000. Although this method is complete, it requires modification to all programs and databases that reference date data as well as positional references to date fields.
Another strategy is windowing. Assume a logical window from 1915 to 2014. Dates below the midpoint of this window such as 10 refer to the 21st century as 2010. Similarly, dates above the midpoint such as 98 refer to the 20th century as 1998. Windowing can be completed in 18 months and is quite popular for businesses late in starting their fixes. The disadvantage of windowing is that users of the data must have existing knowledge of the windowing operations. Plus, a window cannot be larger than 100 years.
Compression allows encoding within the two-digit format for the year to represent any possible date. The key is not to use the two digits to explicitly represent the year. Encoding the two digits in binary or hexadecimal, rather than decimal, would allow more data to be stored than just the last two digits of a year. Thus, the two digits can handle dates over almost any period. Compression can also be accomplished in less than two years. However, as in windowing, users must have prior knowledge of the encoding techniques.
Encapsulation uses an external tool that shifts all dates downward by 28 years. After the shift, 1972 represents the year 2000. The reason for using 28 years is that the 28-year period brings the days of the week in sync with the calendar days. For example, adding 28 years to Saturday, January 1, 1972 generates Saturday, January 1, 2000. This works only for periods that have a leap year every four years (1901-2100). Thus, encapsulation will not work past February 28, 2100. This method is applicable by the end of the century, but also incurs its share of performance penalties.
The hybrid strategy of bridging applies to database applications where the application software is converted from two-digit to four-digit format, without disrupting the underlying database. This solution converts data from one record format to another. Systems can convert two-digit to four-digit dates as needed, converting data gradually rather than all at once. Bridging is popular among late starters because it is quite cost-effective and simple to implement. However, it also exacts performance penalties. Removal of the bridge before converting all data may mix two-digit dates with four-digit dates.
Data duplexing is a method geared toward database Y2K problems. In essence, duplexing creates two versions of a database—one with the original two-digit format and the other with the four-digit format. This strategy is very complicated and expensive. Like date field expansion, it requires at least 36 months to implement.
Object-code data interception is prevalent in IBM mainframe systems, but is still experimental in terms of commercial tools. This technique intercepts dates in executable object code. Data interception works for explicit dates, but not for hidden or obscure dates as in serial number encapsulation. It is by far the fastest technique, but will probably be very ineffective due to so many obscure and embedded dates.
Rather than using external software tools, fixes, or patches, businesses can replace their entire systems altogether. Companies can easily rid themselves of old, non-compliant systems and obtain Y2K-ready systems. Despite the difficulties of starting from scratch, a business should seriously consider if its current system is either too costly to repair, or if it has too many systems to fix. A company may also choose to merge with another company that is already Y2K compliant.
The final strategy for conquering the Y2K problem is the do-nothing approach. This does not entail ignoring the Y2K bug completely, but rather analyzing a company’s systems. Will the bug have a serious impact or will it just pose a minor threat? Programmers can appropriately work around the problem areas. This approach can prove to be very cost-effective.
Related Date Problems
Hands down, the Y2K problem is one of the greatest challenges to face businesses and programmers. However, the simple tick of the second hand on December 31, 1999 at 11:59:59 p.m. is not the only trouble for software applications. There are other date problems very closely related to the Y2K bug that nay affect software. Among these are the GPS roll-over date problem, the commodities switch to the Euro currency, the end-of-files problem, and the Y2K leap-year problem. These problems combined can top $5 trillion on modifications to over 60 million applications in the next 50 ears4.
January 1, 1999 marks the start of the Euro currency era. The movement towards the unified currency runs through calendar year 2002. There are two particular date problems associated with the Euro. The problem lies in the timing of the Euro introduction. "The timing of the Euro is one of the world’s worst public policy decisions in human history because it pits the world’s second largest software project (the Euro) against the world’s largest software project (the year 2000)."4 There is neither enough software personnel nor time to accomplish both projects, which will undoubtedly lead to major economic problems. The second problem concerns the impact of the change to the Euro on software and data mining. Programmers must modify thousands of software applications, along with databases, and data warehouse and data mining operations to handle the change from older currencies to the Euro. The Euro will also pose problems for on-line analytical processing, and long-term trend analyses spanning the pre-Euro and post-Euro periods.
August 21, 1999 is the scheduled date of GPS rollover. GPS, or Global Positioning Satellites, will reset their week counters to 0000 after the 1023rd week since January 5, 1980. Twenty-four such satellites will reset at midnight, and will continue to do so every 1023 weeks. Missing the rollover may prove disastrous as major international funds transfers rely on GPS dates. The GPS roll-over date is a precursor to the more serious Y2K problem. Applications using GPS signals must be tested for the GPS rollover and the Y2K problem almost simultaneously.
The end-of-files date problems refer to the way in which some software applications indicate the end of a file’s validity. Most applications use 9999 to indicate the end of a file’s lifetime. Although not intended to be an actual date, computers may interpret 9999 as September 9, 1999. Likewise in UNIX, 999,999,999 indicates end of files. This number can be interpreted as September 8, 2001. Such misinterpretations of these end-of-file indicators can prove erroneous in related calculations.
The year 2000 is a leap year. There are three rules that determine if a year is a leap year--the third of which is quite rare. First, years divisible by four are leap years. Second, years divisible by 100 are not leap years. Finally, years divisible by 400 years are leap years. The year 2000 is a leap year by virtue of the first and third rules. The third rule, due to its rarity, would otherwise render the year 2000 a normal year. Because the year 2000 is not a "typical" leap year, it is likely to be missed by certain software applications that only define leap years by the first and second rules. Although most legacy systems may make it past December of 1999, they may fail in February of 2000.
The Impact of The Y2K Problem
With all that has been said of the Y2K problem and its other related date problems, we now take a look at what makes the Y2K problem such a unique challenge. To begin with, to say that the Y2K bug is a vast problem is an understatement. It is a global phenomenon. Any and all businesses or individuals around the world that rely on computers must pull together to defeat this common enemy. Although the problem of expensive memory is no longer a major concern, modern computers nonetheless have inherited the two-digit format of the mainframe era. After all, workstations and personal computers proliferated to augment legacy systems and their data. The Y2K bug affects hardware, embedded firmware, languages and compilers, and operating systems. In telecommunications, the Y2K bug affects telephone systems, electronic data interchange, private branch exchanges, and others. Embedded systems found in elevators, ATMs, and traffic signals are also subject to failure on January 1, 2000. Despite the fact that only 5% of embedded chips are date-sensitive, there will be 25 million chips in operation by the turn of the century12. Virtually anything that uses dated information is at risk.
The Y2K problem is also unprecedented. First, it has a non-negotiable deadline and is common to everyone. For that matter, there will be high demand for experienced COBOL programmers and other legacy related resources in the next 20 months. Second, it affects every system with external interfaces. It is, therefore, vital to conduct tests of root programs and interfaces simultaneously. Third, the Y2K problem falls out of the typical maintenance description. Rather than "’Here’s the problem, fix it’--the reaction to the Y2K problem is ‘Where is the problem and what are the fixes?’".2
The costs of Y2K fixes are almost ludicrous. The Gartner Group estimates that the cost of one line of code could reach $2.00. Capers Jones, a bona fide software costs expert, predicts the total worldwide costs of fixing the bug at $1.635 trillion5! Despite these staggering figures, they are indeed inevitable and necessary if businesses wish to survive.
Let us now digress for a moment from businesses. How does the Y2K bug affect the normal individual? You may think that you are immune to the bug because it is mostly a business oriented problem. Quite to the contrary, the Y2K problem has a very significant effect on our everyday lives. The key word to remember is date. Anything remotely related to dates has the potential to affect us in one way or another.
The Y2K bug definitely affects your investments. You should know how your stock and bond firms are dealing with the Y2K problem. According to a 1997 survey of 6,000 worldwide companies by the Gartner Group, 30% of companies hadn’t even begun to take action against the Y2K bug. A sentiment from Cathleen Judge of Ballard Spahr Andrews & Ingersoll best describes the attitude that investment holders should adopt concerning this situation. "I want my retirement money invested in companies that are moving swiftly to become Y2K compliant, because they’re going to eat the lunch of companies who aren’t".6 This is very true. It’s a dog-eat-dog world out there and the Y2K problem is a case of survival of the fittest.
How much are companies spending to make their systems Y2K compliant? The Standish Group International, a consulting firm, predicts that U.S. companies will spend $440 billion on Y2K repairs--33% of which will be spent in 1998 and 53% in 19996. Prudential Insurance will spend $110 million for Y2K compliance. Federal Express will shell out just $75 million compared to the whopping $250 million by Chase Manhattan7. Some of the companies that have an edge on the competition include the banks BankBoston and First Union. Other companies are fixing their bugs by all means necessary. For example, Carolina Power and Light employs skilled, low-cost programmers from India to do much of its conversion. Rite Aid assigned a full-time staff of 80 programmers to deal with its problems three years ago. The millennium bug will hit certain industries the hardest. The Gartner Group recommends that investors look out for pharmaceuticals, semiconductors, construction, community banks, and credit unions6.
Your broker and mutual funds are also susceptible to the Y2K bug. A survey of 3,200 financial services in November of 1997 by Securities Industry Association reported that 77% of large firms were fixing their systems. In contrast, only 33% of smaller companies were doing the same7. Charles Schwab has dedicated 225 programmers to complete its fixes by the end of 1998. Merrill Lynch expects its total Y2K costs to reach $300 million.
Your bank or credit union is also very vulnerable to the Y2K bug. There are approximately 10,000 banks in the U.S. The likelihood that all banks will eliminate their bugs is so small that the Federal Reserve has developed a contingency plan to help banks that will suffer by the turn of the century. According to federal regulators, 9% of all community banks (which possess 15% of U.S. bank assets) are either doing nothing or just now starting to alleviate their Y2K problems8. As for credit unions, which hold $345 billion in assets, the U.S. General Accounting Office feels that their attitude towards Y2K fixes is more or less one of indifference. Even if all U.S. banks solve their Y2K problem, they are still vulnerable to the insufficiencies of foreign banks, which are even further behind. For that matter, Yardeni strongly believes in a 40% probability of a recession occurring in 20003.
Depending on the credit card, your purchases may or may not be affected by the Y2K bug. MasterCard and Visa are confident that their cards will be accepted at the 14 million terminals worldwide. American Express, on the other hand, has not yet released any cards with expiration dates past 1999 until they’re confident that all terminals are Y2K ready. While on the subject, credit cards have already been known to be responsible for pre-year 2000 glitches. At a food market in Warren, Michigan, the store’s ten computerized cash machines crashed due to a credit card bearing a year 2000 expiration date. Experts suggest that if you do have a card with a 2000 expiration date, bring a card with an expiration of 1999 or earlier just in case you encounter a non-compliant terminal.
Surprisingly, your social security benefits should not be influenced by the millennium bug. The reason for this is that the Social Security Agency began their Y2K program back in 1993. A report card on Y2K progress by the U.S. House Subcommittee on Government Management, Information, and Technology gave the SSA an ‘A’. In contrast, the IRS received a ‘D’. Unfortunately, Medicare benefits are at a higher risk of mishaps. According to the GAO, the May 1997 progress report of the Department of Health and Human Services did not assess how much renovation was needed to process the nation’s $200 billion in annual Medicare claims9.
The millennium bug also affects your taxes. Even if the bug incapacitates IRS computers (surely a dream come true for us all), we’re still expected to pay our taxes and any applicable interest. To prevent your refund from going down the Y2K tubes, calculate your 1999 tax withholdings as close as possible to what you’ll owe10.
Will the Y2K bug affect your personal computer? Supposedly, all Apple Macintoshes and PCs after 1995 are ready for Y2K. However, a May 1997 purchase of 30 Pentium laptops by the Department of Defense revealed that 12 chips failed the Y2K test12. To test if your PC is Y2K compliant, set the system clock to 11:58 p.m., December 31, 1999 and shut off the computer. Wait several minutes and reboot the machine. If it retains the correct 2000 date and time, then the computer is indeed Y2K compliant.
The millennium bug may also invade the privacy of your own home. Any date-sensitive appliance or electronic device is susceptible to date-change problems. In particular, your VCR may record the wrong program set on January 1, 2000. By fooling the VCR into thinking it is 1972 (via the 28-year shift of the encapsulation technique), you can ensure that the VCR will record the correct program. Most devices will still work, but will generate erroneous dates. Unless dated information is of no importance, then the replacement of non-compliant equipment such as fax machines is a necessity.
Legal Implications
As in any crisis, there is always the threat of legal implications. With the ominous approach of January 1, 2000, litigation will dictate who should be responsible for the problem, and more importantly, who should shoulder the costs. "Once the millennium bug infects the world, it would be nice to blame the destruction on God".11 Unfortunately, the Y2K problem is a known bug and thus cannot be considered an Act of God or Force Majeure. In regards to Y2K litigation, the obvious defendants will be vendors or licensers of Y2K systems and software. Steven Brower, a former programmer and litigator with over 15 years of experience, believes that there are other significant defense candidates. Among these are Y2K consultants and solution providers, corporate directors and offices, and Y2K "certification" entities.
Y2K consultants and solution providers include a group of entities that provide software solutions and assistance with Y2K problems. Solution providers also encompass outside third party vendors and employees within a company assigned to deal with Y2K issues. Copyright infringement is likely to arise when such third parties or employees attempt to modify licensed software. The license agreement or maintenance agreement may or may not permit licensees to make modifications on a licenser’s product. In the event that the agreement makes no mention of such modifications or outrightly prohibits it, and the licensees nonetheless perform the modifications, the licensee is at risk of violating the licenser’s right to derivative works under 17 U.S.C. Section 16. As defined under 17 U.S.C. Section 101, a derivative work includes "a work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship".13
With time working against them, plus the new difficulties of copyright issues, consultant and solution providers face a dilemma. Although most licensers are willing to provide Y2K compliant upgrades, release dates are uncertain. Many licensees feel that in light of their own time windows of failure, waiting for a Y2K update is unacceptable. They would rather use IT personnel or outside third parties to implement their fixes. As a solution provider, an organization must determine whether they or their clients have the right to modify licensed software. Furthermore, it is necessary to determine if that client even has the right to hire an outside vendor at all.
If licensees do undertake modification of products against the license agreement, they should be prepared for possible litigation. There are certain steps that licensees can take to avoid that possibility. First, licensees should review if license and maintenance agreements do indeed allow for modifications. If outside vendors are involved in the software modifications, licensees should be wary that the third party doesn’t run afoul of contractual provisions. If the agreement explicitly prohibits modification, then the licensee should obtain the licenser’s permission. Finally, if the original developer fails to provide fixes of upgrades, the licensee should seriously contemplate seeking copyright counsel.
There are three defenses available to licensees. The first defense is of the fair use doctrine. 17 U.S.C. Section 107 defines fair use as: (a) the purpose and character of the copyright, including commercial or nonprofit educational use, (b) the nature of the copyrighted work, (c) the amount and substantiality of the portion used in relation to the work as a whole, and (d) the effect of the use upon the potential market for or value of the work13. The decision of the doctrine by its four arguments are split in regards to the licensee. Whereas the second and fourth arguments benefit the licensee, the first and third arguments actually do more harm than good. The second argument considers software a creative work, thus deserving protection. The fourth argument also protects the licensee because its modifications would not impair the demand for the licenser’s software. On the other hand, the first argument harms the licensee because the modification of their software is usually commercially related. Also, the third argument weighs against the licensee because the modified work consists of a substantial piece of the original. On the other hand, the defense of this doctrine is strengthened if the licenser fails to participate in the Y2K fix or if the licensee cannot depend on the Y2K compliant update to meet its time window of failure.
The other two defenses to licensees are the first sale and private use doctrines. First sale implies that the author’s rights are exhausted once a copy of the work is sold. To licensees, this means that they have rewarded the original vendor through payment. The licenser no longer has control of the product. Private use allows purchasers to use software in any manner to satisfy the needs for which it was purchased. However, this doctrine does not extend to modifications made for commercial purposes.
There are yet still other legal ramifications resultant of the Y2K problem. There are contractual liabilities, which include expressed and implied warranties. Tort liability encompasses fraud and misinterpretation, fraud in the inducement, negligent misinterpretation, professional malpractice, negligent design, and strict liability.
According to Brower, directors and officers are also at risk of facing litigation. Actually, anyone involved in corporate management failing to disclose their financial impact is liable. Directors and officers have a fiduciary duty to become Y2K compliant. A breach of these duties can hold a director or officer liable to whomever takes suit--either the shareholders or their own corporation.
Corporate management’s fiduciary duties can be broken down into two components. The first component is the duty of remaining loyal to the interests of the corporation. This issue generally arises when a director or officer uses their stature for personal profit or gain. A breach of this duty is likely to arise in Y2K terms if the director or officer engages in a mixed motive transaction, or misappropriates confidential information concerning the company’s Y2K plan. The other component of fiduciary duties is the duty of due care. In essence, duty of due care calls for directors and officers to take extreme care during the course of their duties on behalf of the corporation. In the midst of the Y2K problem, a director or officer can be personally liable for the damage to their corporation’s net worth if their negligence resulted in a decline of the company’s stock value. We now look at two hypothetical situations in which a company’s CEO can be held liable for Y2K damages.
First, a CEO fails to inform a payroll company of inherent Y2K bugs. As a result, the company does not file taxes and it incorrectly computes payroll deductions. The company’s stock plummets $30 a share. You abhor the CEO’s negligence and promptly file a suit of negligence. Corporate management will likely seek defense under the Business Judgment Rule. This rule consists of five elements: (1) a business decision was made (2) by a disinterested decision-maker (3) who exercised due care (4) and good faith, (5) where no abuse of discretion or waste of corporate assets resulted11. Unfortunately for the CEO, ignorance was the cause of the disaster. According to its first part, the Business Judgment Rule is only valid in Y2K cases where corporate management made a conscious decision to refrain from implementing a Y2K plan.
In this situation, the shareholder (or whomever files suit) must prove that the CEO was negligent. This would not be the case if the CEO can prove that the Y2K bug was an unforeseeable phenomenon. Warren S. Reid, legal consultant for director and officer liability cases, expresses his belief that "no officer or director will be available to avoid liability for his/her company, after, using a defense of ignorance".11 The reason for this is that the media has hyped up the millennium bug so much. How can anyone involved in corporate management be ignorant of the Y2K problem?
Technology consultants have designated December 31, 1998 as the actual Y2K deadline for the completion of all Y2K safeguard plans. The rationale behind this is that at least one year should be designated for testing systems of any bugs that may still lurk. By this argument, corporate management should ensure that its company is Y2K compliant by December 31, 1998.
This leads us to the second hypothetical situation. Assume now that the CEO waited for technology consulting firms to enter the market and drive prices down. The CEO waits until the summer of 1998 to take action by which time the company was able to save $25 million. Unfortunately, since the CEO waited so long, the company did not complete its fixes in time and the company lost $25 million in shares--equal to what the CEO saved the company to begin with. Is the CEO liable? It is quite difficult to pass judgment on this case. The CEO made a conscious decision on good faith to save the company money. There was also no net waste of assets (since the CEO broke even). Variations in interpretation of the Business Judgment Rule will affect the legal decision in this scenario.
Year 2000 "certification" entities also cannot avoid the black hole of litigation. The risk of liability through certification can come from two sources. One way is by the purchase of a product from an allegedly "certified" entity. Organizations that offer Y2K certification often have inadequate certification criteria. Once such organization never even inspects the products or tools of a particular solution provider. Rather, it only takes into account the provider’s processes and methods in delivering the product to the customer.
A vendor seeking certification may also increase its chances of liability in two aspects. First of all, a court could find that a "certification" implies an expressed warranty. Therefore, the vendor can be liable for failures beyond those contemplated by the vendor’s counsel. Secondly, programming is not a licensed profession. A court could find entities possessing certification of software methodology "voluntarily" assuming a "professional" obligation. Thus, a certified vendor may be liable for malpractice.
We now look at the entities most susceptible of all to litigation--vendors of computer systems and software. It may appear that only those vendors who market non-Y2K compliant products will be victims of litigation. The truth of the matter is that even vendors of Y2K compliant systems and software are also liable. Many late-starters will not have sufficient time for planning, investigation, and testing of Y2K compliant products. The vendors of these products should therefore recognize they are susceptible to litigation.
Regardless of the type of products that vendors manufacture, they are all still liable for breach of contract, breach of warranty, or fraud. The first line of defense for vendors is clear contractual terms, along with disclosures of the limitations of their products’ performance. If a system needs an upgrade and that upgrade is not free, vendors have a responsibility to notify their customers. Customers are also entitled to know the date of delivery and costs of the upgrade. Some vendors will object to such disclosures, since competitors having similar problems aren’t disclosing similar information. Of course, it all depends on how much vendors are willing to avoid the possibility of litigation.
Vendors should have an obligation to make systems Y2K compliant under existing warranties or agreements. Depending on the agreement, vendors may have the option of charging more for a new version, with new functionality. It does seem odd though, that to keep a system running into 2000 would be considered a new functionality. As an example, Milberg Weiss Bershad Hynes & Lerach LLP filed a suit against Macola Software Inc. in April of 1998. "In contrast to many other software companies, which are correcting year 2000 problems and providing those corrections free of charge... Macola is improperly requiring its customers to pay substantial fees to purchase upgrades..."14, reported one of the firm’s documents. Furthermore, the changing of dates is neither an Act of God nor Force Majeure beyond the control of the vendor. Rightfully, the vendor should provide customers supports of its products well into 2000.
Even if a customer’s warranty has expired, a vendor is still liable for damages. Just because a warranty expired, and the customer chose not to pay for maintenance, a vendor still has an obligation to that customer. Most warranties last for a certain period, say 90 days or one year. However, the statues of limitation for fraud can last for several years. In 1998, litigation is possible by customers who purchased products as early as 1994.
With all the parties liable for Y2K litigation presented, can these parties insure themselves in some way? The answer is "yes". First-party insurance can cover "your" costs for the Y2K problem. There is also third-party insurance, the most obvious being Directors & Officers Liability insurance. Computer Errors & Omissions insurance, commonly known as computer malpractice insurance, is also available to vendors. As a matter of fact, insurance firms such as Marsh & McClennan Co., American International Group Inc., and Lloyd’s of London provide policies specifically for Y2K troubles15. Coverage includes several categories including direct business interruption, or loss of profits as a result of failed Y2K conversions; costs incurred from unsuccessful conversion of clients’ computer systems; and third party liability--a company’s liability as a result of a third party’s conversion efforts.
It is no wonder then that as the year 2000 approaches, programmers who can fix the millennium bug will be in high demand. Companies now are in a bidding war for the most skillful of these programmers. To be successful, companies need to recognize and take advantage of certain factors. First, a company must realize that a programmer who completes the job is more valuable than the programmer who leaves partially through the project. Second, the demand for skilled professionals will continue to increase over the next three years. Third, this demand has a finite life. Fourth, the sooner a programmer accomplishes the job, the sooner the programmer can move on to another company in need of services. Fifth, programmers who tackle the most sensitive of year 2000 concerns have access to confidential or proprietary information. Finally, the compensation packages of these programmers must somewhat reflect those of the other employees. These are just some reminders in successfully hiring the staff necessary for a company’s Y2K conversions.
Conclusion
The year 2000 problem is a serious issue. It is true that computer networks span the globe. For that reason, the Y2K bug has easily become a worldwide threat to businesses and individuals. It will be interesting to see what kinds of changes and events will occur around the turn of the millennium. There is a mad scramble to make computer systems and software Y2K-compliant. For those businesses who started their fixes early, the year 2000 will be a much anticipated event. For others, it will be a dismal day. From a business perspective, the Y2K bug is another piece of the cat-and-mouse game that companies participate in. The company that solves its problems first remain a step ahead of the competition. From an individual’s perspective, those who rely on the services of companies dealing with the Y2K problem certainly have cause for concern. Otherwise, the Y2K bug just poses an inconvenience in their everyday lives.
SOURCES
5 Muirhead-Gould, John, "A Term Paper on the Year 2000 Computer Problem" Available online http://pages.sssnet.com/jsmg/termpaper.html (4/10/98).
6 "Your Investments" Don't Get Stung by The Year 2000 Bug. Available online
8 "Your Bank or Credit Union" Don't Get Stung by The Year 2000 Bug.
Available online http://www.pathfinder.com/money/y2k/three.html (4/10/98).
11 Stuhlmiller, Mark J., "Can You Hear The Lawyers Singing 'We're Gonna Party Like It's 1999'?" Available online http://www.year2000.com/archive/lawparty.html (4/10/98).
12 "Your Computer" Don't Get Stung by The Year 2000 Bug. Available online
http://www.pathfinder.com/money/y2k/eight.html (4/10/98).
14 Taft, Darryl K., "LERACH'S SUIT: Wants Macola to Upgrade Customers at No Charge-Software Vendor Sued Over Year 2000" Computer Reseller News. April 6, 1998. Available online http://www.techweb.com/se/directlink.cgi?CRN19980406S0157 (4/10/98).
15 Granahan, Thomas, "Insurers Offer Policies to Cover Year 2000 Bug" BusinessToday.com. April 5, 1998. Available online http://www.businesstoday.com/techpages/y2k04.htm (4/10/98).
