Google v Oracle (Part 3): Why Copyright Is a Bad Fit for Software

NOTE: This is the third (and final) in a series. Part 1 is here. Part 2 is here. See Part 1 for my sources for information about the trial.

But it’s All We’ve Got

After two trials, one appellate reversal, another appeal on the way, millions on millions of dollars in attorney’s fees, thousands on thousands of attorney hours, thousands on thousands of pages of testimony, and we are no closer to understanding whether, and when, APIs are copyrightable? Wasn’t that the whole point?

Coding as art? (From Oracle’s slides used in its closing arguments.)

Precedent, Bright Lines & Justice

Lawsuits are often disappointing to interested observers, even when their “side” wins. Lawsuits resolve disputes between parties. They only incidentally—and haphazardly—make law. Courts make law through precedent, which means a lower court cannot diverge from a “holding” of the court. By definition, trial courts, like the one that just heard Oracle v. Google fair use trial, cannot make law, since there are no courts below it. Still, decisions rendered by trial courts can still be powerful “persuasive” authority. Another trial court, faced with a lack of precedent, can read how other trial courts handled the question and say, “That looks like the right way to handle it.” They can also say, “No, that’s not a good way to handle it.” But it is natural for trial courts to herd on difficult and highly-publicized cases, especially in the U.S. legal system, which values consistency. The basic fairness principle underlying precedent is that like be treated alike; district court herding promotes that.

It’s nice to think we know what’s legal and what’s not. It’s weird—but true—that we often do not. It’s nice to think that if you know X did A, B & C and a jury found no liability, you also can do A, B & C without worry. It’s weird—but true—that you still need to worry, just less. If proving A, B or C requires a jury finding—say it involves reasonableness—or is subject to competent proof, a different jury might reach a different conclusion. Indeed, the different juries can view roughly the same facts and reach radically different conclusions.

Bright lines are nice: you stay on that side of the line, you’re OK; but if you cross it, you’re in trouble. The law recognizes the utility of bright lines. But it also recognizes that life is too complex, and human actors are too clever, for bright lines to resolve, with any justice, all the disputes and folly of human existence. Common sense is nice, except when it masks prejudice. Telling them apart is hard. We do the best we can.

It’s a Roadmap, and Maybe More

Despite all this, if you really feel that APIs should never been copyrightable, the jury’s verdict—and the judge’s confirmation of that verdict—in Oracle v. Google is still a step in the right direction. Assuming we’re really just talking about API libraries and how they’re organized, and any code that just necessarily reflects that organization, then Google has just presented us with a roadmap, one that isn’t terribly difficult to replicate.

More important, this strategy worked well even though Oracle was dealt a very strong factual hand. Oracle had emails from Google employees admitting that they were engaging in copyright infringement and that it wasn’t fair use. Good thing they weren’t lawyers! And good thing that the jury was free to disagree with their legal assessments! Several of Google’s key witnesses were, shall we say, vigorously cross-examined. And Oracle had a good story to tell: Google is a company that thinks it’s above the law and decided to save money by ripping off Oracle’s intellectual property. Google’s story was just better, and I think it’s replicable.
Are you holding out for actual, honest-to-goodness precedent? You might be in luck! Oracle is going to appeal, so we’ll have satisfied the first prerequisite of precedent. Oracle is likely to lose, for reasons I explained last time¹I.e., jury verdict are hardly ever overturned, and there’s no reason to believe this one will be. The next question is whether we’ll get a “narrow” fact-bound appellate opinion, or a broad holding of more general applicability.

Now, funny thing about fair use. Last time I talked about how fact-intensive fair use is. This would normally indicate that the appellate opinion will be narrow. But sometimes fair use opinions are quite broad. A good example of that is the Ninth Circuit opinion that has been lurking behind this case: Sega Enterprises v. Accolade. Sega had two very important holdings. First, interoperability was a fair use²Even though “interoperable” wasn’t actually used by the court. Second, making intermediate, temporary copies in order to achieve a legitimate purpose (such as reverse-engineering code to achieve said interoperability) was also fair use. How can we be so sure, when fair use is so crazy and fact specific? For the same reason we can be so sure about true parody: sometimes the same fact affects all of the fair use factors in the same way. In Sega, the policy of encouraging competition—not letting copyright achieve a monopoly greater than what copyright law was meant to provide—caused the first, second and fourth factors to lean in favor of fair use. Only the third factor weighed against, and the competition policy reduced that weight.

