Logic bombs, Part 3
- 17 September, 2002 09:17
Today's software is often provided by external suppliers. Individual contractors and small software firms play an important role in creating systems especially designed to support the essential operations of countless organizations. Larger firms provide commercial off-the-shelf software to millions of users.
In online discussions, I have read communications from several consultants who brazenly admitted that they always leave secret time bombs in their software until they receive the final payment. They seemed to think that this strategy is a legitimate bargaining chip in their relationships with their customers.
In the movie "Single White Female," the protagonist is a computer programmer who works in the fashion industry. She designs a new graphics program that helps designers visualize their new styles and sells it to a sleazy company owner who tries to seduce her. When she rejects his advances, he fires her without paying her final invoice. However, the programmer has left a time bomb that explodes shortly thereafter, wiping out all the owner's data. This is represented in the movie as an admirable act.
In reality, such tricks can land software suppliers in court.
In 1988, a software firm contracted with an Oklahoma trucking firm to write them an application system. Some time later, the two parties disagreed over the quality of the work. The client withheld payment, demanding that certain bugs be fixed. The vendor threatened to detonate a logic bomb that had been implanted in the programs some time before the dispute unless the client paid its invoices. The client petitioned the court for an injunction to prevent the detonation and won its case on the following grounds:
* The bomb was a surprise; there was no prior agreement by the client to such a device.
* The potential damage to the client was far greater than the damage to the vendor.
* The client would probably win its case denying that it owed the vendor any additional payments.
I urge all programmers and contractors to stay away from these dishonest practices. More practically, I urge all clients of software contractors to be sure that their contracts explicitly bar any such mechanism for retaliation. The correct approach to avoiding this kind of fracas is to choose contractors with good reputations and to keep the lines of communication open at all times so that problems don't escalate into warfare, covert or overt. It's much better to pay lawyers to prevent lawsuits than it is to pay them to fight them.
In the last of these four articles, I'll discuss renewable, time-limited licenses for commercial software.