Supreme Court API ruling

• 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.
  

• 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

• 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.
  

• 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.
  

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

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!)

The decision -- a closer look

• 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.