Oracle's patent and copyright infringement lawsuit against Google is currently -- apart from some remaining discovery issues such as network effects -- mostly about summary judgment: decisions on aspects of the case that the judge may or may not take on his own before trial because the law is clear irrespectively of whether the opposing party's factual representations are right or wrong.
The only topic on which a summary judgment process was scheduled a while ago -- and is already underway -- is copyright infringement. Google wants that one thrown out; Oracle wants it to be put before the jury. On everything else, the moving party needs to ask the judge for permission to file a motion in the first place. If the judge allows a particular summary judgment motion, September 8 is the filing deadline. Google proposed four summary judgment motions.
Before I discuss Oracle's opposition to Google's motion to dismiss all copyright infringement allegations and the important issues it raises, I'll give a quick update on what happened to Google's proposals for additional summary judgment motions.
Judge Alsup denies Google's most important proposals for issues to be decided by summary judgment
The two potentially most impactful ones of Google's proposals were thrown out because the judge doesn't believe that such motions were likely to succeed. Google can still try to raise those issues at trial, but those are long shots.
The boldest one was the claim that free-of-charge software should be allowed to infringe patents contributorily. Many software patents can only be infringed contributorily, not directly, so if Google was right, this would have wide-ranging consequences. Google may request summary judgment on the issue of contributory infringement by foreign device makers, but that was only the smaller part of the related proposal. However, Judge Alsup doesn't let Google request summary judgment on the free-of-charge idea. Oracle made it clear that Google does have a business model for Android anyway.
Another potentially impactful proposal aimed to have Oracle's '104 reissue patent thrown out on the grounds of impermissible broadening of its scope. The judge doubted the chances of success of this one, too, and denied it.
Another proposal was related to patent marking. It would have had potential impact only on past damages. The judge didn't want to spend time on this at this stage because the number of patent claims to be actually asserted at trial will be much lower than the current shortlist of 41, so the judge would rather evaluate patent marking based on a smaller number of claims. At that point it will be too late for summary judgment, but Google can raise the same arguments at trial. The judge didn't take a position on how likely those arguments are to succeed.
Besides copyright and the aforementioned issue of infringement by foreign device makers, the only other aspect of the case on which Google is allowed to request summary judgment is assignor estoppel, a theory based on which Oracle wants to preclude Google from challenging the validity of four patents some of whose inventors now work for Google. Oracle told the judge that this matter could be resolved "by stipulation or otherwise", and the judge would be fine with such a resolution, "but in the meantime, [Google] may file its motion". If that motion succeeds, Google can contest the validity of those patents, but this has nothing to do with the substantive merits of those invalidity grounds. In my previous report on this proposal I already supported the idea of Google being allowed to challenge those patents, not based on any analysis of the legal situation but just because I believe any substantive argument that helps to invalidate a patent should be allowed.
Why the API copyrightability dispute matters way beyond Android and Java
Application programming interfaces (APIs) are incredibly important not only in a technical but also a legal and commercial sense. Control over them can make all the difference between allowed interactions with a given program and illegal forms of use.
APIs are equally important for software running on the same machine, client-server software, and cloud computing. Case in point, Oracle's copyrightability argument also refers to some of Google's APIs, particularly the AdSense API, as examples of APIs for which protection is claimed.
Google's summary judgment motion asks the court to throw out Oracle's copyright infringement allegations because they relate to APIs, which Google wants the court to find unprotectable by copyright, and to smaller amounts of files that Google claims fall under a "de minimis" provision (too small to matter).
The "de minimis" argument for those particular files (on some of which I reported back in January) would also affect other software because Google basically wants to have the right to copy small parts of large programs, and to integrate copied material into much larger programs (Oracle cites a court ruling: "No plagiarist can excuse the wrong by showing how much of his work he did not pirate."). Oracle argues that the significance of such copying must be looked at on a file-by-file basis. Moreover, Oracle rejects the assertion that certain files generated by Google through decompilation are merely "dummy files" for testing. Oracle argues that those weren't in the "test" area of Oracle's directory structure for Java, and even if they might have served mere testing purposes for Android, that doesn't mean they weren't valuable.
Back to the bigger issue -- copyrightability of APIs. There are fundamental misconceptions out there. Again and again I hear people claim that APIs are not copyrightable in the United States. This is what Google also claims here. But Oracle disagrees very strongly, and quite convincingly. This is one of Oracle's headlines:
GOOGLE'S WHOLESALE COPYING AND IMPLEMENTATION OF JAVA API SPECIFICATIONS IS COPYRIGHT INFRINGEMENT
Oracle also claims that there's no case law to support Google's position:
No court has ever found that the APIs for a complex software platform like Java are ineligible for copyright protection.
If Oracle is right, Android faces problems beyond Java. As I explained in March, Google also denies the copyrightability of approximately 700 Linux header files. Most members of the Linux community -- and many reporters -- thought that Linus Torvalds put this particular issue to rest even though Torvalds does not make the law and issued a more-heat-than-light kind of statement that admitted he had not "looked at exactly what Google does with the kernel headers" (in other words, he wasn't able to really guarantee to people that everything was above board). Others believe that the so-called COPYING file shipped with Linux indirectly allows Google's way to use those Linux kernel headers. That, again, is an untested assumption. That file may or may not be found by a court to modify the GPL whenever such a case is brought. Even if it is deemed a binding part of an agreement, it was added after several years of Linux development, so any contributions made in the early years would not be affected.
During that debate over the Linux GPL issue Android may face (by now, there's another, even easier-to-understand one that the FSF itself acknowledges), all sorts of people spoke out and dismissed those allegations -- in a similar way as Torvalds, without accepting responsibility for their claims (they all pointed out they didn't know the details) and, especially, without really addressing IP litigator Edward Naughton's "macro" and "micro" arguments for API copyrightability. Oracle's copyrightability argument raises very similar "macro" and "micro" arguments now with respect to Java.
Even if those who claimed that Linux represents a special case were right (which in my view they probably aren't to the extent they believe), Google has done the same kind of "GPL laundering" to header files that are not part of the standard Linux kernel headers. Such a wholesale denial of the copyrightability of APIs is at least very risky. It's not a responsible choice for software that a whole ecosystem depends upon. It can trigger the so-called copyleft effect, meaning that derivative works have to be published under the GPL, too -- a no-go for many commercial purposes. In its pleading, Oracle states that Google "created a derivative work by deliberately copying [many Java] API specifications into the Android source code". Accordingly, one can claim that Google created a derivative work of Linux by copying many Linux API files into the Android source code...
But it's not just that the copyrightability of APIs has implications for Android beyond its use of Java. For example, it could also play a role at some point with non-GPL extensions of Oracle's MySQL open source database.
Copying is undisputed -- non-copyrightability and other excuses
Oracle recalls that "Google's motion does not dispute copyright ownership or that copying took place". So this is all about whether this kind of copying was allowed. Google's primary argument for why it is allowed is non-copyrightability. That's also the primary focus of this post. But let's also quickly go over Oracle's response to other excuses presented by Google:
Oracle dismisses Google's open-source-public-benefit argument as self-serving and untenable:
Google claims it conferred a "public benefit" because it took the copyrighted works and incorporated them into the “open source Android platform." [...] This self-serving argument is untenable. If a party can freely ignore the copyright and fragment the platform, as Google has, compatibility in the marketplace will be severely undermined. Allowing copying that creates an incompatible end product is against the public interest.
Instead, Oracle argues that fragmentation undermines Java's "write once, run anywhere" promise. Oracle's filing also says:
Google's success has come at Oracle's expense. Oracle's Chief Corporate Architect, Edward Screven, testified that "Android has basically foreclosed" Oracle's strategy for succeeding in the Smartphone market and that Java is "pretty well locked out of the smartphone market because of Android."
In an excerpt of a transcript presented by Oracle, the same Oracle executive also said:
But one of the ways, of course, that we make money in Java is by licensing it to other parties. So we'd be very happy, very happy, to sell a license to Google. But Google doesn't want to pay.
One of the first defenses raised by Google was that it used some code from the Apache Harmony project. Oracle says:
But it does not matter in any event. A defendant is liable when he copies, with or without a license, from a third party who copied from the plaintiff.
That's also what I said when that defense came up for the first time.
Scènes à faire: Google argues that the API material it copied simply had to be copied because there was no alternative choice. Oracle says:
But Google’s scenes a faire argument is backwards. The proper test under scenes a faire or merger is whether Oracle was constrained in its choice of design because of the need to be compatible with some other product or standard, not Google.
In this context, Oracle explains what the Mitel v. Iqtel case really meant: it was about the right holder's constraints, not those of the copyist. I have also had discussions with people who misunderstood Mitel.
Fair use: Oracle's brief also addresses widespread misbelief about the meaning of certain other copyrightability decisions in the United States. I have also had discussions with people who didn't understand that decisions that allowed developers under fair use rules to make copies of software for development purposes or to write interoperable software still didn't allow the wholesale copying and publication of such material. Here's a passage in which Oracle explains this, too:
Google’s copying cannot be excused as fair use. [...] Google's fair use argument relies heavily on the Ninth Circuit’s decisions in Sony and Sega -- two cases with very different facts that raise very different policy concerns. The focus of the court's inquiry in both cases was whether it was fair use to reverse engineer a copyrighted product where "disassembly is the only way to gain access to the ideas and functional elements embodied in a copyrighted [work]." [...] But here, Oracle’s APIs were in plain view for anyone to see, so there was no need to copy them to discover their functional elements.
Another key to both decisions was that they concern intermediate copying only. The final product was not alleged to infringe the copyright. [...] As the Ninth Circuit noted in Sega, "[o]ur conclusion does not, of course, insulate [defendant] from a claim of copyright infringement with respect to its finished products." [...] Here, of course, Oracles accuses the final Android APIs and code of infringement.
Google protects own APIs
Oracle's brief contains passages that expose Google as hypocritical and reckless, but without saying so directly.
Oracle notes that "Google, in fact, claims copyright protection for its own APIs" and points to various Google APIs terms of use, including those for the AdSense API. I'm not sure that copyright is necessarily the kind of intellectual property right Google claims, but it's true that Google imposes restrictions, and if it ever wants to enforce them, it needs to rely on some legal theory.
In its summary judgment motion, Google quoted Eric Schmidt, who testified in Congress on interface copyrightability back in 1994. Oracle now points out that Google sought protection of some of its own APIs while Schmidt was Google's CEO:Google understands the creativity and importance of APIs. It asserts copyright and other intellectual property rights over its own APIs. [...] These rights were applied for and maintained during the tenure of long time Google CEO and current Chairman Eric Schmidt. Google quotes extensively from Mr. Schmidt's 1994 testimony advocating against copyrightability, identifying him only as the "Sun CTO." [...] As this shows, there is a distinction between what a person advocates the law should be and what it is.
Oracle also stresses that instead of fragmenting Java, Google could have developed a fully compatible implementation of Java:
Google could have taken the standard license [for fully compatible implementations], or it could have negotiated to obtain a special license. It did neither."
The strongest hypocrisy point is made with respect to Google's heavy-handed control over Android:
Notably, Google requires its OEMs to maintain the full set of Android APIs – including the 37 APIs it copied from Oracle ─ to prevent fragmentation of the Android platform. Android's license is similar to Java’s providing, among other things, that “[d]evice implementations MUST NOT omit any managed APIs," "MUST NOT modify the publicly exposed APIs on the Android platform," and "MUST NOT add any publicly exposed elements…to the APIs." [...] Google itself, of course, has done all of these things to the Java APIs.
It certainly seems that Google is a "do as I say, not as I do" kind of company especially when it comes to intellectual property and openness. However, this just serves to undermine Google's credibility in the eyes of the judge. It does not per se prove that APIs are copyrightable. Oracle presents other arguments for that.
The "human" argument
What a lot of deniers of API copyrightability don't take into consideration is that those aren't merely utilitarian and dictated by technical requirements. They are designed by humans for use by other humans. That is also why someone trying to convince a court of something not being copyrightable has a high hurdle to meet. The proponent of copyrightability can basically say: "all of this program code was written by human beings -- show me why it's not expressive".
Oracle explains the human design of such APIs and distinguishes the needs of humans (who write programs using such APIs) from those of the computer executing the actual code:
[citing a declaration in support of Oracle's brief]
"[A] fundamental purpose of the APIs is not just to call a function, but to "impose a level of abstraction and structure on top of the underlying software development program" to help programmers understand its complexities. [...] The computer does not care about this organizational structure. But humans need some form of order to handle complex programming tasks and work efficiently.
In a related context, Oracle says:
Copyright Law Protects the Original Expression in the Selection, Coordination and Arrangement Of the Java APIs.
Copyright law protects expression in software design, including the selection and structure of software elements. Google's motion glosses over this issue, but selecting what to include in an API, and designing the appropriate structure to contain it, takes a great deal of creativity and skill.
Oracle claims protection for the nams of packages, classes, interfaces, fields, etc.
Oracle asserts that (at least a significant number of) the names chosen for its API elements are copyrightable:
Copyright Law Protects the Names of the Packages, Classes, Interfaces, Fields, and Other Elements in the Java APIs
Basically, Oracle explains that Android's developers took a shortcut by not thinking about alternative names themselves. If Google argues that it needed to stay compatible with Java, Oracle can obviously point to the fact that Android is incompatible with Java anyway:
Though Google copied 37 Java APIs from Java's core libraries, there were many other APIs it did not implement. Despite its claim that its copying was required for compatibility, the reality is Google took only the parts it wanted and created many other, incompatible APIs for Android. As a result, many programs written in Java for other platforms will not run on Android, and many programs written for Android will not run on Java platforms and devices.
Oracle also holds against Google the fact that the copied API material is extensive (Google's de minimis argument was made only in connection with a dozen source files):
Google does not deny that it deliberately copied 37 APIs from Java's core libraries. The APIs are extensive. They include thousands of elements. When fully printed out, they extend to more than 10,000 pages. [...] When Google finished its copying, it proclaimed on the Android developer website: "Android includes a set of core libraries that provides most of the functionality available in the core libraries of the Java programming language."
[...]
Google’s copying of the names of 37 packages, 458 classes, 158 Interfaces, 2,427 methods, 893 fields, and other elements [...] did not come about due to the existence of limited language.
[...]
Claiming there is no originality in the selection of almost 8000 names borders on absurd.
Oracle's macro theory: the structure as a whole is expressive and copyrightable
Oracle's argument does not even depend on protection of those thousands of names because its lawyers present a theory similar to Edward Naughton's "macro" theory in connection with the Linux headers: even combinations of unprotected elements can result in a copyrightable work.
Here are some passages from Oracle's related argument:
Applying the kind of microscopic focus Google does here would "result in almost nothing being copyrightable because original works broken down into their composite parts would usually be little more than basic unprotectable elements like letters, colors and symbols."
[...]
The choice of what to include in the APIs and how to arrange them requires creativity and skill. The 37 APIs contain thousands of different elements, arranged in a unique structure, with many interdependent relationships. They readily meet the standard for copyright protection.
[...]
They are not just a list of names and methods, but an
extraordinarily complex structure of hierarchy and interdepen[den]cy [corrected a rare typo in Oracle's brief].[...]
"[A] claim of copyright infringement can be based on infringement of a combination of unprotected elements."
[...]
In fact, Google copied the entire hierarchical and organizational structure of the APIs into the Android source code.
[...]
Google has cited no decision holding that the structure of a computer program with this level of complexity and interdepen[den]cy [same typo, corrected again] is precluded from copyright protection. Decisions have, however, recognized the copyrightability of programs with much simpler structures.
Obviously the copyrightability of APIs is controversial. I don't mean to say that Oracle will easily win this. But Oracle has presented strong reasons for which the judge should not dismiss Oracle's copyright infringement assertions at this stage.
By the way, I have uploaded Oracle's 30-page opposition brief to Google's motion to Scribd for all those who are looking for further detail.
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:
