Time Bombs, Stop Devices and Other Stuff

What are the legalities of such code?

By Paul Goodman, Esq., P.A.S., New York, New York

Case in point. Bob Bytes, a custom business software developer accepts a project from Wonder Widget, a local widget brokerage, for the development of an integrated accounting package. Since both parties were in a hurry to get started, neither took the time to memorialize their agreement in writing, but there was an oral agreement that Bob would be paid $3,500 per month for the development which was projected by Bob to take four months. Unfortunately, due to circumstance unforeseen by either Bob or Wonder Widget, the project dragged on for three additional months and then for three more without a definitive end in sight. After ten months, Wonder Widget started to object to the increased development time and costs and started to blame Bob for the problems. Bob, on the other hand, blamed Wonder Widget for constantly changing the program specifications.

After Wonder Widget delayed in paying several of Bob’s weekly invoices, Bob became nervous and thought of an idea to help assure payment of his fee should their relationship fall apart. Bob planted into the software a few conditional statements which locked up the software at a predetermined date. Since Bob had never supplied any source code to Wonder Widget, and Wonder Widget had never requested it, Bob had Wonder Widget just where he wanted them. If they wanted to use the software and access to their data, they would have to pay Bob just what he wanted and thought he deserved. Without the source code, Wonder Widget had little that they could do but to pay Bob.

Let’s look at another possible ending to the story. Instead of paying Bob, Wonder Widget decides to make a stand. They hire a lawyer who brings a law suit against Bob charging breach of contract and intentional interference by Bob with Wonder Widget’s property, that is, its data which was now inaccessible. They also ask for punitive damages. To make matters worse, Wonder Widget’s lawyer brings a motion for an injunction requiring that Bob immediately remove the software stop he has placed into the software until the court can make a final determination on the law suit.

Most programmers will recognize this scenario as one they have either thought about themselves or heard about from other programmers. However, we are sure that there would be quite a bit of disagreement in the programming community about whether or not Bob had the right to place the preprogrammed stop into the software and what the outcome of the law suit would be. In this article, we will look at several scenarios involving attempts by programmers to use time locks or other similar code to help protect what they perceive to be their rights and review the possible legal consequences of these actions.

Wonder Widget v. Bob Bytes

As you’ve seen, Wonder Widgets has sued Bob for breach of the software development contract and for interfering with its data. They also asked the court to issue an injunction forcing Bob to remove the time lock so that they can use the software prior to the final decision in the lawsuit. Bob would undoubtedly counter-sue for the additional programming fees he felt that he was entitled to.

What would happen in this case? What would each side claim and who would prevail in the end? Unfortunately for the programming community, this issue is so new that the court’s have provided little or no guidance to follow. Let’s look at what each party might perceive as their rights and which positions might hold up in court.

Bob Bytes would probably claim that he is entitled to shut down the software since he has not been paid his entire development fee and therefore, the software would still be his. He would also probably analogize the situation to the repossession of a car when the purchaser fails to make their car loan payments on time. Finally, given the original fact pattern, since there was no written agreement between the parties, Bob might emphasis what may be a valid claim to the copyright in the software.

As you might expect, Wonder Widgets might see things a little differently. They would claim that the software was merely the subject of a disagreement over the final development fee, a dispute that should be settled in court. Since they had already paid an overwhelming proportion of the fee to Bob, he had no right to prevent there use of the software. They would also claim that this was very much unlike the repossession of a car since because in that situation, the bank would have both a contractual and statutory right under the Uniform Commercial Code to repossess both of which were absent in this case. Finally, if Wonder Widgets had a smart lawyer, she might point out that not only has Bob Bytes shut off the software, he has also denied Wonder Widgets access to its data and thus, jeopardizing the continuity of its business.

What would be the outcome? To the surprise and possibly, the chagrin of programmer’s everywhere, a court would probably find in Wonder Widget’s favor and possibly order the immediate removal of the time lock. We say probably because, as already mentioned, there is very little legal precedence for judges to rely upon and, as you probably, suspect, the courts have had very little experience in understanding and dealing with computer-related issues. Let’s look at this in some more detail. While Bob Bytes might eventually prevail on at least some of the contract issues (payment for the work he performed), he might be found liable for any damage he caused to Wonder Widget’s business. An enlightened judge might also issue an injunction requiring the programmer to remove the time lock until the ultimate issues in the law suit are decided. This is because what legal precedent does exist seems to suggest that programmers do not have a right to self help remedies such as time locks unless that right is spelled out in an agreement between the parties. This is based upon several factors maybe the most significant of which is that the hiring party, who has been led to rely upon the use of the software to operate their business, will sustain far greater damage from the shutting down of the software than the programmer will, since the programmer would have a so-called “adequate remedy at law” in the form of a breach of contract law suit. In addition, the fact that a significant portion of the development fee had already been paid might lead to a finding that the contracting party is entitled to receive value for that payment in the form of the use of the software. This would be true even if the programmer is found to own the copyright in the software, since the courts have regularly found that even in the absence of a written contract, a party who hires a programmer and pays the development fee (or at least significant portion thereof) will have an implied legal right to a non-exclusive license to use the software. Since Wonder Works would be found to have a right to use the software, the court’s would most likely find that the shutting down of the software would be in violation of that right.

