Looking at Google v. Oracle as a consumer and citizen, common sense insists upon a measure of skepticism in response to the premise that the “future of all software development” depends on Google prevailing in this case. Many of those who say so are the same folks who tend to omit the fact that licensing—especially in B2B relationships—spawns innovation all the time. The underlying bias that copyright makes works inaccessible, rather than licensable, is a connotation that should not be overlooked in this case, particularly when Oracle’s Java licensing agreement is specifically designed to demand interoperability and promote development.
In Part II, I said would begin to address the core matter of contention in Oracle—the copyrightability of the “declaring code” that Google copied for development of the Android mobile platform. Google’s main legal arguments boil down to the following: 1) the “declaring code” they copied is a “method” and, therefore, an unprotectable idea under Section 102(b) of the copyright law; but 2) the Court could more narrowly find that copyright is denied under the merger doctrine; and 3) failing all that, Google’s use was a fair use.
In this post, I want to focus on the second of those assertions, partly because the Section 102(b) argument against copyrightability is largely being made by supporting amici, and although Oracle filed its SCOTUS brief on February 12, supporting parties have not yet filed. But the other reason I want to focus on the merger claim in this case is that the rationale being applied comes uncomfortably close to asserting that once a work becomes popular or important enough in the market, its copyright protection is somehow diminished. This is simply wrong as a matter of law and is an issue of no small concern for creators working in any protectable medium.
“Had To” vs. Had To
To begin with an analogy, if I ran a design firm that relied on a variety of staff and freelance artists who most commonly know how to use Photoshop, my dependence—even existential survival—on people with those skills using that software does not relieve me of the obligation to obtain a license from Adobe. (In fact, firms like this are Adobe’s bread-and-butter.) Yet, Google appears to be arguing that its “need” use the Java code was justifiable without a license because the popularity of Java denies copyrightability in the copied lines of code under the merger doctrine.
To review what I prefaced in Part II, merger denies copyright in works when there are so few ways to express an idea that the expression and idea are said to be “merged.” With software, merger can seem rather tricky because, unlike other forms of creative expression, software always performs a function, which is not protected by copyright law. For instance, no software author can protect the concept of having a computer perform the function of regulating the fuel efficiency in your car, but he can protect the code he writes to perform that function—unless there is only one way to write that code, in which case merger denies copyright.
Google’s merger argument with respect to the Java “declaring code” is founded on the premise that they “had to use it.” But to read their brief (and others), it is not at all clear that they “had to” in the strict, legal sense of “only one way to do it” so much as they “had to” in the business sense that it was the best way to enable Java-fluent developers to write for Android. For instance, the Google brief states, “… the declarations can only be written one way to perform their function of responding to the calls already known to Java developers.” (Emphasis added)
That rationale, akin to my Adobe Photoshop analogy, may have been exigent to Google’s ambition to enter the mobile market and quickly attain the dominance in that space that it now enjoys, but it does not read as a correct appeal to merger. In particular, we have two undisputed facts in this case: at the time of authorship, Sun engineers could have taken many different creative paths to produce the “declaring code” at issue; and at the time of infringement, Google engineers also had many creative options to achieve the same functions.
Google even admitted as much, stating in its brief that its engineers could have written their own version of the desired “packages” but for the fact that this would have been a barrier to enabling Java-savvy developers to write for Android. But just as with my design firm example, this is grounds for licensing an urgently-needed work, not a rejection of copyright under merger.
Google Up to its Usual Tricks?
Assuming the above is a fair criticism, it is a clever sleight of hand for Google to color the business reason they “had to” copy Oracle’s code by advancing a legal theory that could more broadly weaken copyright for all types of creators. Hardly novel territory for Google (or indeed many of its supporting amici), it is quite common to encounter anti-copyright rhetoric alleging that the more a work is considered essential (i.e. very popular), it steadily migrates into the commons; and this legal fallacy was a concern raised by the Solicitor General in its brief recommending the Supreme Court deny cert in this case …
“Petitioner [Google] also argues that the court of appeals erred by focusing on the choices available to respondent ex ante when it created Java, rather than on the choices available to petitioner when it sought to devise a way for programmers familiar with “industry standard Java shorthand commands” to use those same commands in Android. Petitioner’s approach would treat the current popularity of respondent’s work among developers as retroactively divesting the work of copyright protection. (Emphasis added. Citations omitted.)
Note that the word retroactively underscores the point that Google’s allegedly urgent “need” to copy the Java code in 2005—now that it has been synthesized through various legal defenses over the ensuing 15 years—attempts to reach back and deny copyright circa 1995 by applying a doctrine that would not have denied copyright at the time of authorship. As stated in Oracle’s brief, filed on February 12, “Google invokes merger—a narrow judge-made doctrine that does not apply unless the original author had very few ways to express the idea. It does not apply here because, as Google concedes, Java SE’s authors had countless options.”
Consequently, Google’s merger argument begins to read like an attempt to draw attention away from the creative options available to both original author and alleged infringer—a distraction that is perhaps camouflaged by the fact that computer code is generally invisible to most observers and is functional in nature, which makes it appear more susceptible to the merger exception.
I will admit that while combing through the briefs filed so far in this case, I find myself wondering whether Google engaged in unscrupulous business conduct and is managing to thread the needle of a plausible legal defense—or whether Google engaged in bad-faith conduct and then proceeded to cobble together a Jenga tower of flawed defenses that, if upheld, are more holistically harmful to copyright law than might at first appear.
Certainly, the latter conclusion would be consistent with the “infringe now, litigate after we own the market” strategy that has come to define Silicon Valley culture; but this conclusion is also implied by the legal arguments presented when we begin to unpack them one at a time, just as the courts do. For the sake of copyright principles writ large, creators should hope the Supreme Court takes a very cautious approach when considering the logical foundation of Google’s appeal to merger in this case. The relative value of a work does not diminish its protection. On the contrary, we protect works under copyright with the hope that they will become very valuable indeed.
