Supreme Court API ruling
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
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:
I will not get into any
- What an API is, in terms a non-programmer should be able to
- Why this decision makes sense and should even be generalized,
again in non-programming terms.
These are all interesting questions, and I have opinions on each. But
not to be discussed here. I will simply assume for discussion purposes:
- 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?
- 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:
Some examples of Server-to-Application data would 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.
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.
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,
- 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.
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
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
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
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.
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.
- The gadget that needs fastening is the application.
- The machine screw is the fastening
- 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.
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:
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.
- Designing it requires engineering effort, but not nearly as much
creativity. It is standardization rather than invention.
- 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.
- 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!)
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.
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".
- 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
- 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.
modified - April 8, 2021