This is a short series not so much about Amazon, Facebook and Google themselves, but rather the America that has fallen into those companies’ lengthening shadows
for an introduction to this series and “PART I – Amazon is a country, and we are all its citizens” click here
for “PART II – The new/not new Facebook leak” click here
PART III
Google gets the Supreme Court to change patent law
21 April 2021 – The United States Supreme Court recently ruled that Google’s use of another software company’s code in building its Android platform was permissible under the fair use doctrine. The decision comes after 10 plus years of litigation on the issue. The long-awaited verdict establishes a groundbreaking precedent in the world of coding and intellectual property as a whole. However, certain questions remain unanswered as to how Big Tech may develop competing programs moving forward. My opinion: it was a horrible decision.
Back in 2010, the software company, Oracle, filed a lawsuit accusing Google of plagiarizing its Java software. Oracle alleges Google copied 11,500 lines of computer code to create its Android mobile device. At the time, Oracle had recently acquired Java, a programming and computing platform used by software developers. When Oracle acquired Java, it became the owner of a number of patents and copyrights. As alleged in Oracle’s complaint against Google, Google’s Android device was a competitor of Oracle’s Java, with Google running Java applications on its own device. Oracle alleged numerous patent and copyright infringements against Google for its use of Java API code and sought $9 billion in damages.
Copyrighting computer code has required intricate legal review. On one hand, a programmer may copyright a complete computer program as a literary work. However, a programmer cannot claim a copyright in an “idea, system, or method indirectly, by copyrighting one of only a few possible means of expression.” This would grant them exclusive use of the idea itself—something that is not copyrightable.
The United States District Court for the Northern District of California ruled in May 2012 that Java’s API – Application Programming Interface – code was not copyrightable. But in May 2014, the Federal Circuit reversed the district court’s decision. This left open the possibility of a viable fair use defense. And Google successfully invoked this defense at trial.
NOTE: API is a software intermediary that allows two applications to talk to each other. Each time you use an app like Facebook, send an instant message, or check the weather on your phone, you’re using an API. The best example of an API is when you use an application on your mobile phone. The application connects to the Internet and sends data to a server. The server then retrieves that data, interprets it, performs the necessary actions and sends it back to your phone. The application then interprets that data and presents you with the information you wanted in a readable way. This is what an API is – all of this happens via API.
And as I noted in Part II of this series, many companies now make their data available through these APIs, the digital “hooks” that others can use to connect to their systems. This reflects the creeping automation in the information realm.
In May 2016, a jury ruled in favor of Google. It found their use of the Java code was permissible under the fair use doctrine. The Federal Circuit again reversed the district court’s decision, finding Google’s use was not fair use as a matter of law. Following this reversal, the case reached the highest court in the land.
The SCOTUS Decision
The Supreme Court held that Google’s use of the Java code was a fair use of the material. Per the decision, this is permissible because Google only included those lines of code “that were needed to allow programmers to put their accrued talents to work in a new and transformative program.” The Court declined to determine whether the copied lines were copyrightable under the Copyright Act, and for the purposes of the decision, assumed that they are. The main question before the Court was whether Google’s use of those lines of code was a “fair use” as permitted by § 107 by the Act.
In order to determine fair use, the Court evaluated four factors:
1. The purpose and character of the use
2. The nature of the copyrighted work
3. The amount and substantiality of the portion of use in relation to the work as a whole
4. The effect on the potential market or value of the work
The Court found in Google’s favor for all four factors. First, the Court found that the lines of code, which are a part of a user interface, allow programmers to access prewritten computer code that is “inherently bound together with uncopyrightable ideas.” The Court found Google copied only what was needed to allow programmers to work on new ideas, consisting of only “0.4% of the entire API at issue.” Lastly, the Court found that Java’s copyright holder would only benefit from reimplementation of its interface into a different market.
The Supreme Court’s decision will certainly make it easier and cheaper to implement code in software applications. With this decision, new developers won’t need to start from scratch in writing code. They can also bypass purchasing licenses from Oracle and other companies for the use of their code.
However, it’s important to remember that the Supreme Court did not rule on the copyrightability of code itself. In fact, the Court seemed to want to avoid the question of whether API code is copyrightable. Justice Breyer acknowledges in the majority opinion that it is “difficult to apply traditional copyright concepts in that technological world.” Many legal pundits believed the Court should have stated APIs are not copyrightable, but thought such a decision would probably be very close to legislating from the bench.
But you know what? The Court legislates from the bench all the time, and this ruling probably has almost the same practical effect. So the question of code copyrightability remains an open legal item. However, the Supreme Court’s decision clearly expanded the permissible use of existing APIs in Big Tech for the foreseeable future.
And that is where I have issues.
My thoughts on the case
My street creds. After university I spent 3 years on Wall Street, learning about *real* life in the commercial and legal world: first as a currency trader, hired for my minor degree (physics) funnily enough. The physics behind trading and technical analysis is an interesting story but it needs a separate post. I then stumbled into a position as a software analyst because the proprietary trading software we were using at my firm was going to be licensed and my trading firm set up a special unit to handle that licensing.
I graduated law school in 1979, and it was perfectly timed. In 1979 the compact disc was invented, the first commercial spreadsheet software, VisiCal, was released as well as the first commercial word processing software, WordStar. In 1980 Microsoft released the first version of its MS-DOS/PC program. And in 1980 software litigation went full throttle after the U.S. Supreme Court decided computer programs were patentable.
I was back on Wall Street and my law firm was preparing for battle – and influence. I was seconded to D.C. as part of a team to work on the “Computer Software Copyright Act of 1980” which was the first significant amendment to the “Copyright Act of 1976” to allow for adjustments to copyright law to take on board computer programs. We did not write any actual legislation but were there merely to assist Congressional staffers to understand the Brave New World. But frankly we were able to influence the interpretation of certain legal concepts – the whole point of our being there.
Of course I’ve followed software development and copyright and a host of related topics through the years, the subject of many of my blog posts. But I have not done much analysis of specific court decisions. But the present case is a doozy. There is a lot to say but I’ll limit my comments to just a few points.
I am not alone in thinking 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. In the present case 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.
And I am fed up with the Court sticking its ass where it knows zip. 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 (see 1-through-4 above) 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 my colleague David Newhoff has nailed this with a touch more elan than I so here is his take:
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, 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.
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.
* * * * * * * * * * * * *
Next up, tomorrow ….
Apple’s new hardware is built for our visual future
As I have been banging on ad nauseam, two decades into the new millennium it is pretty apparent that hardware without software and smarts is nothing more than a gimmick. Apple’s product launch event yesterday was a timely reminder of this new hardware reality. The new iMac video cameras and the new iPad Pro’s front-facing cameras are a big step toward our visual future. Ever since the pandemic began, and we started to live most of our lives on Zoom and its video conferencing cousins, we have complained about the poor quality of video cameras inside our computers. Apple computers, especially.
And tech note: the new iPad Pro has a 12 megapixel camera for video calls, and the new new iMac is 1080p. There are no video call services that support 4K. Most are capped at 720P. So we can expect all video call services to up their game.
Technology informs art, and art informs technology. The two are inseparable and interconnected. And navigating the complexities of visual culture are … well, complex. The visual surrounds us, some of it invited, most of it not. In this visual environment, everything we see — color, the moon, a skyscraper, a stop sign, a political poster, rising sea levels, a photograph of Kim Kardashian West — somehow becomes legible, normalized, accessible. Some thoughts on the bigger tech/cultural picture, beyond our business Zoom chats.