James Niccolai of the IDG News Service was first to obtain a copy of Oracle's response to Google's petition for writ of certiorari (request for Supreme Court review) in the Android-Java copyright case. Here's the brief (this post continues below the document):
14-12-08 Oracle Response to Google Petition for Writ of Certiorari by Florian Mueller
This is one of those documents that are most interesting when read backwards. The order in which it lays out Oracle's argument against Google's petition makes sense for those looking at the case for the first time, but after more than four years of coverage on this blog, I guess most of you already know the history of the case and the fact pattern that gave rise to this case in the first place. If the latter is new to you, or if you're looking for a refresher, the "Ann Droid" story Oracle told to the Federal Circuit is a more lively version of it. Then Oracle goes on to explain why the law has always been what it is, and I have viewed it that way for a long time, including a time when I was at loggerheads with Oracle. There's a simple plausibility test for the whole non-copyrightability claim: look at whatever cases Google and its allies show you in which copyrightability was denied (and that's different from finding in favor of fair use); then look at whether the affected material was a similar combination of quantity and originality as in the case of the Java API declaring code, and you'll find in each case that there was no such combination--and you can find numerous examples of cases in which material way less worthy of protection than the Java API declaring code was held copyrightable by U.S. courts. Life's too short to be a broken record, so I'll focus on what's new and what it means in strategic terms. And to that end, it happens to be most fruitful to start at the end.
Interlocutory appeal: why now? why not later?
The very last section argues that Google's interlocutory appeal to the Supreme Court was premature. An interlocutory appeal is an appeal prior to a final judgment. Here, the alternative for Google would have been to let the remand to California happen, to have the judge or another jury decide on "fair use", and to further appeal after losing the case. (Oracle's appeal to the Federal Circuit was not interlocutory because, if it had not been brought, the case would have been over.)
When Google chose not to ask the Federal Circuit for a rehearing, I was already wondering whether Google would focus on "fair use." Maybe Google was also thinking about the pro's and con's then, but at any event it decided it wants to take this case directly to the Supreme Court.
That, all by itself, does not mean Google's petition will fail. As the SCOTUSblog wrote in 2005, "the importance of the interlocutory status of a case is often grossly overstated." In reality, "[t]he Court regularly grants cert in non-final cases that raise important issues even when the proceedings on remand could illuminate the record in relevant respects and could affect the legal issue presented."
In this case, there is an extraordinarily strong connection between the questions of copyrightability and fair use, and that is so because of the way Google elected to argue the case in district court and on appeal. Oracle is right that Google can't seriously claim the software industry needs a quick resolution of an alleged "circuit split" (inconsistencies between different regional appeals courts) that it claims has existed for decades when the U.S. software industry, and especially the software industry in the Ninth Circuit (i.e., the West Coast, meaning mostly Silicon Valley and Microsoft), undoubtedly thrived. Still, the interlocutory status of the case doesn't guarantee the failure of Google's petition (nor does it make things any easier for Google given the huge number of petitions the Supreme Court receives).
The reason I'm interested in this has nothing to do with what the Supreme Court may or may not decide. Other factors are going to have more weight in that regard, so in case the Supreme Court denies the petition, the interlocutory status probably won't have been the reason. The most interesting aspect is that Google, to say it cautiously, does not quite exude confidence in its "fair use" defense with this tactical choice. It's old news that I don't buy the "fair use" defense here. But if Google really believes in it, why doesn't it just let the case go back to district court, try to win the "fair use" debate based on its "compatibility" argument, and if Oracle appealed again, Google could still try to take the copyrightability part, if it became necessary, to the Supreme Court? This is conjectural but the more I think about it, the more I feel that Google is not nearly as convinced of its two defenses-- non-copyrightability and "fair use"--as it claims and as its supporters claim. The Federal Circuit provided some guidance on "fair use" that ups the ante for Google, and what will up the ante to an even greater extent is that its equitable defenses failed, enabling Oracle on remand to ask the district court to preclude Google from making certain arguments that the first jury (with a bright foreman who couldn't dissuade other jurors from an illogical stance) probably thought had a bearing on "fair use" (Schwartz testimony etc.).
I can't see a winning strategy here for Google with respect to copyrightability, and its only chance with fair use is to get another jury involved that doesn't figure it out, though it will be easier to figure out next time. I wouldn't put it past Google that this here is mostly about delaying the resolution of the case. Nonsensical arguments like saying the software industry (which is mostly on Oracle's side anyway) needs this resolved immediately don't look strong.
There's another indication (that is not in the Supreme Court briefs) of Google's lack of faith in its defenses. Yesterday, Google finally released the first official non-beta version of Android Studio, version 1.0. The Android developers on the team I'm leading and I really like Android Studio (in light of Apple's Swift, Google should do even more to increase developer productivity). But somehow Google is cautious about directly integrating Java material into Android Studio, as this Stack Overflow discussion shows (it slightly predates version 1.0, but the situation is still the same). This doesn't solve Google's entire Java copyright problem. Still, what reason other than a desire to at least limit the extent of the problem would Google have to deliver an IDE--which means Integrated Development Environment--without fully integrating Java, if it's supposedly for the taking?
Google's petition addresses only one of the two reasons for which the Federal Circuit agreed with Oracle
The first subsection of the last section of Oracle's brief is short--merely two paragraphs--but raises an important issue:
"Although one would never know it from Google's petition, the court of appeals found that Oracle's work is protected on two separate bases: (1) the original declaring code and (2) the packages' creative structure and organization."
This is correct. Here's a quote from the Federal Circuit's own summary of its reasoning:
"[W]e conclude that the declaring code and the structure, sequence, and organization of the 37 Java API packages are entitled to copyright protection."
Oracle notes that Google's petition is all about the declaring code per se and "does not address the structure-and-organization rationale." According to Oracle, the failure to address an adequate alternative basis for affirmance means the petition must be denied.
Google's request for Supreme Court review (unlike certain amicus curiae briefs) is all about the functional nature of code. However, as Oracle writes in its response, "[w]hatever might be said about declaring code, the structure and organization is not used 'to operate the methods, i.e., the pre-written programs.'"
This potential reason for denying Google's petition is closely related to what Oracle says in the next subsection: Google now bases its theory on "system" and "method of operation" in the cert petition "[b]ut in the court of appeals, Google made no such argument."
I've said it before: Google's approach does not exude confidence. In its quest for some reason to get 7,000 lines of highly creative (and creatively-structured) material held uncopyrightable, it isn't consistent.
It would be easy for the Supreme Court to deny Google's petition
The previous paragraphs discussed potential reasons for a denial of Google's petition beyond the simple fact that such a massive body of highly creative (and creatively-structured), original, expressive material has always been and will always have to be copyrightable.
This article discusses how litigants are most likely to succeed in opposing a cert petition and says the following about the top court's selection criteria:
"Instead of seeking merely to correct erroneous decisions, the Court is looking, Chief Justice Rehnquist has written, for cases 'involving unsettled questions of federal constitutional or statutory law of general interest.'"
Google's primary argument for presenting an "unsettled" question is that the Supreme Court was divided a long time ago over 50 words used as menu items. As Oracle's response to the petition clarifies, that is not a question of software copyrightability. The way I view it is (apart from the question of whether we're talking about text or code) that if the Supreme Court didn't unanimously hold those menu items uncopyrightable, Cisco is fine with its 500 multi-word commands, but even those multi-word commands are very simple if you compare them to some of the more complex lines of declaring code in Oracle's Java APIs, such as this example cited by Oracle in its brief:
public abstract void verify (PublicKey key, String sigProvider)
throws CertificateException, NoSuchAlgorithmException, InvalidKeyException, NoSuchProviderException, SignatureException
That's a lot longer than the Math.Max example Google and its supporters like to point to (and which may have helped Google to confuse the district judge).
Oracle's brief also notes that one can't compare (as Google did in its petition) the QWERTY keyboard layout (the order of a couple dozen keys) to declaring code like the line above.
Getting back to Judge Rehnquist's criteria, it has to be a combination of "unsettled" and "of general interest." Unless one lowers the standard, there is no such combination here.
When I read Google's brief and the amicus briefs urging a review, I can't help but feel that they base their hopes on factors that reside at a meta-level rather than the factual, logical level. They try to make this a case that is all about interoperability, and I'll talk about that in the next section of this post. They try (some more overtly, some more subtly) to capitalize on what they believe to be friction between the Supreme Court and the Federal Circuit.
It won't be easy for them to get a Supreme Court review on that basis, but even if they did, I still can't see how they could ultimately prevail at that meta-level.
"Partial interoperability" is a contradiction in terms, says Oracle
While not putting those Sony and Sega fair use cases front and center at this juncture, Google still tries to leverage the (important) concept of "interoperability" (or its synonym, "compatibility") to get the Supreme Court interested. Oracle makes a few references to this in its brief that I wish to highlight.
In connection with "overwhelming [record evidence] that Android is incompatible with the Java platform," Oracle describes the notion of "partial interoperability" as a "contradiction in terms." If products are interoperable, they work together. If they are not, they don't. They can obviously work together to varying degrees, but the problem in this case is that what Google and the district judge meant by "partial interoperability" would more accurately be labeled as "familiarity." Interoperability happens (or doesn't happen) at the technical level, while familiarity is a state of mind. Some will argue that one can make changes to Java code in order to make it run on Android, and vice versa. But apart from this kind of definition having no boundary, it involves some additional work to be performed by human beings.
Google didn't advance the cause of interoperability when it sought to shut down Microsoft products implementing two industry standards (a jury thought this behavior warranted a $14.5 million damages award). It won't do the concept a favor by trying to stretch the definition of the term beyond recognition. So I, too, believe that "partial interoperability"--the way the district court and Google meant it--is a logical fallacy.
Oracle also addresses Google's argument that Oracle's asserted code must be devoid of copyright protection in order to prevent a "lock-in":
"[B]ecause Google deliberately made Android incompatible, when a programmer writes for Android, that programmer and program are locked into Android and locked out of the Java platform.
In the policy context, Oracle firmly rejects Google's (and Google's friends') argument that such material as the Java API declaring code would have to be free for the taking in order to enable innovation:
"Google is wrong that unauthorized copying of others' code is just how the software industry works."
Oracle doesn't say that incremental innovation shouldn't occur. The question is just on which basis. Building on top of what others create and making products work together with existing ones, or making them run on existing platforms is fine, as long as you write your own code. Using what others created is fine if you take a license. But "[t]heft is theft whether the work is a novel or complex software." Except, of course, if the "fair use" defense applies (which could be evaluated very quickly if the Supreme Court denied Google's petition).
Free software advocates speak out against the Federal Circuit and Google's petition
The Free Software Foundation and the Software Freedom Law Center have filed an amicus brief that technically (but not substantively) supports Oracle. The free software advocates engage in a balancing act. They are on Google's side with respect to copyright and with respect to copyleft, but they have a procedural preference for denial of Google's cert petition.
I've read their brief and would just like to explain what I believe their strategy is, and the philosophical and legal issues involved.
Richard Stallman, the founder and president of the FSF, leads the life of an itinerant preacher and one can only admire him for how committed he is to his cause. I've disagreed with Eben Moglen, who used to be the FSF's counsel for some time and still works closely with the FSF through his Software Freedom Law Center, on more than one occasion, but he's always extremely interesting to listen to.
Tim O'Reilly described the problem with the free software philosophy more than seven years ago:
"I continue to feel that the focus of the free software movement on 'software' rather than on 'freedom' is the real lost opportunity. [...] Focusing only on free software is as limiting as focusing on free hardware. It's freedom that matters."
The GPL licensing regime puts the freedom of program code above the freedom of developers. The copyleft principle requires all derivative works including GPL-licensed code to be made available under the GPL. This ensures that one cannot enjoy the freedoms granted to him by the GPL and then publish a derivative work under, for example, a proprietary, closed-source license. By contrast, non-copyleft open source licenses don't guarantee that the related code will always remain available on the same terms, but they give commercial software developers the freedom to incorporate it into their products.
The GPL is not about freedom-freedom. It's about enforceable freedom. And in order for anyone to enforce the GPL, the legal system as it stands (where copyleft is not enshrined in statutory law) only offers copyright for a basis. Copyleft wouldn't work without copyright enforcement. Yes, this is an oxymoron.
The dependence of copyleft on copyright is why Richard Stallman counterintuitively criticized the Pirate Party for proposing to limit copyright terms. RMS (he's frequently referred to by his initials) warned that this would allow "marauding giants" to incorporate free software into non-free software after only a few years. For someone advocating general freedom as opposed to just software freedom, this wouldn't be a big deal: one could simply let both approaches, free software and commercial software, compete. But that's not acceptable to the free software community.
RMS and Eben Moglen are copyright minimalists. They want just the level of copyright protection that is needed to make the GPL work in principle. Anything beyond that is undesirable to them. The Pirate Party proposed a copyright reform that would fall short of what the GPL needs. But other than that, less copyright is more if you ask RMS or Professor Moglen.
And now comes the part where they are demonstrably inconsistent. While they generally don't want commercial software developers to incorporate free software into their products ("marauding giants"), and while Richard Stallman considers commercial software to be immoral, they still know that the popularity of Linux (GNU/Linux as they would call it) depends on the availability of non-GPL software (other open source software as well as commercial software) for Linux.
If they were 100% principled, they'd have to like the Federal Circuit's clarification of longstanding principles of U.S. copyright law because it can prove useful in GPL enforement, or at least they should be neutral about it because free software is not made any less free by it. But their objective now is to describe the Federal Circuit opinion (incorrectly) as an outlier that shouldn't have any weight going forward. That's what their brief is really about. They don't want the Supreme Court to look at it because (without saying so) they're afraid of the outcome, knowing that the law is what it is and has been for a long time. If the Supreme Court granted certiorari, the free software guys might file another brief or just hope that what they submitted yesterday would help Google at that stage. But ideally, they just want the process to end. They want to have their cake and eat it. They try hard (but in my eyes fail) to hide the fact that this initiative of theirs runs counter to free software philosophy and is driven by the less than principled desire to let free software like Linux power non-free software like Android.
One of their claims is that the copyrightability question plays no role in this dispute because Google could always use the relevant material under the GPL. The commercial reality is that Google doesn't want to release Android under the GPL. It's a complete non sequitur to me in the FSF/SFLC brief how Google could use the Java API declaring code under the GPL, incorporate it deeply into its own products, and not have a copyleft "share-alike" obligation. So the free software brief is more of a mystery than it provides clarification. The greatest mystery is how the GPL would moot the question of past damages. But frankly, it's not worth worrying about.
The FSF/SFLC brief does, however, show to the Supreme Court that even some of those who don't like the Federal Circuit opinion would like the case to go back to district court now for a "fair use" analysis.
I don't know if any other amicus briefs will be filed. Presumably the software industry at large is just fine with the Federal Circuit ruling, which means business as usual.
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:
