Oracle v. Google Reversed – Why Framing Matters

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.

7 thoughts on “Oracle v. Google Reversed – Why Framing Matters

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. Tim – If that’s true, then that should have been the factual question presented, and it wasn’t. But I read the expert reports themselves, so I’m not just following what others have said about this case (which is highly inaccurate in all directions).

    I suppose you are right that this is not interoperability per se. It’s more like plug-compatiblity. But it’s basically the same principle: do we allow someone else to write an alternative compiler/interpreter/operating system that will allow the same program code to operate? If Google (or me, or anyone else) wants to achieve this, then the APIs will have to copied, or else programmer code won’t work. As a commenter on Facebook noted, you could ban this use, and then there will just be a race to make a search and replace precompiler for whatever new API Google is forced to come up with.

    Is there some other copying you think doesn’t fall within this concept? I’m happy to hear about it – if you read my prior posts on this topic, you’ll see that I originally had a different take on this case, and if I saw some evidence that more than APIs for source code switching were copied, I’d be interested in hearing about it.

  6. Well, the Fed Cir is not the finder of fact. It was for the jury (or the court on summary judgment) to decide in the first instance. And the facts you note might be relevant to that. I suppose you would say the jury did find as much, but the question just wasn’t put to them that way, and the only question the Fed Cir answered was whether the APIs could be copyrightable, which-you’ll note-I agree with.

    In response to your follow up comment, Sega and Lotus take different approaches, and folks disagree on which one is right. I tend to favor copyrightability with an exception – because that allows you to ask the very question you posit – was this for compatibility. Those who favor Lotus say it doesn’t matter, it’s just not copyrightable and anyone can copy for any reason. That’s got some appeal for administrative costs – you don’t have to waste time about why there was copying.

    As to interoperability, I’m still not sold by the Fed Cir view. I wouldn’t expect an android app to run on a JavaJVM, because there were undoubtedly extensions. But why must a Java program have to run directly if there are exceptions? Your premise is that familiarity is not enough, but Lotus v. Borland was pretty clear that familiarity (which decreased switching costs) is critically important – that was just menus! And, there’s surely SOME functionality that is the same in those header definition, even if Android has some differences.

Comments are closed.