eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Whats worth almost any price to protect if its the only one you have, but is almost worthless as long as even a single other copy exists? The answer: source code for a critical enterprise application or for firmware in a manufactured product. The corollary: You and your insurance company had better share a common understanding of what protection youve bought, against what hazards, for any source code on which your organization depends.
The risk of losing source code is fundamentally different, in one key way, from the risk to any other asset. If you have multiple copies of a Picasso print and you lose all but one, youve clearly suffered harm. In contrast, if you lose all but one of several copies of your source code … well, you make new backups and go on. No harm.
This has a dangerous implication: If you have multiple copies of your code that you lose in separate events and even one of those events is not your insurers problem, then you might be completely out of luck—if its found that you suffered no harm at all until the last, uninsured copy was lost.
Additional copies of code are created and preserved not for intrinsic value but for their role in reducing the risk of losing the last one. Risk is the language of insurance providers, and risk reduction is what you think youre getting when you write a check for coverage. Its therefore essential that you and your insurance provider sing from the same page. You dont want to suffer the fate of U.K.-based Tektrol, a maker of energy-saving devices for electric motors whose source code all went missing—but whose loss, the court ruled late last month, wont be covered by business-interruption insurance.
No one would say that Tektrol was careless: Its managers stored the code in different forms, including a hard-copy listing, and at different locations. Even so, the combination of a virus attack and a burglary was enough to leave the company with no uncorrupted source code for the firmware in its products.
As noted by the Hon. Mr. Justice Langley, of the Royal Courts of Justice, in London, this left the company unable to do anything but continue to produce “exact replicas of existing machines”—essentially starting from scratch on any further refinements or customizations of those devices.
Executable code is useful, to be sure, but its source code that enables copying of the good parts and easy updating of the changing parts. Tektrol had failed, however, to review the provisions of its business-interruption insurance with an eye toward the kinds of things that can happen to source code. The companys representatives found themselves in court disputing whether a virus writer “deliberately” caused erasure or corruption of data. If so, then the company was not indemnified by its policy—which covered only accidental events or specifically defined perils such as a riot during a labor dispute.
And yes, the court did find that a virus writer “deliberately” causes damage. One could hardly call the damage from a virus an “accident,” and the court held that simple interpretations of simple words are all that one can expect when old language has to enter new territory.
The essential and irreplaceable nature of source code is not a new discovery. For more than 15 years, my office bulletin board has featured a cartoon in which a nondescript fellow in a trench coat and fedora approaches a widow and her children—still standing at the graveside, in the rain—and says, “I realize that this may be an awkward moment, but did he ever happen to mention source code?” Most of the people who wind up in my office are torn between two simultaneous reactions: a chuckle and a wince. Source code inspires that sort of tension in anyone whose livelihood has ever depended on the stuff. If you create value by crafting code, or by managing those who do, you should be part of the process of protecting your organization against its loss or destruction. The Tektrol case is a warning never to take that protection for granted.
Technology Editor Peter Coffee can be reached at [email protected].
To read more Peter Coffee, subscribe to eWEEK magazine.