This afternoon by Eastern Time the public version of Google's brief in the cross-appeal of a district court's Oracle v. Google Android/Java copyright ruling finally became available. The brief itself had already been filed on Thursday. It's considerably longer than Oracle's opening brief (counting from "Introduction" to the date of filing, Oracle's brief consisted of 14,702 words, while Google's brief has 17,488 words -- 19% more). Here's the 100-page filing (this post continues below the document):
Google Brief in Oracle's Copyright Appeal
I've identified one argument in Google's brief that raises an interesting issue, and I'm really curious to see Oracle's response to that one in its reply brief. Google says that Oracle can't now, on appeal, claim copyrightability for anything other than the structure, sequence and organization (SSO) of the Java APIs, which is how the case was put before the jury, allegedly without Oracle objecting to it. Google says Oracle can't argue now that the 7,000 lines in question are copyrightable ("Oracle does not get a second bite at the apple if its SSO claim fails"). This is a potential obstacle. Oracle may or may not have to overcome (if the SSO of the asserted APIs is found copyrightable, that issue won't be reached). But most of what Google says in its defense of Judge Alsup's ruling, which a former U.S. copyright chief says "eviscerates" protection for software, is simply besides the point if the appeals court disagreed with Google in only three ways:
Google raises arguments in the copyrightability context that may be more appropriate, if at all, in the "fair use" context or perhaps a compulsory-licensing context under antitrust law. The example I mentioned in the headline of this post is typical:
"[T]o the extent that merger occurs because a program element becomes an industry standard, the loss of intellectual-property protection over time is nothing new. The same issue arises when a formerly distinctive trademark like 'Aspirin' or 'Thermos' eventually becomes a descriptive, generic designation that competitors 'must be free to use if they are to be able to enter the market.'"
It's quite a leap to apply this logic from trademark law to copyright law, and last time I checked Oracle didn't assert the Java trademark against Google.
Many of Google's key arguments in the copyrightability context will be irrelevant if the Federal Circuit determines that what's copyrightable is copyrightable, and always will be, for substantive reasons.
Google's lawyers' favorite word is "dictated" as in "dictated by an external factor" or "dictated by the function to be performed". That's a cornerstone of Google's anti-copyrightability argument: functional elements must be filtrated out regardless of how original or creative they are, and Google continues to claim that interoperability is a reason for denying copyrightability. In addition to the previous point (separating fair use and compulsory-licensing questions from copyrightability), the whole notion of 7,000 lines of API definitions being "dictated" makes no sense whatsoever if the appeals court determines that what matters for copyrightability is the creative freedom Oracle/Sun enjoyed when originally creating Java -- as opposed to the freedom Google enjoyed after it decided that it wanted to attract many Java programmers to Android.
Google's brief relies (not only, but primarily) on three cases with respect to copyrightability: Sega v. Accolade, Sony v. Connectix, and Lotus v. Borland. Google has a problem if the Federal Circuit, unlike Judge Alsup, finds them inapposite because Sega and Sony are fair use cases that don't provide any detailed copyrightability analysis that would help decide the Android/Java case, and because Lotus was about a menu structure (very small and simple compared to the Java APIs).
Seriously, if the appeals court viewed the above three items the way I described (and would consider correct), then there wouldn't be much left of Google's appellate argument with respect to copyrightability. And Google recognizes in its brief that the Federal Circuit might side with Oracle on copyrightability, in which case it at least wants a second jury trial on "fair use", which it then also wants to become a retrial of API copyright infringement:
"if the Court reverses the copyrightability judgment, it should direct the district court on remand to retry Google's fair-use defense (as well as the inseparable issue of infringement)."
This may be a useful reminder to all those who, even in recent months, erroneously wrote in articles and commentary that Oracle had lost in district court on two grounds, copyrightability and "fair use" -- in reality, "fair use" was simply not resolved because the jury was hung, and once Oracle prevails on copyrightability, it will have to be resolved somehow: by the appeals court, by the district court, or by another jury. As long as Oracle hasn't prevailed on this count, it can't get an enforcement ruling, but as long as Google hasn't prevailed on it either, this particular defense hasn't succeeded.
This case is far from over, and Google has to deal not only with Oracle's opening brief but also some highly informative and persuasive amicus curiae briefs (overview of amici, former U.S. copyright chief's warning against eviscerating protection for software, Sun founder's submission explanatory filing by academics regarding API creativity, filings by organizations representing creatives).
After this bird's-eye view on Google's argument I'm also going to quote and comment on a few more passages:
"The Java Application Programming Interface ('API') is not a work of imaginative fiction."
This is an allusion to the Ann Droid/Harry Potter analogy in Oracle's opening brief. Google's brief also mentions Harry Potter in a couple of contexts, claiming that fictional works are different. I don't think Oracle denied differences at the creative level, but Oracle's Harry Potter analogy is mostly about the commercial implications of plagiarism (at least that's the way I understood it).
"[Harry Potter's] chapter headings and topic sentences exist entirely for communicative and aesthetic purposes--not to 'bring about a certain result' when used in a computer."
If everything that brings about a certain result when used in a computer were excluded from copyrightability, no software would ever receive protection.
"Oracle accuses the district court of practicing 'software exceptionalism'--discriminating against software by granting it less protection than other works. But it is Oracle that seeks an exception here by asking the Court to excuse the Java API from the normal rule of 'thin' protection for functional works."
I would agree with Google on this one if, for example, Oracle claimed that a single function definition like for the "max" function should be copyrightable. In that case, copyright trolls would give programmers far more headache than patent trolls because software copyright would then be as broad as the broadest patents, or even broader. But Oracle only argues that thousands of lines of API definitions aren't for the taking. In my view, even "thin" protection has scope for this.
This is how Google states its cross-appeal issue, the eight decompiled test files and nine lines of rangeCheck code:
"Was Google's use of eight decompiled test files and nine lines of rangeCheck code de minimis and thus non-infringing when compared to the 2.8 million lines of code in the class libraries of the registered Java 2 SE version 5.0 platform?"
I'm not going to defend the rangeCheck decision, and frankly, I don't care about it too much. As for the eight test files, I believe those are protected, and the comparison to the overall number of lines of code is problematic: if a huge computer program had, say, 28 million lines of code (not 2.8 million), does this mean that one could copy 80 files from it? Or wouldn't it make more sense to look at what's copied and determine whether it's copyrightable in its own right?
Google argues that Sun had to make Java freely available because "Sun and its collaborators, including Oracle, recognized that they could not accomplish these goals by creating another proprietary platform, which Microsoft would dwarf". Whatever Sun's motives, strategies and competitive challenges were, the primary question in this appeal is copyrightability, which is unrelated to it, and even "fair use" is different. This here is perhaps relevant to equitable defenses, and the jury verdict didn't work out well for Google in that regard.
Google quotes from the district court's ruling the holding that "there is no bright line between the language and the API". Let's assume for the sake of the argument that there is no bright line. This still doesn't mean that any arbitrarily-chosen number of APIs is for the taking. It would have to be shown for each copied API why it really constitutes part of the Java language.
On page 14 Google's brief cites the declaration for the "max" method:
public static int max(int arg1, int arg2)
Google then says "[t]he 'max' method is just one of many", but the majority of Java API functions are quite different from "max" in terms of the freedom Java's creators enjoyed when designing the Java APIs. Considering that a group of academics had filed an amicus brief explaining in connection with the task of drawing a circle how an API could provide different functions having the same effect, I was surprised that Google would base its appellate argument on an exceptionally simple function like "max". If I were a Federal Circuit judge and read this, I would really wonder why they don't counter what those computer science professors wrote about creative choices in API design. It looks like Google doesn't think it can win the debate if one also looks at more interesting functions than "max". But I doubt that the appeals court is going to base its decision only on a function like "max".
Here's a passage that I think highlights very well the conflation of copyrightability and "fair use" arguments that is typical of Google's brief:
"The district court committed no clear error in finding that the command structure of 37 Java API packages is functionally necessary (1) to achieve compatibility with programs written in the Java Programming Language and (2) to access, control, and use the Java class libraries."
This is the second one of the three points I listed further above on which the appeals court might disagree with Google, in which case there wouldn't be much left of its anti-copyrightability argument. If the relevant point in time for copyrightability is when Sun created Java, then the alleged needs to achieve compatibility (didn't Apple make the iPhone a huge success without being Java-compatible?) and to access, control and use Java class libraries don't matter because they're Google's problem and didn't constrain the creativity of Java's creators.
"Oracle and its amici also argue that interoperability is 'all or nothing': to achieve it, Google must implement all 166 Java packages and Android must run all existing Java programs."
I'd like to know what Google would do if, for example, Samsung decided to depart from the Android standard and used some of the APIs but mostly different ones. In that event Google might suddenly become a fervent supporter of API copyrightability -- or at least regret its stance in the Oracle case.
Later this week, or early next week, we'll see some filings by amici curiae supporting Google. I will discuss those filings as well.
If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.
Share with other professionals via LinkedIn:
