Once the die was cast (i.e. after oral arguments) in Google v. Oracle, I don’t think I was alone in feeling that if the Supreme Court held that the computer code at issue in this case was not properly a subject of copyright protection, that would be an acceptably narrow decision, even though many might disagree with it as a statutory reading.1 On the other hand, I and others felt that if the Court held Google’s use of Oracle’s code to be a fair use, that would be potentially harmful to copyright law in general, and perhaps a disservice to many parties with an interest in this case—except of course to Google.
The argument against the copyrightability of the code at issue (a.k.a. declaring code or APIs), was founded on the merger doctrine, which holds that where an expression and its idea or function are inextricably bound together, the expression cannot be protected by copyright. Here, the majority opinion, written by Justice Breyer, declined to address that consideration, instead stating that “for the sake of argument,” the Court would assume the code is protected, and then it still delivered an opinion on the copyrightability question by couching it in a fair use analysis.
Although the Court did state that the decision is unique to software and does not “overturn or modify earlier cases involving fair use,” we must hope that summary can be reconciled with the part of the opinion which states, “The upshot, in our view, is that fair use can play an important role in determining the lawful scope of a computer program copyright, such as the copyright at issue here.” That is a troubling generalization, which forces the fair use doctrine (a case-by-case defense) to do what the Court otherwise could have done instead, which would have been to write an opinion limiting the statutory protection for the code at issue, and also limit its own finding. In that instance, fair use should not even be considered. Instead, the Breyer opinion asks fair use to do something it is not meant to do.
As a result, this outcome not only could disturb case law, but it also falls short of providing the market certainty many in the software business were seeking in the briefs filed on behalf of Google. For instance, the brief signed by 83 computer scientists stated, “Forcing companies that reimplement APIs to rely on fair use will not meaningfully address … anticompetitive effects. Though better than nothing, a fair use standard creates uncertainty because it depends on fact-intensive, case-by-case determinations which can result, as this case demonstrates, in lengthy and expensive litigation.”
So, rather than providing that hoped-for certainty, by either accepting or rejecting the merger argument, it is notable that the opinion instead asserts factor two (nature of the protected work) of the fair use test ahead of factor one (purpose and character of the use) in order to frame its conclusion with a lengthy discussion about what declaring code does and why the Court agrees it is distinguishable as an unprotectable type of code. The opinion states: “It is inextricably bound together with a general system, the division of computing tasks, that no one claims is a proper subject of copyright. It is inextricably bound up with the idea of organizing task into what we have called cabinets, drawers, and files, an idea that is also not copyrightable.”
That is extremely close to saying the code at issue fails for copyright protection under merger. So, why didn’t the Court just go ahead and make that finding rather than risk sowing added confusion by stuffing a pseudo copyrightability opinion into prong two of a fair use analysis? Because now, it is possible that a greater number of parties will be disserved by this outcome.
Perhaps what happens in the market should not weigh too heavily where the Court restricts its opinions to questions of law, but this opinion makes clear in its fourth factor analysis that it is terribly concerned about broad market effects. And its assumptions about the market, especially the implications beyond software, seem divorced from reason as a fair use consideration. The factor four opinion suggests the majority was unduly persuaded by the argument that Sun was unsuited as a developer to create a product like Android. “…evidence at trial demonstrated that, regardless of Android’s smartphone technology, Sun was poorly positioned to succeed in the mobile market.” That is potentially a market-devastating view, and here’s why:
First, if a party authors a work that some other entity is potentially better at exploiting, that is grounds for licensing the work, not appropriating it. Consequently, the Court’s failure to hold, in a more straightforward ruling, that the code copied was not protected fosters this more insidious interpretation of “market harm” in its fourth factor analysis.
Second, the biggest gorilla in the sandbox just got a bonus prize. After all, won’t a company like Google always have the resources and capabilities to build the next doodad faster and better than another entity? But in Google v. Oracle, to “level the playing field,” the Court just held that a startup which cannot compete with the Googles of the world, may not necessarily license its IP to the giants either, depending on how one interprets this fourth factor reasoning. Because let’s remember, Oracle ain’t exactly a startup.
Third, imagine we are looking beyond software, and this fourth factor opinion can be argued to mean that, for instance, the novelist who is “poorly positioned” to make a film adaptation of her book is subject to a similar finding in relation to a film studio appropriating her work. Granted, that’s a bit extreme, and she would, we hope, be protected by other considerations in the law. But I use the example to underscore how flawed this view of “market harm” is as a matter of principle.
All the ink spilled in this part of the opinion, lauding the value of smartphones, the quality of the Android system, etc. is an argument that only proves market harm to Oracle due to the failure by Google to obtain a license—and one that simply waves a hand at any implication of the derivative works right. “Given the costs and difficulties of producing alternative APIs with similar appeal to programmers,” the opinion states, “allowing enforcement here would make of the Sun Java API’s [sic] declaring code a lock limiting the future creativity of new programs.”
That language, which connotes a hostility to copyright in general, upends the law by failing to acknowledge that licensing works does not lock up works. We have over 200 years of evidence and jurisprudence to back up that general premise. But again, if this Court accepted the market rationale for this outcome, then it should have held the code at issue unprotectable rather than write a fourth factor “market harm” analysis that describes any rightsholder as “poorly positioned” to exploit a particular use of their works.
By transforming a copyrightability opinion into a fair use analysis, the Court seems to have fallen for the temptation to limit copyright’s protections based solely on works already developed, while failing to more expansively imagine works that may or may not be developed in the future. Aside from the potential damage done to other copyright subjects by this fair use holding (despite the Court’s caveat), the opinion does little for the next software venture, except to tell its principals that when a Google-scale behemoth appropriates some amount of their code, they may be about a decade’s worth of litigation away from finding out if there’s a remedy. And the number of new ventures that can afford that is zero.
