It's been about two years, so I guess it was about time to write about Oracle v. Google. The trigger this time: in a blockbuster opinion (and I never use that term), the Federal Circuit has overturned a jury verdict finding that Google's use of 37 API headers was fair use and instead said that said reuse could not be fair use as a matter of law. I won't describe the ruling in full detail - Jason Rantanen does a good job of it at Patently-O.
Instead, I'll discuss my thoughts on the opinion and some ramifications. Let's start with this one: people who know me (and who read this blog) know that my knee jerk reaction is usually that the opinion is not nearly as far-reaching and worrisome as they think. So, it may surprise a few people when I say that this opinion may well be as worrisome and far-reaching as they think.
And I say that without commenting on the merits; right or wrong, this opinion will have real repercussions. The upshot is: no more compatible compiler/interpreters/APIs. If you create an API language, then nobody else can make a competing one, because to do so would necessarily entail copying the same structure of the input commands and parameters in your specification. If you make a language, you own the language. That's what Oracle argued for, and it won. No Quattro Pro interpreting old Lotus 1-2-3 macros, no competitive C compilers, no debugger emulators for operating systems, and potentially no competitive audio/visual playback software. This is, in short, a big deal.
So, what happened here? While I'm not thrilled with the Court's reasoning, I also don't find it to be so outside the bounds of doctrine as to be without sense. Here are my thoughts.
As I noted the last time, and the time before that, this case should never have gotten to this point. This is just not a fair use case. This case is about whether the functionality of APIs are the types of things that can be implemented in reused code, even if it takes some expression to do it. In my 2014 post, I noted how Sega put it: “To the extent that a work is functional or factual, it may be copied,Baker v. Selden, as
may those expressive elements of the work that ‘must necessarily be
used as incident to’ expression of the underlying ideas, functional
concepts, or facts….” (this is not a fair use point, but a copying point, but the Federal Circuit does not acknowledge this language). As I noted in 2016: "It's not the copyrightability question that matters, it is whether or
not we allow reuse. And that's an infringement question (or, as some of
my colleagues put it in different theoretical terms, a scope question)."
But at some point, whether it was Google or the District Court, this question got lost, and went all-in on whether the whole codebase was copyrightable. The District Court said no, the Federal Circuit said yes. As I noted in 2014, the Federal Circuit was right: "The problem with this ruling is twofold. First, it is surely correct.
Second, it is surely wrong. Why is it correct? Because structure,
sequence, and organization can be creative. This has long been true, and
well should be. I won’t relitigate that here, but holding that these
APIs were simply not copyrightable was a stretch in the 9th Circuit, and
the Federal Circuit is correct to say so."
But by going all in, the court and original jury was deprived of all of the tools you normally see in a case like this: no abstraction, filtration, and comparison (or analytic dissection, as they call it in the Ninth Circuit). Take a look at the original jury instructions. There's no mention of all the things we see in copyright cases like this: scenes a faire (similarities in package groupings and command names), functional names, functional variable types, and so forth. I've blogged recently about such dissection in photographs and music. The record here is devoid of it: all we have is copyrightable=infringing, uncopyrightable=non-infringing, hope for the fair use.
So, that's my grousing about the posture of the case. Now, maybe there's nothing that could have been done about it, but I sure am glad that Microsoft's lawyer's figured this out in the Apple v. Microsoft case, rather than solely relying on an argument that Apple's entire desktop was unprotected because it was functional.
As to the Federal Circuit's fair use ruling, while I strenuously object to the outcome, I am perhaps not as critical of the actual analysis as you might think. It seems to me to be extremely rare to overturn a jury verdict of fair use to find no fair use. I did a search, as did a couple of colleagues who reported on my Twitter thread, and we could find none. This may well be a unicorn, but it only takes one case to prove me wrong. If somone knows of such a case, let me know!
But does that mean the court was wrong to use de novo review? The court spent several pages discussing the standard of review. It is clear they took this matter seriously, both because of what they were about to do, and because they surely knew it would be looked at either en banc or by the Supreme Court. Despite the fact that I just got done telling people that jurors rule on infringement all the time, most of the famous fair use cases seem to implicitly adopt a de novo air about them. People have mentioned that Harper & Row was an appeal of a bench trial, but I think that's a red herring - the Court affirmed a finding of no fair use by the District Court. That's just not this case. At the same time, I think there are not that many fair use jury verdicts - one way or the other.
I wonder more generally if we are in a "live by the sword, die by the sword" situation. Proponents of fair use have no problem urging courts to find that uses are transformative. If courts can do this without a jury, why can't they find works are non-transformative? Why is transformative a one-way non-jury question? In that sense, perhaps I should just disagree with the court on the facts here rather than think the court is upending fair use law?
Then again, it's not clear to me that the court is wrong on transformativeness. These APIs were used for their intended purpose - as a front end for a program. That there was different implementing code doesn't transform them. It's the same code used in the same way, and I frankly think some courts have taken transformativeness too far, so I think this could just be a judicial policy disagreement. Of course, the arguably non-transformative way the APIs were used is functional - see above.
More problematic is the market substitution. The court is making a value judgment here that I don't know bears out, but at the same time really defines the entire problem here. So much of modern fair use comes down to the following question: is this a use for which the copyright owner should own the market? So, in American Geophysical, the court said that there was a reasonable market for licensing out copies of journal articles, and the defendant usurped that market by making copies of articles without paying. And in Bill Graham Archives, the court said that there was no market for taking concert posters and putting them in coffee table books. Finally, in Google Books, the court said that the copyright owners did not own the market for what pages certain words fell on.
And now, in this case, the court says that developers do own markets for the structure and names of systems that take commands from ancillary programs. And I just could not disagree more. So I'll end by repeating what I wrote two years ago, because it's like a broken record that I hope the Supreme Court will finally hear: "The court should have ruled that as a matter of law, on these facts,
this type of use of an API does not constitute infringement. Whether you
get there through abstraction/filtration, thin copyright, privilege, or
even presumptive fair use, this should have been an easy question. My regret for the posture that this case was decided and went up on
appeal is that it was so focused on copyrightability. That was the wrong
question to look at, and it wound up doing a disservice to software
developers everywhere, because even though Google won this time, you
don't know what will happen next time." Next time has now come.
