June 4, 2016 | Category: Blog | Tags: copyright, expression-idea dichotomy, fair use, Google, Java, merger doctrine, open source, Oracle, originality, structure-sequence-organization | Comments: 0
Rick is an experienced Nashville intellectual-property litigator and an erstwhile part-time professor at Vanderbilt University Law School whose writing and teaching focuses on copyright issues but whose law practice involves a wide variety of IP-related disputes.
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, 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.
* 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…
Part VI: Everything That’s Old Is New Again (but it’s Still Overruled)
Last time, we examined Oracle’s strategy to overcome certain doom under the abstract-filter-compare test: pull back and look at the big picture. In other words, don’t focus on the line-by-line computer code, but look at the Java API as a whole—how the “methods” (individual programs that comprise the API) are organized and named.
The problem was that, even with the change in perspective, Oracle had serious problems under the abstract-filter-compare test because one of the things you’re supposed to filter out is expression required for interoperability or compatibility. As it turns out, the way the Java API was organized had everything to do with interoperability and compatibility. If you grant copyright to the way the API is organized internally, you’d interfere with the ability of programmers to program in Java, or, really, for anyone to use Java.
So Oracle needed a new test. And it turns out, if you go back far enough, you’ll find a test for determining infringement of copyright in software that is much friendlier to Oracle. It is from decision known as Whelan. But first, a short history lesson.
Computer software has been explicitly protected by the…
Part IV: Why Oracle Needed a New Legal Theory Worse Than Huey Lewis Needed a New Drug
Last time, we looked at why half of each Java API “method” wasn’t copyrightable (because there was only one reasonable way to express the functionality) and that the other half of each Java API was probably copyrightable.* But then I dropped a little bomb. It turns out, Google didn’t copy the copyrightable part of the Java API. It had its own programmers code them from scratch. Oracle appears not to have disputed this.
* Again, I’m kind of skeptical about this. At least with respect to some of the really simple APIs, the Merger Doctrine must surely apply. Within the confines of computer language and desired functionality, there can’t be very many reasonable ways to code for that functionality. At the same time, apparently 97% of Google’s versions of the Java APIs were different from the original code, which suggests that Google managed for find different ways to code the same APIs. I just find that kind of hard to believe.
At that point, you probably exclaimed, “Then what was Oracle suing about?”* That’s a really good question.
* Well, at least…