The Curse of the Handshake Deal: Software Edition

We Don’t Need a Written Contract Because We’re Such Good Friends.

Here’s a link to the decision I’m discussing.
Plaintiff, xTomic, is a software developer—and a fairly small one, as is usually the case. Defendants teach others how to carry out certain therapies to treat soft tissue injuries that were developed by Defendants’ founder. Defendants appear to have two separate customer bases: teaching other practitioners and managing soft-tissue injuries for companies. For this reason, Defendants have three different corporate entities: “ART” for the main practitioner business, “ART Corporate Solutions” for the corporate business, and “ART Business Solutions” for the I don’t know what it’s for.¹Defendants must not have either, since they voluntarily dissolved it, presumably during the pendency of the lawsuit. Let’s call these three companies “the ARTs.”
For a long time, xTomic provided IT services for the ARTs. One day—several years ago—the ARTs asked xTomic to develop two computer programs, known as “Admin” and “EPN.” xTomic also provided Defendants with two other programs, called “EHR” and “PMS,” but xTomic intended to market the programs to other healthcare providers. The parties dispute whether EHR and PMS were developed at Defendants’ behest. But this much is clear: whereas Plaintiff provided the source code to Defendants for Admin and EPN, it did not do so voluntarily for EHR and PMS.
There was no written contract for the development of the computer programs. Instead, xTomic continued to invoice the ARTs normally. Some of the invoices’ charges were for development of the programs, others were for “maintenance,” yet others for unrelated IT services. Curiously, all the invoices said at the bottom: “All source code and Images created by xTomic and used by the client become the client’s property when Invoice is paid in full.”
As an aside, it used to be normal for software developers to make money not only from development of enterprise-level software, but also from “maintenance,” which included improvements and fixes to the program, but also hosting and technical support. The amount for maintenance was fixed, regardless of the real amount effort required by the software provider. It was also normal for licensing agreements to make the licensee’s continued right to use the program contingent on staying current with maintenance fees. This is to say: even after you (the licensee) have paid a bundle to license the software, you had to keep paying to keep the license. This was often seen as almost pure profit for the developer, and customers came to hate it.
As an aside to the aside, you might wonder why you need a license to use software. When you buy a (physical) book or a (CD or vinyl) record, you can read or play it however you like, no license required. Software is different because to use it, you must make a copy of it—every time you use it. It resides in storage (e.g., a hard drive) until you need it, but when you run the program, your computer loads the code into memory (e.g., dynamic random access memory chips), so your computer’s processor can actually, well, process it and make it do things. It’s the copying from storage to memory that you need a license for.²Once upon a time, this was just a weird property of computer programs, but with digital content, it’s becoming the norm. Any content you store on your reading device or digital music player has to be processed in the same way. We often don’t know whether we “own” the books and music on our devices, or just license them. Fortunately, we don’t have to pay maintenance fees once we “buy” the book file or music file, but it’s not unheard of to unexpectedly lose one’s right to keep using the file. Yes, this is a footnote to an aside to an aside.

We’re Enemies Now (Stage One): I Want My Stuff Back.