Taking all this all into account, what should the programmer who wants to use a locking device to enforce their right to payment do? Here are some guidelines. First and most importantly, have a written agreement with your client disclosing the existence of the time lock. Next, make sure that in the event that the software is shut down, the user will have the ability to access and use their own data. Also, avoid inserting any device or activating it over telephone lines. Finally, make sure that any locking device is activated only in good faith and in response to a dispute where the rights are clearly in your favor.

Commercial Development Situations

Let’s explore this issue some more by changing the fact pattern a little. Let’s say that Bob Byte’s client is not Wonder Widgets but rather is, So-So SoftWorks, a software publishing company. So-So has contracted with Bob for the development of a software product to be published on a commercial basis. Bob is being paid for the work on a flat fee basis, with the total development fee being paid over a series of milestone payments. Since Bob had trouble collecting some of the milestone payments on a timely basis, he has inserted a time-based locking device into the software with the goal of preventing publishing of the software should he not be paid.

Is this situation any different that the other where Bob was doing custom development work for a commercial software publishing customer (of course, differences in the two situations can be easily found, the question really is, are they legally significant)? The key question really is, assuming that Bob completes the development but does not get paid the final portions of the development fee, would Bob be liable for any damages sustained by So-So if they could not publish the software due to the time lock? The answer to this question is even more unclear than the previous one and the courts have provided even less guidance. While the automatic activation of the lock would not deprive So-So of access to any of its data (as was the case in the Wonder Works situation), it would prevent So-So from publishing the software. In addition, So-So may have already paid a significant amount of the development fee for the software. Thus, this situation leads itself to the same type of analysis as the previous example. That is, the programmer is using a “self-help” remedy to enforce his perceived contractual rights and the commissioning party having rights to at least part of the software by virtue of having paid for (at least part of) the development.

As with the previous situation, if the contract between the parties permits the programmer to lock the software in the event of non-payment, then the programmer would have a strong basis to support his or her claim to the right to shut down the software. If So-So claimed an offset against the final portions of the development fee, rather than just arbitrarily refusing to pay, Bob’s case would be somewhat weaker. A programmer might have a basis to support this claim (although a somewhat weaker one) if the contract conditioned any assignment of rights to full payment. Although, if the shut down of the software occurred prior to the completion of the final version of the software, such a contract condition might not apply. Absent of any type of contractual right to place a locking device in the software, a programmer might be treading on thin ice. If you are a programmer in this type of situation you should think carefully before proceeding. In the event that the software is shut down prior to it’s duplication and publication by the publisher, the damages would be rather limited, that is, those costs associated with missing the shipping date for the software. However, if the shut down occurred after the software was duplicated and sold, damages to the publisher could be substantial including the cost of a total recall of the software and the damage down to the publisher’s business reputation with its distributors and end users.

Publishing Situations

A third possible situation is that of the software publisher who purposely has a locking device placed into their commercially distributed software in order to enforce their rights against the end users. There are several possible situations. One is the publisher who distributes a time-limited demonstration version of their software. This is a version which will fully function, but only for a set period of time afterwards it will lock up. A second is the publisher who sells software which requires a key to activate the full version of the software. Finally, there is the publisher who sells software based upon a periodic (such as an annual) license and equips the software with a locking device which automatically activates unless the licensee/purchaser pays the annual fee and obtains a password to unlock the software. The key (no pun intended) to any of these arrangements is that the end user is made aware of their existence so that they can reasonably anticipate when the software will stop working. In the case of demonstration versions, the time limitations on the software should be made well known to the user during system start-up and in the documentation. A warning displayed starting a few days prior to the software shut-down would also be a good idea. If you sell your software pursuant to a yearly licensing arrangement, make sure that the user who wishes to timely renew the license, is warned far in advance of the shut down, can renew promptly and is not inconvenienced in any fashion while trying to renew. Finally, make sure that the end user can access any data credited via other means, so that a denial of the use of the software does not also deny use of their proprietary data. Following these guidelines should help defeat any claim brought by a disgruntled end user.

In Summary

Like many other areas of computer law, the rights of a programmer to deny usage of a software package through the use of a programming device is highly unsettled. While the legal opinions expressed in this article are to some degree speculations, they are all educated opinions based on reliance upon existing legal precedence from similar or related areas of the law. It was our goal in writing this article to present sufficient information to make the programmer who is considering employing a time lock or similar device to make an educated decision before doing so or to convince them to seek expert advice beforehand. After representing programmers for over seven years, we understand that many programmers have strong opinions on this issue (as well as many others) and feel that it is their inalienable right to use a time lock. However, as has been stated, this may not be the case. Therefore, we hope that this article will help you evaluate your rights and the potential liability for improper action. As always, just as your clients hire you to provide expertise that they don’t have, don’t hesitate to hire expert legal advice when you are unsure of the potential consequences of your actions.