Time Bomb
Volume Number: 9
Issue Number: 10
Column Tag: Legal Eagles
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
pr eventing 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.