Could something like that happen here? If you feel you must use an API library’s organization, you’d use it the same way Google did (just with less amateur legal opinionating that come back to haunt you later). Your facts will look a lot like Google’s, and you won’t make the mistakes Google made. And you’ll have an appellate opinion to point to, and your opponent will have little room to distinguish your case from Oracle v. Google. Most opponents that have more legal sense than money won’t even try. If someone does try, you might even be able to get out relatively cheaply at the pleadings stage (i.e., before expensive “discovery” has started), or at summary judgment (after at least some discovery has been taken, but before trial), since the operative facts would likely be undisputed.

Even with a broad rule, there’d still be an important limitation. It would apply only to the organization of the API library (and any resulting declaring code), not to any implementing code (or the equivalent). Remember that Google had its own programmers re-create the implementing code without reference to the Java API code. Even if that implementing code was identical to that in the original Java APIs (which, I believe, a lot of it was), Google couldn’t be liable for it since Google didn’t copy the code.³Indeed, the more identical the independently created Android code was to the original Java code, less original the Java code was in the first place, since that would show the implementing code was dictated by external considerations.

Scoring Points Isn’t (Necessarily) Winning Cases.

One final thought about the trial. Several of the live-tweeters I was following seemed to think that Oracle was “winning” the case when its counsel seemed to score points during cross-examination. Oracle’s counsel was able to do so with some drama, by yelling, making the witnesses look flustered, and punctuating the air while loudly declaiming the names of various sweets.⁴I.e., the code names of various version of Android: Cupcake! Donut! Eclair! Froyo! Gingerbread! Honeycomb! Ice! Cream! Sand! Wich! Jelly! Bean! Kit! Kat! Lol! Li! Pop! Marshmallow!

These were not good moments for Oracle, actually. For one thing, judging from the time stamps, they were taking far too long—and Oracle had precious little time to begin with. And the points they were scoring didn’t go directly to the story Oracle wanted tell. They were just designed to hurt the general credibility of the witness. But it sounded as though the witnesses stood firm long enough that the Oracle lawyer started to lose his or her composure. When a lawyer is browbeating a witness on the stand, it looks to the jury like a bully picking on a kid who can’t get up and leave. And when the payoff is only that the witness has some contradictions, but not about anything that crucial to either party’s story, and it took so long that the jury forgot the point of it all, then all you’ve done is hurt your own case.

Many clients believe that good lawyering is what is shown on TV. But juries don’t see it that way—which is funny, since they watch the same TV shows. But jurors’ perspective is different: they’re trying to figure out who is right and who is wrong, not who is most dramatic. They try hard, they really do, and they reward those who make their jobs easier.

Google, by contrast, had no such problems. Its lawyers stayed on message throughout the trial. Oracle, by trying to do too much with cross-examination, chopped up its story and spiced it with acrimony. Worse, its lawyers spent so much time on cross-examination during Google’s case that they didn’t have enough time to put on its own case effectively.

Copyright & Software: Like Wearing Two Left Boots Over Rough Terrain

If nothing else, Oracle v. Google shows how software just isn’t a good fit copyright.

• Software is mostly functional but will usually have enough expression intertwined with that functionality for copyright protection. But this little bit of expression gives software protection much longer than would be available for patent: life of the “author” plus 70 years.⁵If the “author” is a corporation or is anonymous, the term is a straight 95 years from publication or 120 years from creation, whichever is shorter. If the programmer is 25 years old and dies at 75 years, the copyright term would be 120 years! That’s far more than software needs. Patent, by contrast, provides for only 20 years from filing (assuming two to three years pendency, that’s an effective term of 17–18 years).

• At the same time, this lopsided mixture of protectable expression and non-protectable functionality hurts software protection because it’s much more vulnerable to fair use—as we just saw in Oracle v. Google.
• Copyright actually punishes good programming. If you come up with a particularly elegant way to achieve functionality through your code, your reward is to have your expression merged with the functionality—i.e., no copyright protection. There’s a good reason for this: we don’t want to give patent-like protection to something with copyright’s long term, but it’s a perverse incentive.

