Two years to the day since my last blog post on this subject, the Federal Circuit has reversed Judge Alsup’s ruling that the Java API (the list of function and variable -a/k/a parameter- names) is uncopyrightable. The Federal Circuit held that the structure, sequence, and organization of the APIs renders them sufficiently original and non-functional to be copyrightable. As such, the case is remanded to determine whether there is fair use by Google in using them wholesale to make Android. For more background, see my prior post.
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.
Why is it wrong? Because Google should surely be privileged to do what it did without having to resort to fair use. The court says: “We disagree with Google’s suggestion that Sony and Sega created an ‘interoperability exception’ to copyrightability.”
It is here that framing is important. The court’s statement is accurate; we don’t get rid of copyrightability just to allow interoperability. But Sega is crystal clear that we do allow interoperability reuse: “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 the merger doctrine that the court applied, but rather a defense to infringement.
In short, this should have been an abstraction-filtration-comparison case, and the Federal Circuit makes clear that Judge Alsup did not perform that analysis. The appeals court also makes clear that if the APIs are directly taken, you can jump directly to filtration, but this does not mean you need to hold the APIs uncopyrightable in order to filter them out in the infringement analysis. Instead, Oracle gets its copyright, and Google gets interoperability. It is here that the appellate decision misses the boat.
I hate to be critical after the fact, but this case should never have gone to the jury. It should have been decided as a non-infringement summary judgment case pre-trial where Oracle kept its copyright but infringement was denied as a matter of law due to functional reuse. Maybe that would have been reversed, too, but at least the framing would have been right to better support affirmance.
May 12, 2014 update: Two commenters have gone opposite ways on Sega, so I thought I would expand that discussion a bit:
Sega is about intermediate copying fair use, yes. But that intermediate copying was to get to the underlying interoperability. And I quote the key sentence from Sega above – even if that functionality is bound up with expression (as it is in this case), we still consider that a privileged use (and thus a worthy end to intermediate copying, which is not a privileged use).
Now, in this case, we don’t need to get to the intermediate copying part because the interoperability information was published. But the privileged use that allowed the intermediate copying didn’t suddenly go away simply because Google didn’t have to reverse engineer to expose it. So, so say Sega doesn’t apply because it is a fair use case completely misunderstands Sega. The fair use there was not about fair use of the APIs. That use was allowed with a simple hand wave. The fair use was about copying the whole program to get to those APIs, something that is not relevant here. So sending this case back for a fair use determination is odd.
That said, Sega pretty clearly makes the use a defense to infringement, rather than a 102(b) ruling that there can be no copyright.
Great post Mike. A couple of questions: 1) SSO is copyrightable, but is SSO of APIs copyrightable? Batman’s telling Robin how to cook a fish is copyrightable, but my speech to you giving you the same instructions is not. 2) I don’t get what Oracle’s copyright would protect against on your theory. The only use is in the interface context. And all such uses would be “functional reuse.” Isn’t that effectively identical to non-copyrightable?
Oracle’s code that implements Java is entirely copyrightable, the interfaces that let you run Java programs are not (or at least, were not until this bizarro decision.) This is essentially the same issue as Lotus v. Borland or Sega v. Accolade, both of which were decided the other way.
John – I’m sympathetic on Lotus v. Borland – my last blog post makes the analogy, though others have pushed back on that. And it’s not in the 9th Cir. Sega, I think, can’t be stretched to read as broadly as Lotus. I quote the key language above – it’s about an exception to infringement, not uncopyrightability. Thus, I think that both Google and Oracle/Fed Cir are reading it wrong.
Bruce – The key differentiator, I think, is what you do when there is wholesale copying. If that copying is not for interoperability, then the functionality of headers shouldn’t cause them to be filtered out wholesale. It’s when your level of abstraction is headers/API only and for interoperability that you filter out the functionality. Thus, I think the court was wrong to skip the abstraction step – how you use these is important to the infringement question.
I think the decision is inconsistent with Lotus and the court does not properly distinguish the two. The court however is right that Lotus was not adopted in the 9th Cir.
But is the decision really inconsistent with Sega? Sega is a fair use decision and fair use was remanded.
Guy – see my last post on this analogizing to Lotus. I got pushback from people, like Bruce, who think that Lotus is not as clearly applicable as everyone thinks. I tend to agree with him.
As for Sega, my answer to you is the same one I had for John – but since there have been two comments about Sega (going in opposite directions), I’ll supplement the main post with my answer.
Comments are closed.