Category: Software

Google v. Oracle IV: Fair use & the difference between new and transformative.

Although it has been my intention to write about Google v. Oracle serially, addressing the legal questions in more or less in the order they are presented and weighed in a court opinion, it turns out today marks the end of Fair Use Week.  (How I could have missed that in this otherwise sleepy news cycle is a mystery, I know.) But as Fair Use Week is still officially live, I am going to jump ahead in this post to respond to Google’s claim that its use of Oracle’s Java SE code in the development of the Android platform was a fair use.

We will assume for the sake of discussion that Google’s challenge to the copyrightability of Oracle’s code will not succeed because, absent an infringement, there is no reason to consider a fair use defense. On that note, it is worth mentioning that while it may be good legal strategy to present a fair use argument as a Plan B in a litigation, some fair use assertions are more demonstrably hail-Mary plays than others.  And in this case, Google’s argument seems like a pretty wild pass all the way down the gridiron that should be knocked down by the fair use test.

Above all, Google’s fair use assertion under the first factor—arguing that its use of Oracle’s code was transformative—is yet another example of this tech giant in particular seeking to conflate the novelty of a product with the nature and purpose of transformativeness in fair use. 

For quick review, transformativeness, in its earliest application, tilts toward a finding of fair use when a new creative expression is derived from the specific use at issue.  Hence, the seminal case Campbell  v. Acuff-Rose (1994), in which the Supreme Court unanimously held that 2 Live Crew’s use of the heart of the song “Oh, Pretty Woman” produced a new expression—a parody of the original. Campbell upholds the purpose of copyright to promote new forms of expression such that society gains both the original work and the parodic comment upon the original work. 

By contrast, in considering Google Books, a search tool that relies on the use of digitized copies of millions of published works, the courts in 2015  broadened the doctrine to encompass uses that are transformative because they “expand the utility” of the original material. The Google Books interface offers an unprecedented and highly-useful research tool that does not provide a substitute for the works used—namely it does not make full books under copyright available.

Nevertheless, the Second Circuit Court of Appeals cautioned that its holding in Google Books “tested the boundaries of fair use.”  In other words, the “utility” aspect of the transformative test is meant to be scrutinized very carefully, as the same court later affirmed in its (2018) consideration of the service ReDigi, which asserted that an online exchange trading in “used” digital music files was transformative …

“Even if ReDigi is credited with some faint showing of a transformative purpose, that purpose is overwhelmed by the substantial harm ReDigi inflicts on the value of Plaintiff’s copyrights through its direct competition in the rights holders’ legitimate market, offering consumers a substitute for purchasing from the rights holders.”

Translation:  not everything “new” is transformative under a fair use analysis. Google’s claim that its use was transformative in its defense against Oracle breaks the boundaries the Second Circuit drew in Google Books because Google did nothing to “expand the utility” of Oracle’s code.  On the contrary, Google used Oracle’s code for the exact purpose for which it had been developed—and for which other mobile developers had licensed the work.

Further, Google’s claim is not markedly distinguishable from the holding in ReDigi; Google’s use of Oracle’s code put the search giant in “direct competition” with the party whose work it appropriated, usurping opportunities in the mobile market that Oracle was already exploiting by licensing its products.

Google and supporting amici assert that the roll-out of Android itself is sufficient to render its use of Oracle’s code transformative. But if mere “newness” of a product (or even a creative work) were the shibboleth required to pass the transformative test, this standard would swallow copyright in its entirety and nullify the purpose of a fair use exception.  “… the more amorphous and unreasonably expansive the analysis and application of the fair use doctrine, the harder it becomes to establish the value of the copyrighted work during licensing negotiations that are the lifeblood of the creative ecosystem,” states the brief filed by songwriters in support of Oracle.

Any use of a prior work will always result in something new; but this novelty alone has never relieved the user of the responsibility to either license the prior work or to demonstrate how the use narrowly qualifies for a fair use exception. In this case, Google makes the familiar (though thankfully still unsuccessful) argument whereby the infringing user asserts that migrating a work from one medium to another is transformative. Not only is this not transformative, but in Google’s case, using Java SE in mobile platforms is not even novel. In the absence of transformativeness the first factor consideration of commercial v. non-commercial use will weigh heavily against Google given that Android is a multi-billion-dollar commercial use.

