Managing Your Intellectual Property In The Year 2000

By Steven D. Hemminger And Lynn Y. Mckernan

The Year 2000 problem, also referred to as the 'millennium bug', or, by those who prefer acronyms, the 'Y2K' problem, is big news these days. Basically, it is the result of a method of saving memory in a computer that effectively prevents computers from accurately calculating time when years beyond 1999 are involved.

Generally, the problem exists because in the days when mainframes ruled, i.e., in the late 1950's and early 1960's, memory was expensive and limited. Code was written to save space, so the date field in many programs omitted the century portion. Thus, for example, the year 1998 was coded as '98'. Consequently, when January 1, 2000 arrives, most computers will roll over to Year '00', which may be treated as Year 1900 for arithmetic purposes.

Mainframes, however, are not the only computers that may be affected. For example, certain chips were developed that cannot properly process the Year 2000; there are reports that a large number of PCs incorporate such chips. Basically, any computer system that relies on date calculations should be tested for Year 2000 compliance.

WHAT IS THE BIG DEAL ABOUT FIXING THE PROBLEM?

Even though the Year 2000 problem may sound simple to correct, in reality it is extraordinarily difficult, labor intensive and time consuming to fix. Programmers in many instances have to search the computer code line by line to find date code. In some programs, this can mean looking at software that has millions of lines of code.

There are several reasons for the complexity of the problem. For example, older code did not always follow structured design and modern language coding standards. Additionally, older code may use outdated and/or unsupported compilers. Too, older code may include special patches that are platform dependent. To compound the complications, many companies may not even have the original source code.

Additionally, early programmers were not necessarily known for their code commenting. Either they were never trained to comment properly, they did not have the time to do so under the constraints of tight product delivery dates, or they found that their lack of commenting provided them job security. (If nobody but they could decipher their code, the assumption was that the company had to keep them around in case the code needed to be fixed, upgraded and/or enhanced.)

Thus, because of the vagaries in many software programs that need to be rendered Year 2000 compliant, there just is no technical 'silver bullet' to fix the problems. There are so many computer languages and there has been so much customization of software over the years that no single solution exists.

IF YOU ARE A 'USER', WHAT ISSUES ARE INVOLVED IN YOUR YEAR 2000 COMPLIANCE EFFORT AND WHAT SHOULD YOU DO?

WHAT'S THE FIRST STEP?
First, you should identify all your software and hardware licensors and vendors and immediately notify them in writing of your concern over your Year 2000 problem exposure.

Then, you should undertake a comprehensive inventory of all hardware and software in use. You should collect copies of all licenses and other system-related agreements, as well as documents reflecting representations that were made when those agreements were signed. These documents should be audited by an IP lawyer to analyze your rights vis-à-vis your software, hardware and service vendors. The audit should include a legal analysis of each agreement, including the scope of any warranties, representations, limitations on liability and other provisions made therein or in regards thereto. Depending on what the agreements say and what representations were made, your vendors may be obligated to participate in your Year 2000 conversion effort and/or help defray the costs. On the other hand, it may be your problem.

WARRANTIES IN YOUR SALES/LICENSE AGREEMENTS
To determine the scope of the warranties accompanying any of your software or hardware transactions, it is important to review all transaction documents, product manuals and sales and marketing materials attending the sale and/or license of the software/hardware. For example, a sales piece which states that 'This product will take you into the next century', may very well be treated as an express warranty that the product is Year 2000 compliant. (However, a corresponding disclaimer may accompany this 'puffery' which makes it clear that such statements are not assurances of the quality of the product, and are not part of the sales contract.)

In your audit, care should be taken to look at your annual maintenance agreement. It is possible that within the last few years your vendor modified the language to expressly exclude the Year 2000. Also, carefully review all new maintenance agreements to make sure such limiting language is not included.

While many people refer to the Year 2000 problem as the 'millennium bug' don't assume that your vendor will agree that it is a 'bug' and that it is responsible for fixing it under the 'bug fix' clause of your license or product agreement. After all, the use of two digits for the date was not an error when the software or hardware was created; it was intentional and the system is performing as intended.

Still other vendors may disclaim liability for providing Year 2000 upgrades at no additional cost under the maintenance agreements, arguing that the Year 2000 problem was well-known in the computer industry and constitutes an 'assumed risk' of the customer. The failure to at least ask your vendor in writing to make its products Year 2000 compliant, however, may constitute a waiver by you of your right to later seek reimbursement for the costs incurred in making the changes yourself.

WHAT ELSE SHOULD YOU BE DOING?
If you are one of the 'lucky ones' and your vendor actually assures you of a product's Year 2000 compliance, get it in writing. Moreover, be somewhat skeptical of broad vendor claims that its products are Year 2000 compliant. Recently, companies have publicly announced full confidence in their products, only to later retract those statements upon further testing.

Once your company ascertains what needs to be fixed to remain operational, it must make the decision to replace, repair or modify the relevant systems. Responsible management should compare the cost of possible system upgrades with the cost of Year 2000 compliance repair.

Your company should also provide for some contingencies at known 'drop dead' dates to enable starting on an alternative path if a promising vendor and/or Service Provider (i.e., third party contractor) is unable to deliver for any reason. For example, some vendors may simply choose to go out of business rather than assume the cost of making their product Year 2000 compliant.

If your company purchases and/or licenses new software and hardware products or contracts for software development in the next several years, it should require the vendor to both 'represent' and 'warrant' Year 2000 compliance. In this way, as a customer, you are entitled to both equitable remedies, such as recision of the contract, for breach of the 'representation' and remedies at law, such as damages, for the breach of the 'warranty'.

Additionally, for the next several years, all technology-related contracts your company enters into should include sufficient guarantees of Year 2000 compliance so as to leave no ambiguity as to who bears the risk of loss in the event of failure.

SELF HELP MAY BE PART OF YOUR YEAR 2000 SOLUTION
Regardless of how your audit turns out, you may decide that the adage 'if you want something done right, do it yourself' is true for you. However, you must be careful since legally you may not have the 'right' to modify the software to make it Year 2000 compliant.

Moreover, if you decompile object code and/or modify source code when your license prohibits these actions, you can be liable for copyright infringement. The solution, however, is simple. Contact your vendor and ask for permission to modify the software (this also solves the notice problem). It is highly unlikely they will refuse to allow you to make it Year 2000 compliant. If they do, and they also refuse to provide a fix of their own, you must decide whether the potential for a judgment against you in about the Year 2005 is worth the risk of the damage caused by not being Year 2000 compliant.

CONCLUSION

The Year 2000 is coming and it promises to be an event. Companies need to assess their system's Year 2000 compliance and act accordingly. And, as part of any Year 2000 assessment activity, companies should evaluate the intellectual property issues that may result from their activities.


Steven D. Hemminger and Lynn Y. McKernan are partners at Lyon & Lyon, a Los Angeles based intellectual property law firm. Founded in 1901, Lyon & Lyon has over a hundred attorneys in five offices in California and New York.