Security /

Logic bombs, Part 4

By M. E. Kabay
Network World Security Newsletter, 09/11/02

In the first three of this four-part series on logic bombs, we have looked at illegitimate bombs. In this article, I want to draw your attention to software that is sold with a time-limited license (e.g., a year of use).

In a way, a legitimate version of the time bomb is the openly time-limited program. One purchases a yearly license for use of a particular program; at the end of the year, if one has not made arrangements with the vendor, the program times out. That is, it no longer functions. When the license is renewed, the vendor either sends a new copy of the program (source or executable), sends instructions for patching the program (that is, how to perform the necessary modifications directly in the executable code) or dials up the client's system by modem and makes the updates or patches directly.

Such programs are time bombs as long as the license contract clearly specifies that there is a time limit beyond which the program will not function properly. However, a time-limited program can cause major problems if the vendor refuses to update the program to ensure continued correct operations - for example, to run on newer versions of the operating system. Even worse, the vendor may go out of business altogether, leaving the customer in a bind.

My feeling is that if you are paying to have software developed, you should refuse all timeouts. If you do agree to time limits on your use of a program, you should require the source code to be left in escrow with a legal firm or bank with authorization to let you maintain (change) the code if the vendor goes out of business or refuses to continue supporting the code. Don't forget to include the requirement that the vendor indicate the precise compiler version required to produce functional object code identical to what you plan to use.

With these measures in place, perhaps you will be able to keep production stable while you move to a different software suite with proper support.

However, if you are using off-the-shelf software such as utilities, accounting packages and so on, you will probably never get permission to have the source code, in escrow or otherwise. Realistically, if there's no practical alternative, you may have to let the vendor insist on timeouts, provided the terms are made explicit and you know what you're getting into. Personally, when using such code for production, I would be scouting for alternatives all the time to be sure that disappearance of the vendor or removal of the product from the active list does not cripple operations.

In summary, if a vendor's program stops working with a message stating that it has timed out, your software contract must stipulate that your license applies to a certain period of use. If it does not, your vendor is probably contractually obligated to correct the time bomb and allow you to continue using your copy of the program. [Mandatory disclaimer: I am not a lawyer and this is not legal advice. For legal advice consult an attorney with expertise in this area of law who is permitted to practice law in your jurisdiction.]

By now, I hope that readers will be thinking of the well-publicized plans by Microsoft to switch from an unlimited-time license for its software to a system of yearly renewals. Such contracts have been commonplace in the world of mainframe and minicomputers, but the shift will surprise ordinary users who still think they are " buying " a computer program (they aren't).

Although the benefits of this model to the software supplier are evident, clients should evaluate the costs and benefits of putting their critical production at risk by depending on software controlled by supplier who can unilaterally decide to change the costs, features, and even continued availability of an essential tool.

Microsoft's strategy may backfire by pushing some of its customers to alternative operating systems and applications.