On Wednesday Oracle filed its reply brief in the Android/Java copyright appeal, and it became publicly accessible this morning. Oracle's opening brief, filed in February, likened Google to a fictitious Harry Potter knockoff author by the name of "Ann Droid" and received support from an impressive and diverse roster of amici (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). In May, Google filed its answer, defending District Judge Alsup's ruling all the way except for some minor items (rangeCheck, decompiled programs). The amicus briefs submitted in support of Google's position were largely orchestrated by Google-funded anti-IP groups (overview, EFF, group of professors led by EFF Vice Chairwoman, CCIA, Application Developers Alliance). The latest Oracle brief responds to Google's brief and the Google-supporting amicus briefs. The week after next Google will get to file its reply brief concerning (only) the aforementioned minor issues. Then there will be a hearing, followed by a decision.
Due to the narrow focus of the upcoming Google filing, briefing is now already complete with respect to the number one issue in this appeal (copyrightability of the asserted Java API sources) and the number two issue (fair use), which becomes relevant only if Oracle wins a reversal of Judge Alsup's denial of copyrightability.
Oracle's brief says that "Google concedes away--either explicitly or tacitly--everything necessary to resolve this case under established copyright principles". Without the last four words -- "under established copyright principles" -- it would be an extremely bold claim. But those four words are key. The parties' positions are divergent. This is not the kind of case where they follow the same approach and just disagree on the results. Here, the disagreement is fundamental, and total. One party wants to go north while the other wants to head down south. The Federal Circuit now has to determine which way is consistent with existing case law and, with a view to the future, represents a workable solution that can be applied to future cases raising similar issues.
Despite this divergence, the issues have been narrowed significantly. With hundreds of pages having been filled, it's now pretty clear what this case turns on. We'll get to the strategic issues in a moment.
Google relies 100% on Judge Alsup. It won the first round in his court. But other than Judge Alsup having ruled in Google's favor and Google defending Judge Alsup, who else supports the two? Oracle's reply brief says "Google only emphasizes its lack of case support by filling its brief with quotations from the writings of an academic who has, for decades, argued for changes in the law on the ground that Congress never should have granted copyright protection to software". This academic is Berkeley Professor Pamela Samuelson, the aforementioned EFF Vice Chairwoman. According to Oracle, "Google cribs so much from this one academic that she should demand royalties".
Rather than just summarize Oracle's brief, let me show you the document (it's long, but it's very clear) and further below I'll talk about the key issues.
Oracle's Reply Brief in Google Copyright Case
Before the parties hit the crossroads I mentioned further above, there's actually quite some consensus. In particular, Google admitted a long time ago that it has copied the material in question from Oracle (its Sun Microsystems subsidiary, to be precise). Google doesn't claim to have written those 7,000 lines independently. Nor does it deny that this is expressive, creative material, or dispute that Sun's engineers had a whole lot of creative choice when they wrote all of this declaring code. That's why Oracle's brief says Google "concedes away the entire case" -- under established copyright principles the way Oracle sees them.
Let's step back for a moment before we talk about these "established copyright principles", i.e., the relevant statutes and precedential rulings. Oracle's reply brief raises a key issue, which I'm going to call "line drawing": what would be the wider impact of Google's proposed approach on the copyrightability of software? What software would and would not be copyrightable? Line drawing is key to any court, and especially to an appeals court. Judge Alsup said toward the end of his non-copyrightability decision that he didn't mean to deny copyright protection to all APIs under all circumstances. He said his ruling was specific to the facts of this case -- but the amici curiae who urged reversal warned against its (even if maybe unintended) consequences. Line drawing means that you need a set of rules (including tests) to say that A falls within the scope of something while B doesn't. Judge Alsup said B doesn't, but there might be an A -- and in ruling on one particular case, he didn't indicate what API-related code he would deem copyrightable. He didn't have to. But the appeals court will think about this a lot.
Line drawing is pretty easy if you're Professor Samuelson and wrote, back in 1984, a paper entitled "CONTU Revisited: The Case Against Copyright Protection for Computer Programs in Machine-Readable Form". Oracle's brief portrays her position as follows: "The professor 'firmly believes' that Congress was wrong to grant copyright protection to computer programs and should have created 'a new form of intellectual property law.'" (As an aside, I for my part think a sui generis IPR for software would be very interesting and, depending on its specific manifestation, could be a really great thing, but let's not digress into this in this context, which is all about the law as it stands and not the law someone would like to see made in the future.)
Oracle criticizes Google for failing to explain how software is still protectable if its broad (and, in Oracle's view, incorrect) understanding of an exclusion from copyrightability of functional, utilitarian works applies:
"[A]n original work--even one that has a function--is entitled to copyright protection so long as the author had multiple possible ways to express an idea. Instead, Google asserts that if a computer program--or any other literary work--is functional, it loses protection no matter how creative it is. Google never explains how any software can be protected under its view, since all computer programs are 'fundamentally a functional, utilitarian work.'"
I guess this passage is going to get a lot of attention from the Federal Circuit judges (maybe more than anything else in the document), who have taken great care in connection with patent-eligibility cases not to create broad exclusions through case law that U.S. Congress never intended and that only Congress could enact (Oracle's reply brief dismisses certain parts of Google's appellate argument as "policy arguments that are best addressed to Congress").
In its efforts to defend Judge Alsup's reasoning, it never crossed Google's mind that it would have to be reasonably specific as to what kinds, elements and aspects of software fall within the scope of copyrightability if the appeals court affirmed the district court's ruling. Some of Google's argument is interoperability-centric, and interoperability is what I'll discuss in the final part of this post. The way Google defines interoperability also doesn't have much of a boundary. But in connection with the merger doctrine (where there's only one way to express a certain function, function and expression merge), Google advocates a broad exclusion that goes beyond interoperability and includes anything functional. This proposed exclusion is so very broad that the startups, investors and app developers who supported its position would be very unhappy about the further effects of affirmance, just that they haven't realized it yet.
By contrast, it's pretty clear now where Oracle says the law draws the line: expressive software code, whether declaring or not, is protectable. Expression means creativity, which in turn requires choice -- choice on the part of who writes the original code, not the one deciding to copy some or all of it later. If Oracle wrote program code that is completely dictated by technical circumstances without any expressive choice, it wouldn't claim copyright in such code (regardless of how much effort, "sweat of the brow", goes into it). But if a copyist restricts himself, he can't count on Oracle's support.
Oracle's position doesn't mean that copyright becomes similarly broad as patents. This case is about (undisputed) literal copying of 7,000 lines of code. It doesn't mean that a single, simple line of declaring code is necessarily copyrightable. Nor does it mean that a broad concept, such as that of Write-Once-Run-Anywhere, would be owned exclusively by one company that describes it in a document. So Oracle divides software into copyrightable and non-copyrightable categories. Google doesn't.
Oracle says that "[o]f course, Google is free to advocate for changes in copyright law, and is doing so vigorously", pointing to a section in the Picture Archive Council of America's amicus brief "discussing Google's anti-copyright history".
I'll do more posts on this case, so I won't go into full detail on Oracle's summary of the case law right here and now. But there's one more key issue to discuss in light of Oracle's reply brief: interoperability.
Interoperability is key to the four terms contained in a section of Oracle's reply brief described as a "Google-English dictionary", providing "translations" of certain terms used by Google because "Google twists the meaning of ordinary words to obfuscate their true import". This "dictionary" is fun to read (citations omitted in quote below):
"'Industry standard': Google calls the declaring code 'a de facto industry standard,' --and then subtly drops the hedge, calling it 'an industry standard'. But Google does not mean that there is some standard-setting organization that sets out voluntary disclosure standards (there isn't) or that Oracle promised to let Google or any other commercial enterprise use its work without a license (it didn't). Google just means that the software packages became wildly popular.
'Necessary': When Google says that everything it copied was 'necessary for compatibility,' it does not actually mean 'necessary.' The most Google can assert is that '[t]hree of the [37] accused packages'--more precisely, 750 methods in 61 classes in those three packages--'were 'fundamental to … the Java language.'' But embedded in that assertion is the concession that it was not necessary to copy a thing from the other 34 packages--specifically, 6088 methods in 616 classes and interfaces across all 37 packages.
'Interoperable' and 'Compatible': When Google says that it copied the Java packages to ensure “interoperability with existing programs written in' Java, and that any use of the Java packages 'was dictated by … external factors such as compatibility requirements,' it does not mean that it developed a product that was in fact 'interoperable' or 'compatible.' Google admits that Android is not interoperable with Java, in that 'you won’t be able to write an Android app while also using [Java]-specific classes.' Rather, Google means that it wanted to harness the popularity of the declaring code and organization of certain Java packages so that Android would have a pre-existing community of followers who were accustomed to Java.
'Imperfect interoperability': When Google invokes the district court's assertion that Android achieved 'a degree of interoperability' or 'imperfect interoperability,' it does not mean that there is any significant degree to which Android apps run on Java and vice versa. There isn't. Instead, Google means that it took the packages of code that were most valuable to it--because programmers would expect to find them in a smartphone development platform--and left behind the packages that were less useful."
The above is indeed important to bear in mind when analyzing Google's "interoperability" argument. If the Federal Circuit doesn't adopt Google's extremely broad and almost borderless definition of interoperability, then it's pretty much game over for Google's non-copyrightability argument as well as its "fair use" argument. Should the appeals court agree with Google, there are still considerable hurdles.
Google basically claims that the Sega and Sony rulings, which I discussed last year, create an interoperability privilege at the level of copyrightability -- when those are "fair use" cases that actually held some software copyrightable (as Oracle's reply brief points out), tiny pieces of code compared to what's at issue in Oracle v. Google. Oracle also clarifies the scope of the findings in favor of fair use in those cases:
"The copies at issue in Sega and Sony were not final, commercial products, but intermediate copies used to figure out how the software works. In contrast, Google's copying here was for a final, commercial product: Android."
According to Oracle, "Sega and Sony do not help Google in fair use any more than they did for copyrightability". There definitely is a difference: at least those are "fair use" cases that resulted in the finding Google wants in its (distinguishable) case: fair use. They are not copyrightability cases, and the software that was found to be used fairly was found copyrightable (which Google strives to avoid in its case). Fair use applies to copyrightable material. If something isn't copyrightable, fair use doesn't matter, which is why Google's "fair use" in this claim still hasn't been ruled on (the jury was hung, which means that neither party prevailed on this one, and it only matters if and when the asserted declaring code is found copyrightable).
There's more stuff in Oracle's reply brief that's worth discussing. And Google's final brief will also be very interesting. I'll continue to follow and comment on this case.
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:
