Oracle v Google: The Jury Has Spoken, But What Did it Say?

Note: This post and those following rely on and are indebted to live-tweeting by Sarah Jeong and Mike Swift of the trial. Jeong storified the trial here. You can find Swift’s twitter feed here. I also reference the jury instructions, which you can find here.

Once a Year, Everyone Pays Attention to Copyright (and Finds Something They Don’t Like)

It’s been only a little more than a year since a jury has rendered a controversial verdict in a closely watch-ed copyright case. That case, of course, was the “Blurred Lines” case, which led much furrowing of brows and some gnashing of teeth about whether, if verdicts like this become a trend, songwriting will become too risky to pursue. While there is evidence that “Blurred Lines” really is part of a trend in music cases¹A movement away from near-exclusive reliance on melody in determining substantial similarity, and toward looking at a variety of musical elements—you know, like other forms of creative work subject to copyright., songwriting is not doomed, as I explained at the time.

The jury’s recent finding of fair use in Google v. Oracle has led to some wringing of hands, knowing tut-tutting, and even some exuberance:

• All copyright in software is doomed, especially free software.²I’d call this view a strawman, except it was written by Oracle’s own lead counsel!
• It’s nice and all for Google, but everything is already terrible because APIs were found to be copyrightable and fair use is a poor substitute.
• Ditto (pre-verdict version).
• We were saved from disaster because Oracle was going to after YOU. Well, potentially. The phone companies, at least.
• The jury got it wrong (but not for any reason any copyright lawyer would understand).³The author of this article argues that Google’s use should not have been a fair use because “Android is not a Java platform,” leaving a messy “hodge-podge.” That would to be an example of a “transformative use,” though. I agree with the author that copyright is a bad fit, but it shouldn’t be made into a kind of patent protection—not without doing serious damage to overall copyright law.
• Oracle should have won because we and the court and the jury misunderstand fair use (pre-verdict article).
• Juries are dumb, LOL.

I think all of these points of view are flawed.

The waters of Redwood Shores appear peaceful, but lurking, lurking, lurking… Photo by Hokan Dahlström http://www.dahlstroms.com

The Jury Verdict Isn’t Bad for Open Source

If I understand correctly, Hurst is arguing that, because open source relies on strong copyright, the jury verdict is bad for open source because it weakens copyright. Hurst goes so far as to say that “free software” is dead and that Google killed it. Actually, she goes further: “In fact, it is hard to see how ownership of a copy of any software protected by copyright can survive this result.” I.e., this verdict means that all use of software is now fair use.⁴To be fair, she wrote this the day after the jury verdict. It might not have been the best day for her. And all of us lawyers can relate. Then again, maybe blogging about your very hard-fought high-profile case the day after you lost it perhaps not the best idea.

I’ll grant Hurst’s first point. The way many open source licenses work, the obligation for downstream users to comply with open source requirements, e.g., making source code publicly available, is secured by a copyright license: if you want the right to use this piece of open source code, you need to follow these rules. And if you don’t, then someone could actually sue you. Which has happened.⁵The case was Jacobsen v. Katzer, and it involved the “Java Model Railroad Interface,” which was licensed pursuant to what can be fairly described as an open source license, though it wasn’t one of well-known ones. The Federal Circuit held that the open-source conditions could be enforced, though much of the decision turned on contract interpretation.

Hurst loses sight of what was actually at issue in the case.⁶Which is itself an interesting insight. I’ll discuss later, but one of Oracle’s strategies at trial was to conflate the organization of the API library with the entirety of Java, or at least with the Java APIs. Perhaps that argument has been internalized? That wouldn’t be too surprising. Oracle did not try to enforce copyright in the software code that comprised Java, or even, really, the Java APIs themselves. Oracle could only enforce the way the Java API libraries were organized. As it happens, each API repeats in its “declaring code” its location in the library. For example:

package java.lang;
public class Math {
public static int max (int x, int y) {⁷Surely, this has become the most famous piece of declaring code of all time.

The declaring code basically tells the developer how to use the API, its syntax. To do that, you need to know where in the library the API resides, which is expressed as a path or nested containers⁸It has been compared to a title of a multi-volume set of books: you need to know the title of the series, the volume and the chapter. You also need to know what the inputs are (in this case two integers, int x and int y. So, to invoke this API, you would write something like: “int a = java.lang.Math.max (4,5).” The “path” goes like this: start at java.lang, then go to Math, then go to max.

This might seem needlessly complicated. Why not just call the API “max”? But API libraries are large, and Java’s especially so. They need to be organized in a way later developers can understand (that is, if you expect others to use them). This isn’t a simple task. One takeaway from this is that declaring code is a reflection of the way the API libraries are organized (and what isn’t a reflection is purely conventional and functional).⁹You’ll sometimes hear that Google copied over 11,000 lines of code, but this isn’t very impressive, since most of that code is dictated by the organization of the library. You’ll also hear that 11,000 lines of code is more lines than were used in the Apollo moon landing. That’s not impressive at all, given the differences in hardware capabilities between 1969 and today. What’s actually impressive about that is that computer engineers were able to do so much with so little back then.

Where the real work is done is in the “implementing code,” which tells the machine what to do. In this example, it looks like this:

if (x > y) return x;
else return y;

Oracle owns the copyright in both the library organization/declaring code and the implementing code. Google, however, didn’t copy the implementing code¹⁰With one minor exception.. It hired developers to come up with their own implementing code without reference to the original implementing code.

Google did, however, copy the library organization/declaring code. Google did so because it was easier than coming up with an entirely new way of organizing the APIs. And I don’t just mean easier on Google, but also on any developers who wanted to use the Android operating system that was going to use Java APIs. Google could have created a completely new Android way of organizing the API libraries, but at the cost that developers already used to Java would have to learn a whole new way to use the APIs. The “max” method wouldn’t be called java.lang.Math.max any more. It would be called something else, like “android.lang.Arith.bigger” or even “android.lang.mango.mauve.”

The difference between Oracle’s case against Google and an open source developer’s case against a downstream developer is that the open source developer would be able to sue on the entirety of the source code, and not just the way the source code was organized. What we learned from the jury verdict (assuming it stands) is that the organization might be vulnerable to fair use, but there’s no reason to believe that software as a whole is.

It’s no great secret that, while copyright might be the best fit for software, it’s still a bad fit.¹¹I.e., it’s the least bad fit. That’s because, while copyright protects “literary works” (i.e., works comprised of words or characters), copyright doesn’t protect functionality. Software is essentially a functional literary work. Unlike even the dullest instruction manual, computer language allows for no variation, and hence little room for creativity: make a mistake, and the whole thing doesn’t function. When there’s a case for copyright infringement in software, the court is supposed to filter out everything that’s dictated by functionality, things that are common to every developer’s tool box¹²The software equivalent of “scénes á faire.”, things that are dictated by hardware and compatibility requirements, and things that come from elsewhere (like open-source components). Not much might be left after all this. But that’s usually not a problem because most software copyright cases involve a straight taking of thousands upon thousands of lines of code, and we can safely assume that there’s something protectable in there.

By contrast, Oracle had to stand or fall on a single identifiable structure: the organization of the API libraries. Although the organization is so large that you can’t easily show it, it is not difficult to conceptualize: it’s like how you organize your filing cabinet, or your computer files, or your personal library, only on a much larger scale. And it might be less creative.

By contrast, the open source software that Hurst is talking about is based on thousands upon thousands of lines of code. If you were to use it without permission, you’d probably be infringing copyright. Software is no less safe now than before the jury verdict.

We Don’t Know if APIs Are Always or Never Copyrightable (and We Were Never Going To)

The EFF believe that the jury verdict was a little like winning the battle of New Orleans: the “good guys” won the battle but had already lost the war.¹³Except it’s not quite fair to say we lost the War of 1812. We didn’t capture any of Canada, as we had intended, but we didn’t lose anything either. If nothing else, the much-maligned Treaty of Ghent is, by some measures, must be considered one of the most successful treaties of all time: the U.S. and Great Britain not only have never fought each other again but are close allies. The idea is that the lawsuit was only good if it resulted in binding precedent that the organization of APIs¹⁴The EFF calls this “API labels.” are never copyrightable.

The EFF is surely mistaken. Its argument boils down to: using the Java API organization is necessary to use Java, and Java is otherwise free to use; therefore the Java API organization is also free to use. This is a fine argument, but it’s not the argument that Google presented to the trial court, and that the trial court accepted, and the Federal Circuit reversed. The EFF’s argument has to do with interoperability. We know this because EFF, in its amicus brief to the Federal Circuit relies on Sega Enterprises v. Accolade, and Sony v. Connectix, which held that making copies of software in order to facilitate—essentially¹⁵I say “essentially” because there’s an extra step, and neither case directly addresses interoperability. The cases directly talk about reverse engineering, in order to get at the underlying (unprotectable) ideas in the software, but the purpose of such reverse engineering was to create software that was interoperable with the plaintiffs’ systems.—interoperability. But in both of those cases, interoperability was upheld in the context of—wait for it—fair use. It was not upheld in terms of copyrightability. Indeed, Sega rejected precisely that argument. What the EFF wanted was simply not available under controlling law.

What Google actually argued is a kind of “merger” argument—which I’m going to call “easy merger” (you’ll find out why in a moment). “Merger” is a defense to copyright infringement where there are only a few reasonable ways to express an idea or functionality. As you know, copyright won’t protect ideas or functionality—that’s what patent (and trade secret) is for. It protects expression. But if there is only a few reasonable ways to express an idea, the owner of the copyright in the expression would effectively have control over the idea/functionality, too. That would give patent-like protection to copyright, which would be terrible because copyright has a much longer term and much lower requirements. (Patents have to be novel, copyright only original. That’s a huge difference.) Merger comes up a lot in software because developers try hard to come up with the most elegant way to achieve a certain function, but copyright law won’t let them get protection for the best way to carry out a function.¹⁶Yes, this is perverse. You are punished for being a good programmer. Did I mention that copyright is not a great fit for software?

Before we go on, we might wonder for a minute how something like the organization of an API library could possibly be creative enough for copyright protection. Surely, when your organizing your computer and paper files in your own inimitable way, you’re not being creative. In fact, your family members have told you that it’s terrible, and they can’t figure it out. Why is the receipt for the automobile repair filed under “General Maintenance” and not “Automotive”? Or worse, it’s filed under something called “Barney” because that’s what you named your car.

To understand this, you need to understand two basic concepts. First, to be worthy of copyright protection, you don’t need to be very creative. As someone (I can’t remember who) on Twitter put it, you just have to show you were more creative than a monkey. Second, copyright extends not just to the words or paint strokes or musical notes, but also to the structure of those words, strokes or notes. It even applies to the way you select and organize things that aren’t even copyrightable on their own. It is thus possible to get copyright protection in the way your number your machine parts or medical procedures, but only if your method isn’t (1) arbitrary or random, or (2) functional. Numbering them sequentially isn’t creative. Neither is giving them absurd or random numbers. And neither is giving them numbers that is dictated by some functional scheme (such as the way libraries number books). But somewhere is a happy medium where a method of numbering may be protected by copyright.

Back to Google. Its merger argument went like this. Google had no choice but to organize Android’s APIs the same way Java’s APIs were organized because Android was based on Java and developers would confused and frustrated if the APIs were organized any other way. The great advantage of this argument was that there could be no dispute about the facts. Java had been around for a long time, it was very popular, there were a great many developers who worked with Java and relied on Java APIs, and they would all agree that they would go nuts if they had to learn a totally different way of organizing the APIs. This is why I call Google’s argument “easy merger.” Many of us ahem were persuaded by this.¹⁷For me, it was even worse. I actually published an article based on this. Oh, and the trial court was persuaded. There was much rejoicing. And not a little bit of relief: developers were genuinely worried that their use of APIs generally would get them in trouble.

The disadvantage of Google’s argument is that it was looking through the wrong end of the telescope (as I explain in more detail here, while consuming humble pie). Merger is determined at the time of creation, not at the time of (potential) infringement. The fact that Java is super popular now doesn’t matter. What matters are the creative choices at the time the Java API libraries were organized.

But were those choices really creative? Your method of organizing your files might be idiosyncratic and reflect your own priorities and personality, and thus creative. But whereas your method only has to make sense to you, the method of organizing Java API libraries had to make sense to future developers whom you’ll never meet. Your choices are much more limited. Indeed, there’s an argument to be mounted they are completely dictated by outside considerations. I’d guess there are conventions in organizing API libraries that were followed (and thus are uncopyrightable). The decision to put a method in one class and not another is dictated by a guess at where a later developer would expect to find it. It might be an art, but it’s an art that seeks very practical results.

I call this “hard merger,” for a couple of reasons. First, the Java API library is huge, and Google took the whole thing. And the burden would be on Google to prove that no choice (or at least a trivial number of choices) was creative. Second, to prove that, Google would have to put on proof about the conventions of organizing API libraries as of the late 1990’s, when Java was being developed. That’s a long time ago, and the leading experts might not even be around. Even for a big company with a big law firm, that’s a lot of work. And there is no guarantee of success.

Google didn’t even try “hard merger.” But, as I’ll argue next time, Google found a way to bring it in through the side door. The arguments for hard merger, it turns out, are very useful for fair use.

Here’s the thing: the question that EFF wanted put before the court—whether the organization of API libraries can ever be copyrightable—was never going to be put properly before the court. Easy merger superficially put the question before the court, but we had to make a major error in copyright law to do so. Hard merger was—in addition to being, you know, hard—too case specific. If the court had found “hard merger,” it would make us feel more confident that APIs weren’t copyrightable, you couldn’t be certain that another library was just creative enough. And the proof issues… well, if Google didn’t want to mount the argument, then no one would want to.

I actually think the EFF should be happier with the jury verdict than it lets on. As I’ll argue next time, if nothing else, Google has shown the world how to bring this sort of issue under fair use. And, as it turns out, contrary to EFF’s concerns that fair use will somehow get worn out, the issue of whether later developers should be permitted to use an API library’s organization is probably better suited for fair use than for copyrightability.
That’s enough for one blog post. I’ll finish up next time.

Thanks for reading!

Rick Sanders

Rick is an intellectual-property litigator. He handles lawsuits, arbitrations, emergency injunctions and temporary restraining orders, opposition and cancellation proceedings, uniform dispute resolution proceedings (UDRPs), pre-litigation counseling, litigation avoidance, and other disputes, relating to copyrights, trademarks, trade secrets, domain names, technology and intellectual-property licenses, and various privacy rights. He has taught Copyright Law at Vanderbilt University Law School. He co-founded Aaron | Sanders with Tara Aaron-Stelluto in 2011.