On the third and fourth fair use factors, Google should also fail, while it may end up a draw on the second.  The second factor considers the nature of the work used, and although neither party denies creativity in the declaring code at issue, the inherent functionality of software may point towards a tie in the analysis of the Court. The third factor considers the amount of the original work used, and although Google emphasizes that it copied only a fraction of Java SE, Oracle states in its brief that, “Google admits it copied the packages most valuable to create a derivative version of Java SE for mobile devices.” Further, fair use is not sustained by showing how much they did not copy.

The fourth factor should be especially prejudicial against Google’s fair use claim, as it addresses the harm, and potential harm, to the creator’s market for the work used.  Here, as in ReDigi, the analysis militates against fair use.  As Oracle states in its brief, describing prior licensees of Java…

“If what Google did was permissible, IBM, Danger, and others would not have licensed Sun’s declaring code or complied with [the interoperability standard] ‘write once, run anywhere.’ If everyone could copy the declaring code without a license, Java SE would lose value, as anyone could ‘reimplement’ a knock-off. This undisputed evidence negates Google’s defense as a matter of law.”

More broadly, if Google’s unprecedented assertion of fair use in this case were the new standard, this would only empower the wealthiest corporations to poach any creative works they choose, as long as whatever they use them for has not already been put on the market. That predicate offends the purpose of copyright and is anathema to the interests of all creators in all media. Google enjoys enough advantages when it comes to squashing competitors and making a business out of infringement, without the courts also rewriting decades of copyright doctrine at their behest. 

Google v. Oracle III – Popularity Does Not Overturn Copyright

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.    

Google v. Oracle Part I: Or Why You Really Don’t Have to Know WTF an API Is

I freely admit that one reason I procrastinated when it came to digging into Oracle v. Google (now Google v. Oracle) is the fact that this nine-year litigation, now headed to the Supreme Court, deals with software.  Unlike most creative arts in which I have some background and knowledge, software might as well be magic spells that make our devices run (or not); and although this form of authorship is generally invisible or incomprehensible to most of us users, the code-writers say it entails creative expression, and so does the copyright law since 1980.  

This clash-of-titans lawsuit, which currently stands with two rulings (in 2014 and 2017) in Oracle’s favor at the Federal Circuit Court of Appeals, will now ask the Supreme Court to settle two main legal questions:  1) whether the specific code (part of Oracle’s Java API) used by Google without a license in the development of Android is copyrightable in the first place; and 2) if that code is protected by copyright, whether Google’s use is protected by the fair use doctrine.  I will actually address the legal narrative and issues in subsequent posts because on top of the triable matters and doctrinal debates, is a business and PR story that should probably be addressed first. 

From Google’s perspective—and that of its defenders, who include many prominent copyright critics—the future of software innovation itself hinges on Google ultimately prevailing in this case.  These parties allege that developers everywhere depend on using programs like Java API (originally developed by Sun Microsystems) without license; and if they cannot do so, software evolution as we know it will be in jeopardy.  But without even getting into what an API is, and whether it can be copyrighted, let us keep in mind that this is Google we’re talking about—a market-killing, competitor-squashing, policy-manipulating, rights-infringing monopsonist that lacks any street cred to be speaking on behalf of the start-up entrepreneurs out there. 

Copyright history is replete with this recurring theme:  one business or industry would prefer to circumvent or deny copyright protection to a particular class of work and declares that, if their argument does not prevail accordingly, the death of [insert industry here] will ensue, and the public will suffer for the loss.  In this sense, note Google’s very broad statement in its petition asking the Supreme Court to grant certiorari …

“Given the ubiquity of smartphones today, it is easy to forget the challenges that developers initially faced in building the operating systems that allow modern smartphones to perform their myriad functions. Among other things, developers had to account for smaller processors, limited memory and battery life, and the need to support mobile communications and interactive applications.”

Notice how the narrative thrust here positions Google as just another developer doing good works for society, almost as though the company had no interest whatsoever in becoming one of two—count them, two—smartphone platforms now being used in several major markets.  But Google is, of course, not just another developer.  According to Oracle’s brief in opposition to granting cert …

