After Google's recent--and expected (this blog was first to report that it was coming)--petition to the Supreme Court of the United States for writ of certiorari (i.e., for a review of the Federal Circuit's decision in Oracle's favor, see my refresher Q&A after the appellate decision), I have seen a couple of articles that described the state of affairs and quoted observers on what all of this meant. In addition, I've seen all sorts of tweets. I don't want to link to them and criticize websites, authors, tweeters, and analysts (some of whom I actually like), but I do see a need to highlight the fundamental flaws in some of the commentary out there. Since the current state of the case--with Oracle being on the winning track--is consistent with what this blog has been saying for years no matter what the mainstream thought and claimed, I feel a certain responsibility to point out some important facts.
These are the most "popular" misconceptions (click on any one of them to jump directly to further detail):
Misconception: the stakes in this case are $1 billion.
Reality: the strategic value to Oracle of bringing Android back into the Java fold, as opposed to Java being hijacked forever by Android, is a whole lot greater.
Misconception: this is about the right to write applications for platforms, including the right to write interoperable cloud services.
Reality: it's only about partial or complete clones of platforms.
Misconception: third-party, independent implementations of APIs would become illegal unless the Federal Circuit ruling was reversed.
Reality: copyrightability is only the first of several criteria that must be met in order for an independent API implementation to be unlawful. Many roads lead to Rome, i.e., API freedom.
Misconception: this is about control over the Java programming language, which Sun had said was free (or, by extension, any other programming language).
Reality: the commands of the Java programming language are not, and never were, at issue. Google used the "free Java" promise as an equitable defense, which failed in district court and which Google didn't even try to resuscitate on appeal.
Misconception: this is about open-source implementations of the Java APIs.
Reality: this case changes nothing at all about everyone's freedom to develop free and open-source Java API implementations under the GPL. Even Google never claimed so in court. Android is not published under the GPL.
Misconception: definitions of basic functions such as a Math.Max (greater of two values) method would become copyrightable.
Reality: this is about the overall creativity that went into 37 Java APIs, which contain many definitions of great complexity, and their structure, sequence and organization, not about simple, isolated lines of code.
Misconception: the district judge got it all right because he learned to program Java, thus the appeals court must be wrong.
Reality: not only is the Federal Circuit ruling legally stronger but it is also more accurate in technical terms.
Misconception: a certain "G" blog was, while it was active, a reliable source of information on this case.
Reality: while that blog did a great job on a different copyright case a long time ago, it was off-base on Oracle v. Google.
Now the more detailed explanations.
Misconception: the stakes in this case are $1 billion.
Reality: the strategic value to Oracle of bringing Android back into the Java fold, as opposed to Java being hijacked forever by Android, is a whole lot greater.
It's not unique to this case but a general problem with litigation reporting that the claims formally brought and taken to trial (and, such as in patent cases against smartphone makers, the products formally accused) can be stated in ways that are not inaccurate in the narrowest sense of the word but don't reflect a plaintiff's strategic priorities.
I've come up with a new analogy: during the 2008 electoral campaign, it would have been numerically correct--but would have missed the point, which is why no one did it in that context--to describe the objective of the Obama campaign as "a senator from Illinois seeking a pay raise from $174,000 to $400,000 per year." In reality, Barack Obama would have been happy to become president for an annual salary of $1 (he was making millions from book royalties anyway). Mischaracterizations of this kind, which would be unthinkable in political journalism, occur on a daily basis in legal journalism.
Here, Oracle itself made very clear at a key juncture in the district court proceedings that its #1, #2, #3, #4 and #5 objective was a copyright injunction. Obviously, either company's--and any other company's--CFO will care about a billion-dollar amount going in or going out. But if the only net effect of this protracted litigation was a billion-dollar payment from Google to Oracle, and maybe some reputational implications for the convicted infringer, none of us (besides those companies' CFOs) would really have to care.
The remedies the statutes allow are just a means to an end. In some ancient cultures you could have asked the judge or king for anything to right a wrong, and the decision-maker had unlimited leeway, including the option of telling Google to make Android Java-compatible. Not so now, where we have statutory law and a rich body of binding case law. The prevailing (or likely-to-prevail) right holder will then sit down with the other party and work out a solution, but needs monetary and, even more so, non-monetary remedies to have leverage.
In my refresher Q&A after the appellate ruling, I already said that this case was not really about a billion dollars.
Misconception: this is about the right to write applications for platforms, including the right to write interoperable cloud services.
Reality: it's only about partial or complete clones of platforms.
I've previously criticized that certain amicus briefs (and campaigns to orchestrate support for amicus briefs) overbroadly and insolubly vaguely referred to the "use" of APIs.
The most common use of APIs is simply to write applications for a platform, or applications that communicate with cloud services, where APIs are communications protocols. That's what zillions of programmers do every day. Compared to that most common use of APIs, there's only a very small, almost negligible number of companies and developers that create partial or complete clones of platforms.
No app or cloud developer needs to worry that Oracle's enforcement efforts against Google have anything to do with the most common form in which APIs are used. This is not about Google having written Java apps.
If a company makes the APIs of its platform or cloud service available to third-party developers, it will normally be estopped (precluded because of its own actions) from enforcing API copyrights against those who reasonably rely on the right holder's interest in attracting developers to a platform. Developers would also be able to raise a "fair use" defense. But all of this is very theoretical because, in practice, a platform maker won't suddenly turn around against developers: it will continue to court them.
Misconception: third-party, independent implementations of APIs would become illegal unless the Federal Circuit ruling was reversed.
Reality: copyrightability is only the first of several criteria that must be met in order for an independent API implementation to be unlawful. Many roads lead to Rome, i.e., API freedom.
The Oracle v. Google case is a pretty good showcase of the various defenses an alleged copyright infringer can raise. That's why it's all the more misguided that some people look at the legality of third-party API implementations exclusively through the (non-)copyrightability lens.
The Federal Circuit remanded the case to the district court for a new trial on "fair use." That defense was not adjudicated at the first trial. The jury was hung, which meant that the issue needed to be revisited unless the material at issue wouldn't have been copyrightable, which would be dispositive in its own right (and which is what Judge Alsup thought but the Federal Circuit disagrees with). In this particular case, I don't think Google's "fair use" argument has merit, but there could be other cases in which independent implementers of APIs could prevail on the grounds of fair use.
The Federal Circuit also mentioned, in a footnote, the possibility of a compulsory license on FRAND terms. In cases of extreme market power, this is a last--but often effective--resort.
In a case in which a platform maker encourages widespread adoption of an API (and not just of the commands of a programming language), equitable defenses could also tip the scales in a defendant's favor. (Google's equitable defenses in this case failed, and Google didn't even try to revive them on appeal.)
It's unsophisticated at best and intellectually dishonest at worst to limit the question of independent API implementations to copyrightability, which is an extremely coarse filter because it does not enable fact-specific case-by-case determinations.
Misconception: this is about control over the Java programming language, which Sun had said was free (or, by extension, any other programming language).
Reality: the commands of the Java programming language are not, and never were, at issue. Google used the "free Java" promise as an equitable defense, which failed in district court and which Google didn't even try to resuscitate on appeal.
Sun encouraged everyone to implement the Java language. Its commands and keywords and syntax. But even the district court (whose non-copyrightability finding Google's supporters love so much) stated clearly that Google had failed "to prove an overt act by Oracle and/or Sun relaying its intent to abandon rights as to the specific elements asserted here." Relatively speaking, a 2007 blog post by then-Sun-CEO Jonathan Schwartz was Google's best argument, and even that one fell far short of what would have helped Google with respect to the intellectual property rights Oracle actually asserted in court.
The Federal Circuit was aware (as its ruling indicated) that there may be material in 3 of the 37 Java APIs at issue that one could describe as being inextricably linked to the Java language--but only 3 out of 37.
It speaks volumes that Google didn't try to get the appeals court to revive those equitable defenses.
Misconception: this is about open-source implementations of the Java APIs.
Reality: this case changes nothing at all about everyone's freedom to develop free and open-source Java API implementations under the GPL. Even Google never claimed so in court. Android is not published under the GPL.
A long time ago, Sun made certain Java material available under the GPL (GNU General Public License), a free and open-source software license. The key characteristic of the GPL is the "copyleft" principle: if you obtain a program under the GPL and modify it, you're not allowed to publish your modified version under a license that would deprive others of the freedoms the GPL had afforded you in the first place. In the Creative Commons universe, this principle is called "share-alike": share on the same or substantially similar terms as the ones you benefited from.
Google never opted for the GPL route. Otherwise it would have had to publish Android as a whole under the GPL. As a result, device makers would have had to publish their proprietary extensions (things like Motoblur, HTC Sense, Samsung TouchWiz etc.) under the GPL as well. This would have made it practically impossible for OEMs to differentiate through proprietary Android extensions. So none of the key players in the Open Handset Alliance would have liked the idea.
With or without the Federal Circuit copyrightability determination, the GPL applies, always has applied, and always will apply, to the open-sourced parts of Java. But that is not a commercial option for Google. For the open-source community it would be, and actually is, an option. After Oracle sued Google, the Free Software Foundation actually reminded people of the fact that Google could have avoided the whole problem by using Java on GPL terms.
API copyrightability makes the GPL's copyleft feature even stronger, but it's pretty strong in any event.
Google mentioned open source a lot in the early stages of this dispute. But it never raised a contract-based (license-based) defense. Not pursuing the equitable defenses on appeal was weak, but never even raising a GPL-based defense was weaker than weak. The smokescreen nevertheless worked with people who don't know how the GPL works and with some who did but intentionally misled the rest.
Misconception: definitions of basic functions such as Math.Max (greater of two values) method would become copyrightable.
Reality: this is about the overall creativity that went into 37 Java APIs, which contain many definitions of great complexity, and their structure, sequence and organization, not about simple, isolated lines of code.
What Oracle is asserting in this case is a body of 37 Java APIs with a total of approximately 7,000 lines of declaring code. Neither Oracle's theories nor the Federal Circuit ruling suggested that the threshold for copyrightability would be lowered to the point at which the definition of a Math.Max function would have become copyrightable in its own right. The hurdle isn't high, and the Federal Circuit threw out Google's attempts to have items like the nine-line RangeCheck function declared uncopyrightable. But if you want to get a single line of program code protected by copyright, you better present something reasonably expressive and creative.
A week ago I explained, toward the end of a blog post on how Google's argument has become an all-out attack on all software copyright (rather than a surgical strike against API copyrights), that Google misportrays the Federal Circuit's rationale by suggesting that anything that can be written in more than one way would automatically be copyrightable. I also looked at it mathematically. Even if one looked at only 70 (1% of 7,000) of the lines of declaring code at issue and assumed only an average of 3 alternatives per line (way too low), the number of possible combinations would have more than 30 zeros, not even counting possible permutations because different lines could be assigned to different packages, and for any given code there could be many different numbers of packages.
Misconception: the district judge got it all right because he learned to program Java, thus the appeals court must be wrong.
Reality: not only is the Federal Circuit ruling legally stronger but it is also more accurate in technical terms.
I can only shake my head when I read in certain articles that people were sooooooo impressed by the judge saying he learned Java, as he told Oracle's counsel in open court, and that he had programmed, in different languages, something like rangeCheck many times. Sorry, but that's not the way to distinguish between right and wrong decisions. If a judge, or a panel of judges, never programmed one line of code in Java or any other language, but correctly applies the basic rules of U.S. copyright law and correctly interprets the statute (particularly § 102) and the case law (including the Sega and Sony stuff Google's cert petition doesn't even cite to, despite references to multiple decisions by appeals courts, including other decisions by the Ninth Circuit), then that's what matters. And nothing else.
People also forget about the significance of a unanimous decision by a three-judge panel (at the Federal Circuit) as compared to a single judge's opinion.
Judge Alsup was right that programmers perform range checks all the time. Just this year I've written code of that kind on several different occasions. But rangeCheck, which Judge Alsup also deemed copyrightable (a fact some people seem to have forgotten; affirmed by the Federal Circuit, by the way), is not at the heart of this case. The declaring code of the 37 Java APIs is, and the Federal Circuit judges, who never claimed to have learned Java or any other programming language, accurately noted that apart from maybe 3 APIs, those are separate from the Java language, while Judge Alsup conflated language and API issues.
If the measure is whether someone has programming experience, the same people who were behind Judge Alsup's apotheosis after the erroneous 2012 non-copyrightability ruling would actually have had to trust me to a greater extent than a non-programmer paralegal's blog. I've done a lot of programming; it's what I'm doing again (and will go back to right after this post). I wrote 10 computer books, mostly on programming topics, while in high school. One of them was a commented version of the assembly (machine) language code of an entire operating system and language interpreter, of which I can show you a small excerpt (click on the image to enlarge):
So let's please go back to the facts and to what the law says and not make it a question of whom we want to trust, and let's especially not be misled by our enthusiasm for the idea of a judge ruling on a tech case having actual programming knowledge, no matter how much we like the notion.
Misconception: a certain "G" blog was, while it was active, a reliable source of information on this case.
Reality: while that blog did a great job on a different copyright case a long time ago, it was off-base on Oracle v. Google.
Checking in one's brain at the wardrobe in exchange for uncompromised allegiance to Judge Alsup (because he said he learned Java) is a major mistake. What's far worse is blind faith in a (no longer active) blog that wanted the world to believe it was an open discussion forum representative of the sentiment of open-source folks while having been convicted of a particularly malicious form of censorship whenever its own users disagreed with the propaganda and party line.
Further above I've explained why Google never had and never even tried to raise an open-source defense. It's unbelievable that a blog claiming to advocate open-source interests suggested that Google was in the clear thanks to Sun's decision to open-source certain Java material.
At this stage, Oracle v. Google is a copyright-only case, but initially various patents were at issue, and that blog totally blew out of proportion the significance of first Office actions formally "rejecting" patent claims. Most of the time, first Office actions mean very little, and if they are issued by an examiner who (as was the case for some examiners based on a sample that academics studied) initially "rejects" 100% of the challenged claims. A first Office action can be reasonably meaningful if it issues, as it happened in connection with an Apple autocomplete patent, about a year after a decision to reexamine. In that case, the examiner didn't routinely "reject" all claims but must have arrived at a reasonably well-considered conclusion. So one must look carefully at non-final USPTO actions so as not to jump to conclusions, as a certain "G" blog did just because it liked this. One of the initially-"rejected" Oracle patents was actually affirmed by the USPTO right after the start of the 2012 trial, but too late to still be presented to the jury.
The archives of that source of confusion and misinformation are certainly not a good place to start one's research (though I think that blog could have made some useful contributions to other recent debates, such as the way this year's Apple v. Samsung trial in California went).
I've taken consistent positions on API copyright in general and Oracle v. Google in particular at different stages, starting more than ten years ago (when I had a debate at a conference with an EFF staff lawyer on interface copyrights in connection with Blizzard v. bnetd) and even shortly after fighting against Oracle's acquisition of Sun. And I'll continue to defend those beliefs going forward. I'm very confident that the Supreme Court will either deny cert or will otherwise affirm the Federal Circuit. The Supreme Court won't get confused the way parts of the general public, the media, and industry observers apparently do.
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:
