Supreme Court API ruling

Dave Tutelman  -  April 6, 2021

The Supreme Court just announced a decision in a legal battle between Google and Oracle. The Court ruled in Google's favor, ruling that Google's implementation of an Oracle API in Java was legal -- not a copyright infringement. In this article, I explain what an API is, and why I feel this was a good and necessary decision. I use a non-programming analogy so that non-programmers can understand it better.
Yesterday (April 5, 2021) the press was astir with reports about the Supreme Court deciding a case in favor of Google over Oracle. As is too often the case, the mainstream media didn't have a clue about the content. Their reports were all about sound bites from the officers and lawyers of Google and Oracle, and how big, bad Google was going to take over the world. The best report I could find was by C|Net, but it requires you understand what an API is and how it is related to a programming language (in this case Java).

In this article, I cover:
  • What an API is, in terms a non-programmer should be able to understand.
  • Why this decision makes sense and should even be generalized, again in non-programming terms.
I will not get into any debates over:
  • Is Google too big, too powerful, evil, etc?
  • Are patents or copyrights or even the notion of intellectual property a bad idea?
  • Is Java a dead or dying language? Should it be?
These are all interesting questions, and I have opinions on each. But not to be discussed here. I will simply assume for discussion purposes:
  • This has less to do with Google or Oracle than the intellectual property content of an API.
  • Society has a need for intellectual property to be protected. Patents and copyrights are [admittedly imperfect] reasonably effective ways to do this. If you think there should be no such thing as intellectual property -- that it should all be public domain -- you won't find this article of interest at all.
  • I like Java. But even if you don't, this is about APIs, not Java. Regardless of programming language, APIs are essential to the software development ecosystem. Our technical society won't function without publicly available APIs.

What is an API

API is an acronym for Application Programming Interface. It is the interface and the set of rules by which an application program can ask for services from another program. For tutorial purposes, here is a very simple example, a message-sending API. (It is not the API in question in the court case.)

An application wants to send a message to some other program, which could be at another location. The application does not have to have all the details of how to send a message in its code. Instead, it could request another program, a message server, to do it. (The term "server" is technical jargon for a program that provides a service to other programs.) The application makes this request through an interface, a "message-sending API". The API is a set of rules for how to pass the information necessary to send a message, and to interpret the information the server passes back.

What would that look like? The information would be a pieces of data telling the server what it needs to know about the message in order to send it, and one or more pieces of data passed back indicating how the server is doing with the request. For instance, some of the Application-to-Server data might be:
  • The address the message is going to.
  • The subject line.
  • The message text.
  • Formatting information for the message text.
  • A list of attachments to the message.
  • Perhaps other stuff, depending on the assumed capabilities of the messaging system. For instance, some messaging systems have optional capabilities like priority or message-was-read notification. If those capabilities are not part of the API, then the application cannot use them.
Some examples of Server-to-Application data would be:
  • Message succeeded or failed.
  • If it failed, why did it fail?
  • An optional capability was requested, but the specific server does not offer that capability. A default will be used.
Why are we talking about APIs as if it is difficult to define them? Just let the programmer of the Application sit down with the programmer of the server and let them hash it out. It'll take maybe an hour, right?

Wrong! In a tiny project, that might work. But a well-designed API can work with a variety of applications and servers. It can connect applications to servers in much greater variety than the original project. For instance, consider the flexibility we could get from a really good message-sending API.

There might be a variety of applications that want to send message, and a variety of ways to deliver those messages. The key is: if all the applications are programmed to use that API, and all the servers are programmed to implement that API, then any of the servers will work for any of the applications. That is the measure of a good, flexible API.

Let's not talk yet about the legal implications yet -- like the Supreme Court decision. Instead, let's build a more familiar analogy to an API. We'll discuss instead an interface -- not a programming interface -- that almost all of us are familiar with, and cast the legal issues in terms of that interface instead of an API.

An analogy

Let's use an analogy to make sense of what sort of intellectual property an API is. Think about a threaded bolt or machine screw. What a marvelous invention! I hope the inventor got lots of credit and lots of wealth from it. (Most sources credit screw threads to Archimedes, so I guess being remembered 2300 years later is ample credit.) But that was so long ago any intellectual property rights would have long since expired. So anybody is free to use the principle of the screw thread.

But people can certainly invent new kinds of bolts and machine screws. For instance, there are lots of head shapes to drive the screw. The picture shows a Phillips head, but there are slotted heads, hex heads, socket heads with different shapes of socket. Overall head shapes can be round, flat, oval, and pan. There are thumb screws and set screws and carriage bolts. Each of these was an invention based on the idea of a screw thread, and might itself be protected as intellectual property. I see no obvious reason they could not be patented.

It is even more obvious that an infinity of gadgets can be fastened with bolts or machine screws. Everything from automobiles to watches to signposts to the computer I am using to write this are fastened together with bolts. Each of these gadgets has the potential of being original enough to be intellectual property itself. (And that originality probably has nothing to do with the bolts that hold it together.) So things we build with bolts might be patentable.

Let's think of the bolts as "fastening servers"; they provide a service of fastening things together. Staying with this metaphor, the things we build with bolts are "applications"; they use the fastening service of bolts, without worrying too much about how the bolts work, just that they do indeed work.
So we have analogies for applications and servers. Is there room for an API in this metaphor? Yes, there is! Let's look at the terminology we use to describe a screw thread. This is completely generic; it applies to round head, flat head, slotted, socket, and every other kind of machine screw or bolt. It applies whether it is made of stainless steel, galvanized steel, brass, or any other material. It is completely independent of whether the screw in question is patented or public domain. It is just a way to talk about screw threads with precision.

Just because we can talk about it doesn't mean we can fit any screw into any threaded hole. That is another step! It is specification. The each term in red in the picture can be assigned a value, a number. If we assign proper numbers to the terms, then we can expect any threaded bolt to fasten into a hole with those numbers.

The final step is standardization. This step chooses a set of numbers for the specifications. For instance, here is a table that specifies metric thread sizes. It is part of an ISO standard that specifies metric thread sizes.

This says if your project requires a bolt of roughly 6mm diameter, you can purchase a standard metric screw of that size -- an M6. The red-shaded numbers tell the manufacturer of the thread the exact size to make it. For instance, it will have a thread pitch of 1mm. The blue-shaded numbers tell the used the drill sizes that will be required in manufacturing the part that the bolt threads into.

There is nothing about the physical world that says a 6mm diameter screw has to have a 1mm thread pitch nor a minor diameter of 4.773mm. An infinite number of choices could have been made. Some would have been very poor choices, but a lot would result in usable screws. So why limit our choice by having a standard specification? Practicality! You don't have to reinvent, or at least redesign, the screw for each use (each "application"). You can design your gadget to use a standard screw and be pretty sure you can order it from a lot of manufacturers of screws. It creates an economy where fasteners can be bought off the shelf rather than being custom built for each potential use.

Let's see how this is a metaphor for an API.
  • The gadget that needs fastening is the application.
  • The machine screw is the fastening server.
  • The table is the threaded fastener API. It tells both the gadget manufacturer and the screw manufacturer exactly what the interface has to be between their components. If the gadget and the screw are built to the specification -- the API -- then everything will fit together and the gadget will be fastened by the screws.
What a huge impact on development and economy an API can have. You can think of this in terms of the screw thread metaphor, but it is equally true for software. If I am building an application, whether software or a physical gadget, I can be reasonably confident that my needs will be served by an available server as long as I build to the API. Similarly, if I build a server, whether software or machine screw, I can be reasonably sure of a market in which to sell my wares if I build to the API. Of course, I will probably also have competition in that market, but that's business.

Why the decision -- even extended to APIs in general -- makes sense

Let's start with the analogy, the metaphor. The server (the screw) can be protected intellectual property. The application (the gadget with threaded holes) can be protected intellectual property. But as long as the idea of a screw thread is public property, then the API (the table of standard thread combinations) is not a protected invention and should not be protected. It is merely a selection from all possible dimensions and an agreement that those are the dimensions we will build to. It would be wrong to give patent or copyright protection to the API because:
  1. Designing it requires engineering effort, but not nearly as much creativity. It is standardization rather than invention.
  2. Having everybody build to the standard is efficient and economical. In the extreme, it may even enable an industry that would not be feasible otherwise.
  3. Conversely, refusing your competitors the use of an interface standard is a monopolistic practice, pure and simple. (I have been a professional in the standards world. Trust me, that is fact!)
All three statements are equally true for a software API if you think about it. Software development is expensive, and reuse of designs makes a big difference in the cost of the software. The whole point of general-use APIs is to mechanize one method for reuse of a server over many applications, or an application over many servers.

The decision -- a closer look

I just made a more broad-reaching argument than the Supreme Court decision did. It is pointed out in the C|Net article:
Google had argued that APIs aren't copyrightable, a stance many developers had applauded. The Supreme Court didn't rule on that point, though, addressing only Google's fair use argument so it had "to decide no more than is necessary to resolve this case."
I just made the argument that the Court avoided, and I believe it to be true.

The Court's decision was more limited and more technical. If you aren't a programmer, there's a fair chance you still won't understand that part. But maybe you will. Here's the reasoning.
  • Java (the computer language) had been owned by Oracle, which made its use free by anybody.
  • Oracle was not arguing that the API specification itself was private intellectual property, but rather that Google had copied Oracle's Java code that operated the interface. So the question was, "Is that a violation of Oracle's copyright for its server?" Certainly, the server code itself is, and should be, protected intellectual property.
  • There is a concept in copyright law called "fair use". It allows unlicensed use of the copyrighted work (usually only a part of that work) if that use meets certain requirements. For instance, if the use is small enough that it does not threaten the potential market for the full work, or the value of the full work.
  • The Court decided that "Google's copying of the Java SE API, which included only those lines of code that were needed to allow programmers to..." pass the required information across the Application Programming Interface. (Anything not in quotes is my paraphrase, not the words in Breyer's written decision.) In other words, it was a very shallow copy, involved only in passing information across the interface, not any actual function in either the application or the server.
I would have liked the court to agree with my conclusion that an API cannot be copyrighted. But I understand -- and support in principle -- that courts should decide only the issue before them, rather than choose to "legislate from the bench".

Last modified  -  April 8, 2021