Humble Pie Taste Like Sawdust but at Least it’s High in Roughage
It’s fair to say that I was a little bit invested in the district court opinion in Oracle v. Google. I really thought it was a great opinion, thought it really helped clear the air about the vexed issue of copyright protection for computer programs—and I said so, both in a published article, and in a multi-part blog post (starting here).
Humble pie looks a lot like chess pie. Doesn’t taste as good, though. Photograph by Ralph Daily. Creative Commons attribution license.
So when it became clear that the Federal Circuit Court of Appeals was set to reverse the decision, I had to resist getting defensive. While my Twitter feed exploded, mostly in outrage, at the actual reversal, I put off reading the decision until I could read it fairly. The Federal Circuit might have been reversed by the Supreme Court five times out of five this year, on the very subject (patents) it is supposed to be an expert on, but that doesn’t make it wrong. And just because I had publicly supported the now-reversed trial court opinion*, doesn’t mean I was right.
Most of the criticism that I read had mostly to do with policy. In essence, they contended that the Federal Circuit to be legally wrong because APIs should just be free to use, either because innovation is served thereby or because APIs are purely functional and can’t be anything but. Which is a slightly odd thing to say, when you consider that the only reason the Java APIs might be free to use* was that the developer of Java, Sun Microsystems, made the Java language free to use. So it can’t possibly be the case that APIs, as a general class of works, are not copyrightable—just those APIs used by a “free” coding language.
* And they still might be. The Federal Circuit remanded the case for a determination of whether the need for interoperability was sufficient to make Google’s use of the Java APIs a fair use. I won’t be addressing that issue.
The comments in favor of the reversal aren’t much better. They applaud the decision because computer programmers worked hard on the APIs are should be rewarded.* But that’s just sweat of the brow all over.
* I couldn’t find any blog entries that made this point, though I found lots of comments. The best I can point to is this quote from Oracle’s General Counsel, which shows (1) he was pretty happy, and (2) he doesn’t actually get copyright law: “The Federal Circuit’s opinion is a win for Oracle and the entire software industry that relies on copyright protection to fuel innovation and ensure that developers are rewarded for their breakthroughs.” Instead, how about some more thoughtful analyses? critical of the decision, supportive of the decision, and kinda neutral.
Policy? We Don’t Need No Stinkin’ Policy!
But copyright law doesn’t usually care about policy that is not otherwise established in law, except occasionally in connection with a fair-use analysis.*
* Again, there is a strong policy favoring interoperability, so it will get a chance to make its case on remand, but even here, it can but influence, not determine, the outcome.
What I learned from the opinion was more than a little embarrassing to me. There was nothing wrong with my analysis of the lower-court decision, except I, along with a lot others, were looking through the wrong end of the telescope. The district-court decision was based mostly (but not entirely) on the doctrine of merger: if there are only a few reasonable ways to express something that’s not protectable by copyright—e.g., ideas, facts, functionality—then the expression is not protectable either.
At issue in this case is the way Sun organized the APIs. Sun used the common package-class-method hierarchy, but Sun still had to decide what classes and methods to create, which methods to put in to which classes, which classes to put into which packages, and what to name everything. There was no dispute that this organization was “original” for purpose of copyrightability, but the court held that this original expression merged into its functionality, in that, if you wanted to code in Java, you had no choice but to follow this organization. If you wanted to re-write the methods from scratch—which Google did—you had no choice but include this code in the “declaration”* part of the method:
package java.lang;
public class Math {
public static int max (int x, int y) {
Otherwise, no one familiar with Java would recognize it. Thus, there’s only one reasonable way to write it, and therefore, it merges with the functionality of the way the API library was organized: to assist Java programmers in finding the right API for a particular task.
* Each method has a “declaration” section, which describes the method’s place in the hierarchy, and an “implementation” section, which has the actual instructions for the computer. Google had the “implementation” sections written (almost entirely) from scratch, and there’s no dispute that those sections do not infringe Oracle copyrights.
Whoops. My Bad.
Only, it’s not that simple, and to make it that simple, we have to make a fundamental mistake. It is true that the organization of the API library serves a function: to be intuitive to the “community of programmers,” so they can easily find the API method they’re looking for. But that doesn’t make it automatically uncopyrightable, any more than an instruction manual is. If you’re Google, then yes, there’s only one way to organize the library—Sun’s way. But there’s our big mistake. When it comes to copyrightability, we’re shouldn’t be interested in the actions of the alleged infringer—Google—but of the author, Sun. We shouldn’t ask (as we mistakenly did) what choices Google had, but what choices Sun had.
It is worth asking, as an aside, how the trial court made this mistake. Wasn’t Oracle right there to point it out to the court? Not really. On appeal, the issues are well-defined. At trial, they’re a mess. In this trial, the case was mostly about Oracle’s patents, which were much more of a threat to Google than Oracle’s copyrights*. Trial briefs have page limits, and Oracle had to choose which issues to emphasize. I’ve read the numerous trial briefs (read them all here), and Oracle spent one (fairly eloquent) paragraph pointing out the error of Google’s argument on this issue. “Google turns scenes a faire [a doctrine similar to merger] on its head,” it wrote and cited a 10th Circuit decision the proposition that “the court’s analytical focus should have remained upon the external factors that dictated [the developer’s] selection of registers, descriptions and values.” (Brief here: quote is on pages 7–8). But that was pretty much it. Further, the court gave no indication it was buying Google’s argument. It had the parties brief a dozen or two specific issues about copyright, but not this one—yet, this was the issue on which the trial court’s opinion turned. So it goes.
* The jury found that Google did not infringe any of Oracle’s patents.
Back to my thread. To the Federal Circuit, Sun had an infinite number of choices for organizing and naming the components of the Java API library and still kept to the package-class-method hierarchy. Therefore, the “structure” of library was protected by copyright because it was “original.” To return to the example of java.lang.Math.max example, Sun could have called it (and, by extension, reorganized the API library) “java.lang.Arith.larger” or “java.lang.Math.maximum. Or, one supposes, ”java.harrumph.blob.dude.“ Or, Sun could have created a playful code in which the names of classes and methods are replaced with colors that share the first two letters, so we get ”java.lang.mauve.mango.”
Crisis in Infinite Structures
Well, let’s not get carried away. The choices aren’t really infinite—not if the API library is to fulfill the key goal of intuitiveness. As Oracle itself argued in its appellate brief, the naming and organization had to communicate their content to the “programming community” and provide a roadmap where to find them. In short, they had to be conventional. “java.harrumph.blob.dude” is fanciful, but it doesn’t convey any information. “java.lang.mauve.mango” both is fanciful and conveys information, but only if you understand the playful code.
Could Sun have called the method something other than “max”? “Larger” would convey the same information, but, since programmers are often more familiar with mathematical language, “maximum” is probably more conventional to them than “larger.” And “max” is such a well-known abbreviation for “maximum,” it almost displaces the longer word.
Could Sun have called the class something other than “Math”? “Arithmetic” would seem to convey the same information, but “mathematics” might preferable because it’s more accurate. Strictly speaking, “arithmetic” involves the most basic mathematical functions, and wouldn’t include, for example, trigonometric functions like cosine. So if you have a class with both arithmetic and trigonometry, “mathematics” is more accurate since it includes both. And, of course, like “max,” “math,” although an abbreviation, is more commonly used than “mathematics.”
But couldn’t Sun have divided the mathematical functions into, say, three classes: “Arith,” “Trig” and “Calc” (short for “calculus”)? First, that assumes that all of the functions fit into those three categories, or else we’d need a “MathMisc” class in addition. Second, that would require the programmer to take the additional mental step of first classifying the mathematical function then looking in the right class. Much easier to just group them intuitively into a “Math” class.
As you can see, Sun might have had, in theory, an infinite number of ways of classifying the method for identifying the larger of two numbers, but practically, there was only one way: java.lang.Math.max.
And Failure, Mr. Jones, Is Hardly Original.
Was Google, then, too quick to concede originality? It’s quite possible that Google chose not to challenge the originality of the Java API organization because it, too, is a software company and would prefer that its organization of its libraries receive copyright protection. At the same time, originality is a very low bar. You just need a spark of human creativity to have an “original work of authorship.”
I think the best way to address this question is to look, not at software cases (where actual code is at issue), but at “parts numbers” cases. In these cases, a competitor has copied the copyright-owner’s numbering system for its parts, procedures or whatever. In Toro Co. v. R&R Prods., the Eighth Circuit held that there was no copyright because the numbering system was “random and arbitrary”). In Southco v. Kanebridge, now-Justice Alito, writing en banc for the Third Circuit, held there was no copyright because the system was too systematic. If you are familiar with the system (which is not copyrightable), you can tell from the part number the characteristics of the part in question. In American Dental v. Delta Dental, cited by the court, Judge Easterbrook, writing for a panel of the Seventh Circuit, held that dental procedure numbers, together with a short descriptions, were sufficiently original, because (1) the numbers were neither arbitrary nor systematic and the descriptions could have been written in different ways, and (2) they authors were making sense of a morass of procedures.
The organization of an API library is not random and arbitrary, as in Toro*, but neither is it so systematic that it merely reflects an uncopyrightable system, as in SouthCo. The organization of the Java API library, probably really is a “taxonomy,” like the dental procedures in American Dental. In short, it’s original and, therefore, potentially copyrightable. So Google was right not to challenge originality.
* Even java.harrumph.blob.dude isn’t necessary random and arbitrary, so long as “harrumph,” “blob” and “dude” represent meaningful categories. If “blob” held all of the math or arithmetic functions, then the structure still isn’t arbitrary, just weird. However, if the methods were just thrown willy-nilly into classes, then the structure would random and arbitrary (as well as weird).
There’s Easy Merger. Then There’s Hard Merger (and Harder Choices).
But that doesn’t end the inquiry. We’re not actually done with merger. Well, we’re done with Google’s simple merger theory, but there’s still complicated merger. The Java API library might not be a system, but it is principled. Its design principle is ease of use and intuitiveness—because that’s more efficient. Merger could apply, because you can’t have a monopoly on the most efficient way (or one of the most efficient ways) to express something that’s not protectable. This is the great irony of the merger doctrine: you are actually punished for doing an extraordinary job!
My analysis of Sun’s choices for java.lang.Math.max above suggests (but only suggests) that, perhaps, the structure of the Java API library carried out its design principle too well: that it’s not just a very good way to organize and name methods, but one of the best ways. A good way to look at this issue is to ask: if Google had asked programmers to re-organize the Java methods it wanted to use as best they could, how similar would the resulting organization be to the original organization?
The answer is: we don’t know. We don’t know because Google didn’t go that route.* You can see why. To prove that the Java API library’s structure merged with its design principle, Google would have to go through the sort of analysis I went through above for every relevant method and class. There were a lot of methods and classes at issue. To adduce this sort of evidence trial would have taken days, and bored the jury. Maybe an expert could have been called to save time, but is there such a thing as an expert in the field of API organization?**
* At least, I assume Google didn’t, or else it would have featured in its briefing. Also, it would be a tacit admission that its main legal theory is wrong.
** Or, maybe there is, and Google couldn’t find one that would testify the way it would have liked.
Too Complex to Fail
One thing Oracle really had going for it—and this is emphasized in its appellate briefing—is the sheer size and complexity of the Java API library. Maybe it’s mostly dictated by efficiency, but surely somewhere in there is a spark of creativity. Since Google copied the structure verbatim, it’s reasonable to assume that Google copied something that didn’t merge with the design principle.*
* Much of copyright protection for software is tacitly predicated on logic very much like this. If you copy software verbatim (which is the usual case), you copied something original that doesn’t merge with the software’s functionality, and it would be a massive burden to identify what.
Once this fundamental mistake is corrected*, reversal inevitably follows. Google still has a good chance to win on fair use (reflecting another irony: success of a computer language might reduce its copyright protection).
* Well, and you dispense with and/or distinguish Lotus v. Borland.
If I have time, I’ll share some other thoughts about the Federal Circuit’s reversal of Oracle v. Google.
Thanks for reading!