In 2013, the relationship between xTomic and the ARTs “deteriorated.” Did it ever. One of the ARTs’ employees left the ARTs and formed a competing soft-tissue treatment with one of xTomic’s founders. This competing company used a different technique than used by the ARTs. But it would use the exact same computer programs. The ARTs charged into state court and got a temporary order giving them access to the source code of the EHR and PMS programs. The ARTs also sought damages against xTomic and the new company for misappropriation of trade secrets, among many other claims. xTomic and the new company counter-sued. When the dust had settled, the ARTs ended up with nothing except a $1.5 million judgment against it (which was partially overturned).
While that was cratering for the ARTs, xTomic sued the ARTs for copyright infringement in federal court³Because it had to. There’s no such thing as a copyright claim in state court. After some litigation, but before trial, the parties moved the court to resolve two issues: (1) who “owns” the computer programs? and (2) do the ARTs have a license to keep using the computer programs, even though there’s no written contract saying so?
The first question was very easy for the court to answer: xTomic, obviously, owns the software. More precisely, xTomic owns the copyright in the computer programs, which is what we mean when we say “owns the software.” Although the ARTs essentially conceded the point, it must have come as a surprise that they didn’t “own” their own software.
But here’s a stone-cold rule of copyright law. The author of a work initially owns the copyright in the work. In this case, an xTomic employee wrote the source code for the programs, which meant that xTomic (as the employer) was the “author.” Unless the author then transfers the copyright to someone else—in writing⁴While it’s nearly always a good idea to “get it in writing,” it’s usually not an absolute requirement. Contracts, for example, don’t HAVE to be in writing; it’s just a very good idea. But with transfer of copyright, the writing is required.—ownership of the copyright remains with the author. It’s as simple as that.⁵OK, OK, this is law we’re talking about, so of course it’s not always as simple as that, and this is just a relative measure.
And, here, there wasn’t anything in writing that transferred the copyright in the four programs to the ARTs. Well, except for that strange statement at the bottom of xTomic’s invoices. It seemed to imply that, if xTomic wrote the source code, and a client used it and paid for it in full, the source code became “the client’s property.” Why wasn’t that a “writing” that transferred copyright? This statement is, at a minimum, ticklish for xTomic, and under the right circumstances could have been disastrous. But the court here seemed to take at face value xTomic’s contention that the invoices for the development of the four software programs were never paid, so the condition was never triggered.⁶I think another problem might have to do with the timing. By the time the ARTs got the invoices with the statement, whatever deal xTomic and the ARTs had made concerning copyright ownership would already have been made. The statement would thus be an attempt to modify whatever deal there was, but since it was gratuitous—xTomic received nothing new in exchange for this new promise—it couldn’t modify that pre-existing deal. Or else the statement was confirming an agreement that might not have existed in the first place. Either way, I don’t think the statement results in the transfer of copyright. Since the ARTs didn’t really contest this, perhaps it’s safe to assume that it had to admit the invoices in question had never been fully paid⁷And never could be paid, in light of how the invoices were structured?

We’re Enemies Now (Stage Two): What Did We Agree to Back When We Were Friends?

So, when you “buy” custom-developed software, you didn’t really “buy” it the way you might buy a custom-made house or sweater. But you bought something, right? Copyright law might be counter-intuitive, but it’s not stupid counter-intuitive, right?
Good news: you’re right! If you requested custom-made software and you paid for it, courts will imply a license—a right for you to use the software. Bad news: that leaves a lot of scope for things to go wrong for you.
Take the situation here. There’s no real dispute that, while the ARTs were paying invoices and the parties were more or less chummy, the ARTs had some sort of license to use the four programs.⁸Or, at least, one of the ARTs did—see below. The real dispute is whether the ARTs could continue to use the programs after it terminated its relationship with xTomic.
The answer, the court decided, depended on the program. There was an implied license to continue using Admin and EPN, the court ruled. But there might not be one for the EHR and PMS programs, and that a jury would have to decide it.⁹The issue was presented to the court through the ARTs’ motion for summary judgment. The ARTs were arguing that the copyright case should be dismissed because they had implied licenses to use all the programs. The only rulings the court could make were: (a) motion granted and case dismissed; or (b) motion denied and case goes on. So that’s why the court wasn’t in a position to say definitively that there was no such license. All it could say was that it wasn’t sure and a jury had to decide. Why the different outcomes? Whereas xTomic had to admit that it developed Admin and EPN for the ARTs, xTomic presented evidence that it developed EHR and PMS for a more general market (even if the idea might have been sparked by something the ARTs requested). This distinction was echoed by the way xTomic treated the source code. Whereas it eventually gave the ARTs copies of the source code for the Admin and EPN programs (after much cajoling, but it was still voluntary), it fought tooth and nail to keep the source code for the EHR and PMS programs from the ARTs (and did so only after being ordered to). If you’re sincere about wanting to market a computer program to others, then there’s no way you let anyone have access to the source code (at least, not without strict and enforceable promises of confidentiality and limitations on use).
As you can see, implied software licenses aren’t quite all they’re cracked up to be. You don’t know whether you have one, until there’s a lawsuit and a court says you have one.¹⁰Which is an expensive way to find out. And, even then, the court might say you don’t have one, and all that money you spent didn’t buy what you thought it bought.
But it gets worse, as the ARTs found out. Although the court found there was an implied license for the Admin and EPN programs, it still denied the ARTs’ summary judgment on those programs. Why? Because it wasn’t clear which of the ARTs was the licensee of the implied license. All of them? Just one of them? If not all of them, then the other ARTs would still be liable for copyright infringement!
But, wait. If only one of the ARTs was the licensee, couldn’t it just assign the license to another of the ARTs? Since they’re all controlled by the same person, that would be simple. But we don’t know if the implied license is transferrable. Implied copyright licenses are always non-exclusive, and non-exclusive copyright licenses normally aren’t transferable.¹¹The copyright owner might not want, say, a competitor, acquiring a license, for example. Since xTomic was aware of all of the ARTs, there’s a pretty good chance that it expected all of them to use the software—but the ARTs can’t be sure.

