Good morning,

As noted in the Daily Update Schedule, I am taking the next two days off for a small vacation with my family. I’ll be back on Monday.

On to the update:

Google Versus Oracle

From the Wall Street Journal:

The Supreme Court ruled for Alphabet Inc.’s Google in a multibillion-dollar battle with Oracle Corp. over elements of Google’s Android smartphone-operating system, a decision that could weaken software copyright protections but allow developers more room to build on each other’s products.

The court, in a 6-2 opinion Monday by Justice Stephen Breyer, threw out a lower-court ruling for Oracle that said Android infringed its copyrights on the Java software platform. The high court said Google’s copying of some Java API code was fair use. APIs, or application programming interfaces, are prewritten packages of computer code that allow programs, websites or apps to talk to one another…

The ruling didn’t do away with copyright protections for APIs but dealt a blow to them nevertheless, a potential setback for companies that hold copyrights in software platforms that took considerable time and money to build.

This case has been a ten-year odyssey:

• Google won at trial, where the District Court ruled that copyright did not apply to APIs (more on this in a moment).
• The Court of Appeals for the Federal Circuit (which specializes in patent law — this case started with Oracle claiming patent violations) overturned the decision, and remanded the question of fair use.
• The District Court ruled that Google’s usage was fair use.
• The Court of Appeals for the Federal Circuit again overturned the decision.
• Yesterday’s decision overturns the Court of Appeals for the Federal Circuit, declaring that Google’s usage of the API was fair use; the decision did not address whether or not APIs could be copyrighted.

Given this long-and-winding history, my analysis is going to be a bit long-and-winding too — I’ve gone on my own journey with this case.

Start with the endpoint; as I tweeted yesterday,

That tweet is quoting this Daily Update, where I examined the four factors that go into a fair use determination:

Those four factors are:

• The Transformative Factor: The Purpose and Character of Your Use
• The Nature of the Copyrighted Work
• The Amount and Substantiality of the Portion Taken
• The Effect of the Use Upon the Potential Market

I believe that Google has a strong case:

• The Java APIs were used for a completely new runtime (transformative), but that new runtime was highly commercial (which favors Oracle)
• While Java as a whole is a creative work (including the APIs), APIs are for implementing interoperability, making them much more akin to factual information that is looked upon more favorably in fair use determinations
• Google took only the APIs from Java, nothing else
• Google can argue that Java was not widely used in mobile prior to Android, but Oracle will argue that there is a licensing market that they were unable to participate in

Stephen Breyer’s majority opinion first established that they were not going to address the question of copyright:

To decide no more than is necessary to resolve this case, the Court assumes for argument’s sake that the copied lines can be copyrighted, and focuses on whether Google’s use of those lines was a “fair use.”

After that the reasoning about fair use was similar to my argument (albeit in a slightly different order):

• The nature of the code was “a part of a ‘user interface’ that provides a way for programmers to access prewritten computer code through the use of simple commands,” and thus differentiated from “the code that actually instructs the computer to execute a task.”
• Google “copied only what was needed to allow programmers to work in a different computing environment without discarding a portion of a familiar programming language”; in other words, applying the API to smartphones instead of servers or desktops was transformative.
• While 11,500 lines of code is a considerable amount, the majority ruled it was a small amount relative to the entire Java code base, and that “as part of an interface…they would allow programmers to bring their skills to a new smartphone computing environment.”
• The majority found that Android was not a substitute for Java SE, that Java benefited from the reimplementation of its interface, and that finding in favor of Oracle would cause “creativity-related harms to the public”.

The court also made clear that questions of fair use were a matter of law, not facts, which means that applicability should be determined by judges, not juries; given the deferences that judges (appropriately) give precedent, that effectively means that reproducing APIs will always be held as fair use.

This, as a practical matter, is a very good outcome. As the majority made clear, APIs are interfaces; being able to copy an interface means the ability to create an interoperable product. I gave some examples in that Daily Update:

For example, in Antitrust and Aggregation, I wrote about the Samba project that made it possible for non-Windows PCs to join Windows-based networks; this was done by re-implementing all of the necessary software behind “copied” APIs. WINE, which makes it possible for Windows applications to run on Linux, does the same thing: the applications are written to interact with Windows APIs, so WINE “copies” those APIs and then implements a clean sheet solution that responds to the applications in a way they expect. It’s the same idea behind Xamarin’s Mono, the Microsoft project that makes it possible to write cross-platform mobile apps, and there are many, many more examples, nearly all of which work against lock-in, something that is absolutely to the benefit of end users.

This can work in favor of dominant platforms, as well; cloud providers like AWS, for example, can create their own implementation of software with an identical API, differentiating based on scale. Or a social network like Facebook could mimic the functionality of an app, but augment it with access to its network. Or Google could — and in fact did — jump start a developer ecosystem by copying an API developers were already familiar with and marrying it to a new operating system tied to a business model built on Google’s unassailable advertising business. That doesn’t seem so fair!

Copyright and APIs

This was the core contention of Justice Clarence Thomas’ dissent:

Oracle spent years developing a programming library that successfully attracted software developers, thus enhancing the value of Oracle’s products. Google sought a license to use the library in Android, the operating system it was developing for mobile phones. But when the companies could not agree on terms, Google simply copied verbatim 11,500 lines of code from the library. As a result, it erased 97.5% of the value of Oracle’s partnership with Amazon, made tens of billions of dollars, and established its position as the owner of the largest mobile operating system in the world. Despite this, the majority holds that this copying was fair use.

Thomas argued that the Court’s fundamental mistake was ignoring the copyright question:

The Court reaches this unlikely result in large part because it bypasses the antecedent question clearly before us: Is the software code at issue here protected by the Copyright Act? The majority purports to assume, without deciding, that the code is protected. But its fair-use analysis is wholly inconsistent with the substantial protection Congress gave to computer code. By skipping over the copyrightability question, the majority disregards half the relevant statutory text and distorts its fair-use analysis. Properly considering that statutory text, Oracle’s code at issue here is copyrightable, and Google’s use of that copyrighted code was anything but fair.

I think that Thomas is half right and half wrong: he is right that the majority should have considered the copyright question. If they had, though, it seems clear to me that the majority would have — and should have! — found that APIs are not copyrightable. The definition of copyright states:

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

When the majority is meticulously detailing how an API is a way to access functionality — “the declaring code’s shortcut function is similar to a gas pedal in a car that tells the car to move faster or the QWERTY keyboard on a typewriter that calls up a certain letter when you press a particular key” — it is quite clearly describing a “method of operation.” APIs are how you operate a program, and they should not be copyrightable.

I have to be honest: I have had this completely wrong throughout the case. I have repeatedly made a utilitarian fair use argument in favor of Google that implicitly conflated APIs with application code as far as copyrightability is concerned — as Thomas does in his dissent — even as that utilitarian argument rests on the difference between APIs and application code (which Thomas gets wrong)! I do feel particularly bad because I know several of you have argued with me about this, but for some reason seeing the Court make the same argument I have been making for years is what finally made me realize that the argument doesn’t actually make sense. APIs should not be copyrightable, for all of the reasons that the majority used to say why copying them is fair use. In other words, right outcome for the right reasons, but the wrong means, if that makes sense.

Copyright Tradeoffs

One of my continued complaints about the current state of U.S. IP law is that the Court of Appeals for the Federal Circuit in particular has forgotten that the point of copyright and patents is more creativity and innovation, not simply patents and copyrights for their own sake; to go back to that same Daily Update I referenced above:

Ultimately, what makes this case and pretty much every other intellectual property dispute so frustrating is the degree to which the purpose of intellectual property law has been perverted: the entire point is to preserve the incentive for the creation of new intellectual property, but in the case of technology broadly and markets governed by Aggregation Theory specifically, the incentive to create intellectual property could not possibly be greater, matched only by the risk to the public of the monopolies that are the inevitable result.

What would be most beneficial would be clear legislation governing software that ideally follows the framework I laid out above: no patents, full copyright, with APIs explicitly exempted from copyright (and, if you want to get radical, mandatory disclosure and documentation). Sadly, given the state of the U.S. political system, that seems highly unlikely, so our best hope rests in the hands of a jury in Silicon Valley.

Again, I’m now convinced that APIs ought to be explicitly exempted from copyright by the letter of the existing law; the outcome of this case is that they are exempted by matter of precedent. What is just as encouraging, though, is that the majority spends a lot of time making the case that copyright is a means to an end, and that that end is innovation and creativity broadly. From the case:

Copyright and patents, the Constitution says, are to “promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.” Copyright statutes and case law have made clear that copyright has practical objectives. It grants an author an exclusive right to produce his work (sometimes for a hundred years or more), not as a special reward, but in order to encourage the production of works that others might reproduce more cheaply.

At the same time, copyright has negative features. Protection can raise prices to consumers. It can impose special costs, such as the cost of contacting owners to obtain reproduction permission. And the exclusive rights it awards can sometimes stand in the way of others exercising their own creative powers.

This was actually an important factor in why the court said that the consideration of the market impact favored Google; there are more parties impacted than simply Oracle:

Given programmers’ investment in learning the Sun Java API, to allow enforcement of Oracle’s copyright here would risk harm to the public. 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 declaring code a lock limiting the future creativity of new programs. Oracle alone would hold the key. The result could well prove highly profitable to Oracle (or other firms holding a copyright in computer interfaces). But those profits could well flow from creative improvements, new applications, and new uses developed by users who have learned to work with that interface. To that extent, the lock would interfere with, not further, copyright’s basic creativity objectives. After all, “copyright supplies the economic incentive to [both] create and disseminate ideas,” and the reimplementation of a user interface allows creative new computer code to more easily enter the market.

This in part touches on the fact that APIs are a “method of operation”, which I discussed above. In addition, the majority is arguing that the knowledge of how to operate something is in effect the property of the knowledge holder, not the something creator. More importantly, the majority recognizes that copyright is a trade-off, not an end in and of itself. Maybe the Court of Appeals for the Federal Circuit will finally get the hint.

---

This Daily Update will be available as a podcast later today. To receive it in your podcast player, visit Stratechery.

The Daily Update is intended for a single recipient, but occasional forwarding is totally fine! If you would like to order multiple subscriptions for your team with a group discount (minimum 5), please contact me directly.

Thanks for being a supporter, and have a great day!