• Where the copying is not literal, proof is a bear. Remember that copyright protects not just the actual string of words and characters, but also how it’s organized. This is why you can infringe the plot of novel, if you take too many details, even in you use entirely your own words.⁶Those detailed synopses of movies you find in Wikipedia are basically infringing copyright, but the infringement appears to be widely tolerated (and is possibly a fair use). The process of proving non-literal infringement of computer programs is: (1) you “abstract” the code’s structure at its highest level, (2) “filter” out non-protectable elements (e.g., merger, idea-expression, etc.), and (3) compare what’s left over with the same level of abstraction in the allegedly infringing work; and (4) repeat for the next level of abstraction. When you consider how long major computer programs are, and how many levels of abstraction there are, and that most judge, lawyers and juries don’t know that much about programming, you can get some sense how hard—and how expensive—this will be to prove (and defend against!).

• We don’t have a good theory (that I’m aware of) of what constitutes “expression” in code. When I ask programmers to describe it, they usually describe it in terms of elegance, such as an insight for how to solve a problem. But, as we’ve seen, that’s vulnerable to merger. Because merger lurks behind this question, courts often describe expression as having a number of reasonable choices for how to implement functionality with code. This theory is workable but doesn’t mesh with the requirement that expression show a modicum of creativity, not just choosing from various options.

• Software is oddly immune to the First-Sale doctrine because it can’t be used without making a copy of it (from storage to memory). If you buy a book, you can read it all you want; if you buy music, you can listen to it all you want; but if you buy software, you can lose your right to use it—and the cost of buying it—if the copyright owner can yank the license. What’s odd is that, from the user’s point of view, this immunity protects the software’s functionality (which is all the user cares about), not the expression (which is only incidentally implicated). We’ve tolerated this state of affairs for a very long time, but it may be coming to a head because more and more of our content is digital and takes on software-like characteristics (i.e., you have to make a copy of every time you want to enjoy it).

• Because software is purchased for its functionality, and not for its expression ⁷In the code—the expression in, say, the artwork for a computer game is a different matter., buyers are frequently confused into thinking they “own” the software they have purchased. But, unless they’re copyright-savvy, the probably only purchased a license. Many of these licenses are so robust and broad that there’s no difference (e.g., most consumer software is sold with perpetual, worldwide licenses), but a lot of custom software and enterprise software is not.⁸One day I’d like to see a software license that requires the purchaser to dance a jig at midnight on Midsummer’s Eve while reciting the Gettysburg Address as a condition for renewal.

At the same time, software isn’t a great fit for patent law either, even before Alice.⁹Alice is a Supreme Court decision that made it harder to obtain patent protection for software-based inventions. Patent protects only the ideas and functionality, but it doesn’t protect a programmer’s code itself. There might be several ways to implement an idea, but patent doesn’t care how you implement it with software. Put another way, the programmer’s craft doesn’t enter the patent discussion. Indeed, the inventor of a software-based patent doesn’t have to be—and often isn’t—a programmer. It could be a CEO who had a brainwave and hired a programmer to make it a reality. Actually, the CEO doesn’t even need to do that, so long as the necessary software is something that a competent programmer could pull off.

The Programmer’s Craft and the Lawyer’s Craft

There are a couple of themes here. First, the programmer’s craft gets short shrift. Second, business of buying and selling software doesn’t conform with our normal experience of buying things, even other copyrighted things. If we looked at software as its own regime of protection, we could directly address the policy behind concepts like interoperability, open source, computer languages, and so forth, without risking violence to the protections afforded to other types of copyrighted works.

The only solution is a Congressional one, and I’m not holding my breath. First of all, although Congress is in the middle of a high-level review of copyright law, I don’t think software protection is on the agenda. Second, the fate of § 117 shows that Congress is too timid to really strike a balance. Section 117 was meant to let you make a temporary copy of software so you could use it, but Congress lost its nerve and made a crucial change that threw the whole thing into confusion. If Congress won’t protect your right to use something you paid for¹⁰Yes, you really just bought a license. But did you read it? Did you understand it? Should you have consulted a lawyer first? Would it have made any difference since the license isn’t really part of a bargain but of a contract of adhesion? Commerce shouldn’t work this way., what chance do you think it’ll strike a good balance between programmers, their employers, consumers and the open source community?

Well, unless and until we have a good separate protection regime for software, we lawyers will just have to find creative¹¹Ahem. ways to make software fit into the various boxes copyright (and patent and trade secret) present to us—some fair use here, some copyrightability there, some idea-express over there—and to come up with creative¹²Again, ahem sources of proof and analogies for judges and juries. As we saw in the Oracle v. Google trial, not all of them are going to work well, but every non-literal software copyright case is going to be an adventure and an experiment. May as well get used to it.

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.