Moving from Unknown-Unknowns to Known-Unknowns Is Progress, But….

There’s enough uncertainty with running a business, without avoidable stuff like this. Consider all the things the ARTs don’t know about “their” software:

• Whether they can keep using it.
• Which of them can keep using it.
• If someone wishes to buy the ARTs, whether the license to use the software can be transferred to the buyer.¹²Since this would require a transfer of the license, and non-exclusive licenses are normally non-transferrable, this issue would throw a wrench into many run-in-the-mill corporate transactions, including not only acquisitions but also the creation of new operating entities. A straight merger would probably avoid this problem, but there’s a reason straight mergers are disfavored these days.
• Whether it can make modifications to the software, say, to fix bugs, keep it updated, make it compatible with new equipment, or improve it, and if so, under what circumstances.
• Whether the software is warranted against infringement or other harms to third parties.¹³Granted, in this case, the software has been in use long enough where any problems would be evident by now.
• Whether and to what extent the software is warranted to work as expected.¹⁴See previous note.

That’s a lot of unknowns. They affect not only how you can use the software (for which you’ve already paid a lot of money), but also your plans for your company. If you were hoping to be acquired, or form a joint venture with someone else, even split your company up for tax reasons, there’s now a complication that you might not be able to overcome.
Things aren’t super rosy for xTomic, either. True, they’ve been well-paid for software they’ve developed and still get to keep the copyright. But almost every unknown listed above can be turned back against it; and if circumstances were a little different, it could be pretty unhappy with the situation. There’s an outside chance the software might be transferrable, which could put the software in the hands of, say, a competitor. Worse, imagine if there was also a right to modify the software and it was transferrable: the software could get involuntarily forked.¹⁵I.e., two incompatible versions could be available on the market. There’s a chance that it might still have to do warranty work on the software.¹⁶See notes 13 and 14. This problem would be much worse if the software were relatively new.
The laws governing software are a complex patchwork that both under-protects and over-protects software, while increasing transaction costs unnecessarily. It’s also dangerously counter-intuitive. Until there’s some sort of overhaul of software law—something that’s not even on the horizon—all you can do is engage with software intentionally. Ideally, you’d also maintain a good relationship with your software developer, but to be fair to the ARTs, that wasn’t going to happen here…
That points up another, surprisingly common problem: hand-shake deals. I often hear that a certain agreement doesn’t need to be written because the parties have such a close, trusting relationship. Wanting to put a deal in writing makes it seem like you don’t trust the other party. And, also, lawyers: they’re always asking, what if this and what if that. And it’s true, one reason for carefully bargained written contracts is to create trust that isn’t there naturally. But another reason is a kind of posterity. The relationship might not always remain chummy—look what happened between xTomic and the ARTs. Also, the human beings who formed the deal might move on, and you might find yourself trying to make an amorphous deal work with someone you’re not chummy with, and who might think the deal ought to be somewhat different than what you’ve assumed it was.
Thanks for reading!

Rick Sanders

Rick is currently General Counsel for Software Freedom Conservancy. Previously, he has been practicing law as an intellectual-property litigator since 2000.