Computer Software and Year 2000 Compliance
The turn of the century will be celebrated twice--once in the year 2000, which is actually the last year of the 20th century, and again in 2001, the first year of the 21st century. Many computer systems in use today are not equipped to handle either year. In the 1960's and 70's, when disk space was expensive and processing relatively slow, false economy lead many programmers to designate year dates with two digits rather than four. With lack of foresight, the year 1961 was designed to be recorded in computer software at "61." Now these systems cannot record 2001 as 2001, but will by default calculate it as 1901. In addition to being unable to correctly record year dates, this problem also means that these systems cannot perform calculations (such as for interest owed) when years after the change of the millennium are involved.
Converting Software to Make it "Year 2000 Compliant"
Companies with two-digit software should begin a four-step process to become Year 2000 compliant. First, a high-level inventory should be made of the lines of code in such software. Based on the amount of code, the scope and expense of the conversion to achieve compliance can be estimated. In the second step, an impact analysis should be performed to establish the priority in which particular programs should be corrected. Third, individual programs should be revised and tested for accuracy. Fourth, all revised programs must be run and tested together to ensure that they are compatible with each other before live operations begin.
Revised Software Agreements Are Required
Software agreements should also be Year 2000 compliant. Contracts for new software must provide that the programs will handle years in the new century. This applies not only to regular licenses to use software, but also to agreements covering electronic data to be supplied to the company's host computer system and software to be connected to that system. All of these contracts should comport with the Year 2000 standards recommended by the International Organization for Standardization ("ISO").
Specific types of contracts should contain specific Year 2000 provisions. Agreements for the acquisition of new software should include representations and warranties (backed-up by indemnities) to the effect that "the occurrence in or use by the software on dates on or after January 1, 2000 (the 'Millennial Dates') will not adversely affect the performance of the software with respect to date dependent data, computations, output or other functions (including, without limitation, calculating, computing, and sequencing) and that the software will create, store, generate output data related to or including Millennial Dates without errors or omissions." If the software is not currently Year 2000 compliant but the vendor promises that it will be at some date, the agreement should include a representation and warranty in the future (and indemnity) specifying how and when the program will be made compliant. Specific, objective criteria should be included in the contract. Software maintenance agreements should have similar provisions.
It is common for software vendors to include provisions in their agreements limiting their liability to only the amount paid by the licensee. This provision, however, should be modified to exclude liability for damages resulting from the failure of the software to be Year 2000 compliant. Software agreements should also include a representation and warranty that any modifications made to bring the program software into compliance (as well as any maintenance services) will not corrupt any data or introduce any viruses into the company's network. If the company will hire a special "millennium conversion company" to make the software Year 2000 compliant, the company must first secure from the vendor of the original software a right to obtain and have the conversion company modify the source code for that software. Moreover, there is a potential for problems when different companies provide the conversion and regular maintenance services. In such cases, the contracts should be drafted to protect the company when, as can be expected, the conversion and maintenance companies blame each other if the software does not operate properly.
If a Year 2000 conversion project is managed poorly and implemented unsuccessfully, it has the potential to impact the company's bottom line and subject corporate directors and officers to liability. As "stewards of the company's assets," directors have a responsibility to prepare the company's computer system for the next century. While the general rule is that they cannot be held liable for matters beyond their knowledge or control, this defense many not be available in light of the importance of the Year 2000 compliance. Thus, officers and directors need to be aware of and involved in the software compliance program. In addition, software vendors may face liability if they fail to advise licensees of latent Year 2000 problems in their software.
New Due Diligence Required
Year 2000 compliance is also an issue to be considered in due diligence conducted by any company involved, directly or indirectly, in investing or making loans to businesses with computer systems. Financial advisors in particular may be held liable if they are not aware if a company is not in compliance when making financial recommendations. Year 2000 compliance is also a factor in due diligence to be conducted in connection with mergers or acquisitions of companies using date-sensitive software, as almost all are.
In summary, Year 2000 compliance raises technical, contractual and managerial issues. For a complete solution, the strategies for responding to them must be handled on a coordinated basis.
William A. Tanenbaum is a partner in Rogers & Wells and a member of the Intellectual Property & Technology Law Group in the firm's New York office. Mr.Tanenbaum is the Immediate Past President of the Computer Law Association, an international organization, and is currently the Chairman of the Internet and Online Task Force, international cross-industry task force focusing on the convergence issues. This article is based on an article that will be published in the Fall 1996 issue of IPAsia.
Copyright © 1996 William A. Tanenbaum and Rogers & Wells. All Rights Reserved
This site carries original content from many contributors, and this content and those opinions are of the authors, and do not reflect the opinions of Communication Links, Inc. its contributors or advertisers. We have reproduced them here for public awareness and discussion. We have no control of content on links, or of sites visited after viewing these pages. We do not endorse products, commentary or verify any information found on sites contained in these links.