“Google faced an existential threat.  People with mobile devices were not using Google’s search engine, causing Google to lose significant advertising revenue.  It needed to quickly develop a platform tailored to mobile devices that would promote Google search.”

Perhaps Google would dispute this fact pattern, but it sounds substantially more realistic—and is wholly consistent with the company’s market behavior to date—than the tech giant’s alleged, post hoc concern for “developers everywhere.”  In order to move as quickly as possible into the mobile market, and encourage developers to create apps for what would become Android, Google describes …

“In 2005, Google and Sun began discussing a partnership that would have allowed Google to adapt the entire Java SE platform for smartphones. Google and Sun conducted negotiations but were unable to reach an agreement. In the absence of such an agreement, Google used the freely available Java language (and its declarations) to develop its own libraries of methods that enabled developers to build smartphone applications for use on Android devices.” (Emphasis added)

Note that I highlighted a couple of terms in order to draw your attention to what reads like a contradiction.  If indeed a software is “freely available,” why was a party like Google “negotiating” with Oracle for its use in the first place?  It seems almost as though some piece of that story is missing, which, not surprisingly, Oracle fills in with its brief, stating, “Google rejected the condition Oracle demanded of all commercial licensees: make Android ‘compatible with the Java’ platform and ‘interoperable with other Java programs.’” (Emphasis added)

Again, I will leave the matter of copyrightability of the specific code Google appropriated to a future post; but even without understanding what Java or an API is, the whole existential-threat-to-software-development narrative starts to look a little squishy.  Instead, this story begins to read like a typical scenario in which a commercial user (one of the biggest commercial users in the world) did not like the licensing terms to which several other commercial users had subscribed and, so, opted to go permissionless and sort it out later.  With regard to its licensing regime, Oracle states that app programmers (e.g. those folks who make games and guitar tuners etc.) can obtain a free Java platform license for development.  But …

“Oracle recoups its investment in the Java platform mainly by licensing it to (1) hardware manufacturers who copy the platform onto their devices…and (2) competing platform developers who want to use Oracle’s programs to commercialize their own platforms.  Any platform developer that does not want to take a license is free to develop its own platform with identical functions without copying the Java platform.  Apple and Microsoft did it.”

Assuming these statements are undisputed facts—and we need not understand the technology here—what exactly was Google’s problem with agreeing to the “interoperability” term of the license agreement, which other platform developers like Blackberry, Nokia, et al had signed?  Could it possibly have been that the “interoperability” condition was a barrier to Google’s ambition to have something proprietary and, thereby, own as much of the mobile market as they could acquire?  Sounds pretty Googley to me.

So, for all the chatter surrounding this litigation about the importance of “innovation, competition, and future software development,” it must at least be plausibly entertained that Google sought to leverage Oracle’s IP in order to expedite time-to-market while also insulate itself from any liabilities that might obstruct its eventual market dominance.  That would certainly be consistent with the kind of conduct many rights holders in other media have witnessed (see YouTube), and so would Google’s couching its own interests in broad statements like this one: 

“If allowed to stand, the Federal Circuit’s approach will upend the longstanding expectation of software developers that they are free to use existing software interfaces to build new computer programs. Developers who have invested in learning free and open programming languages such as Java will be unable to use those skills to create programs for new platforms—a result that will undermine both competition and innovation.”

Given the different tiers of licensing available for the Java platform, including the free license for app developers, that doomsday prediction does not ring entirely true and, therefore, belies the broad narrative that the future of all software development is under siege by Oracle’s claim.  This is, of course, a familiar pattern among Silicon Valley corporations—especially Google—whereby they emphasize the general value of a system (e.g. a smartphone, a search engine, a social platform) while understating their own interests in the market itself.  And they often achieve this sleight-of-hand by misdirecting public attention to hypothetical “competitors” in the abstract, while in reality, these tech giants have a habit of killing potential rivals before they get out of the lab.  

As stated, I will do my best to dig into some of the specific copyright matters in Google v. Oracle in future posts; but as these stories tend to seep into public dialogue in layman’s terms and PR messaging, this seemed like the right place to start.  The general premise that Google’s needs are inherently society’s needs has worn very thin.  And it’s about time.