Who Invented the API?

What is an API? Who was the first to use one? Did anyone “invent” the API as we know it?
These questions are foundational to computer programming and fundamental to the tech industry as a whole. While they are high-level, they certainly have some important legal implications as well, as we’ve seen in recent events.

Today, we address a few basic points concerning APIs with the goal to understand some questions percolating around the API space. We’ll look at the history of the API, and define the nature of the API concept itself. Then, we’ll take an in-depth look at some of the issues surrounding the modern API in a legal sense.

The question of who invented the API is a little like asking who discovered Antarctica – the answers are as varied as the parties that submit them, and there’s little agreement as to a hard and fast date. The question becomes even more complex due to the nature of an API (which we will discuss shortly) – that being said, we can at least start with some of the earliest conceptual formations towards the idea of an API with the work of Wilkes, Wheeler, and Gill.

This article was inspired by an excellent presentation “A Brief, Opinionated History of the API,” delivered by Joshua Bloch at QCon.

Primordial APIs

Maurice Vincent Wilkes, part of the team behind EDSAC. [Source: Wikipedia]

Maurice Wilkes, David Wheeler, and Stanley Gill are considered by many to be the godfathers of programming and software, and for very good reasons – their work in the 40s and 50s would lay the groundwork for much of what would become the software revolution of the 70s and 80s. This revolution would be instrumental in the development of personal computing, and thus the near-ubiquity of personal devices that we enjoy today.

In 1949, EDSAC, or the Electronic Delay Storage Automatic Calculator, was brought to life. Utilizing complex mercury delayed storage systems, EDSAC was extremely powerful for the time. After realizing during the development of his first non-trivial program that he’d be spending the rest of his life debugging his own programs, Wilkes spearheaded work on the program libraries which were introduced for EDSAC in 1951. This work focused on coordinating orders, which allowed the augmentation of initial orders to allow for complex subroutines. The Wheeler Jump was designed during this time, allowing for high order functions utilizing a subroutine linkage technique to call other routines at a specified depth.

The EDSAC’s main memory capacity was 512 18-bit words, filing a large room.

All of this came into being under the EDSAC subroutine library, which was literally a library of paper punch cards holding the various subroutines. This was published in The Preparation of Programs for an Electronic Digital Computer. At the time, this work was not strictly referred to as an applications programming interface, simply due to the fact that everything was monolithic – there were no competing architectures, no legacy programs, and everything was on a single system. That being said, this is arguably the first true incarnation of the concept of the API.

The Evolving Machine

Of course, EDSAC was not the last computer built – and because of this, as new hardware was introduced, new algorithms devised, and new components integrated into existing codebases, the need to port functionality to various hardware and systems at large became obvious and pressing.

Flowchart from “Planning and Coding of Problems for an Electronic Computing Instrument,” 1947 [Source: Wikimedia Foundation]

Perhaps the most important conceptual statement around this problem was in Herman Goldstine and John von Neumann’s Planning and Coding of Problems for an Electronic Computing Instrument – Part II, Volume III. In this volume, the idea that most programs will have to use common operations and a library of subroutines were levied. This concept stated that integrating a known library would result in a dramatic reduction in the amount of new code that had to be developed, as well as the incidence of errors and issues. Unfortunately, this was a very generalized view of the API concept, and as such, didn’t offer much in the way of implementation or guidance, to the point that some modern experts consider it to be akin to “vaporware” – promising a lot, but delivering very little.

Finally, in 1968, the term was first used in a clear way in the paper Data Structures and Techniques for Remote Computer Graphics, presenting at the 1968 AFIPS Fall Joint Computer Conference. As for 2018, this is cited by Merriam-Webster as the first use of the term “application programming interface”, defining the concept as promoting interoperability between a variety of components and systems.

The key takeaway from all of this is a simple realization that is a fundamental nature of APIs – APIs aren’t really “created” as much as they are “discovered”. Any use of a library amongst different applications and systems will necessarily result in a need to tie those uses together, and this tying together is the literal definition of an API. The question as to what was the “first” API is really a meaningless one – the real key as to define what an API actually is.

Also check out: Complying with Tough New EU Rules on Data Protection

What is an API?

Unfortunately, even that is somewhat the wrong question. An API is just an interface between two implementations. The real questions we should be asking are what kind of API we have, and what the nature of that API is.

In our modern perspective, a web API is a smart, programmable doorway for developers to access data from a digital organization.

Generally speaking, something is an API if it does two things: first, it should provide a set of operations defined by inputs and outputs; and second, it should allow reimplementation without compromising its users. Typically, this can be further constrained by suggestions that an API should augment a programming language or set of languages. That last aspect is viewed by some to be far too constricting, as it omits something like an instruction set, which is very much a “hardware” API. For others, that’s the whole point, and omitting that constraint makes the definition far too broad. Either way, when we start looking at APIs, we can broadly sort them into two general categories – device APIs and web APIs.

A device API is one that enables communication at the device level, typically between hardware and software and the interrelated components which enable them. A web API is different, however, in that it allows devices to communicate with one another over different languages, structures, and architectures.

In essence, a web API allows communication between devices almost by considering each whole device as one component in a much larger, interconnected, internet omnibus devices – a “device of devices”, so to speak. In the same way that a device API allows individual components to work together, a web API allows individual devices to do the same.

For more read: What is an API?

Legal Concerns over APIs

So why is all of this important? Right now, we are in a very interesting place when it comes to the legal questions surrounding APIs. For years, the success of APIs and the systems they enable hinged on the idea of reimplementation. Being able to morph code over and over allowed for new APIs and new functions – in many ways, the interoperability of an API is almost second to its reusability in terms of what makes the technology successful.

Despite that, there have been some legal concerns raised around the concept of copywriting an API. In 2010, Oracle launched a lawsuit against Google regarding the implementation of the Java APIs in Android, alleging that Google violated both their patent and their copyright. In 2012, a jury ruled that there was no patent infringement, and the presiding Judge ruled that there was no copyright violation as APIs could not be copywritten. In 2013, Oracle appealed this decision, and in 2014, the presiding US Federal District Court of Appeals reversed the original judgment. Later that year, Google petitioned the Supreme Court to hear the case, which they declined to do the following year, remitting the issue to the lower courts.

In 2016, the Federal Court jury found the use to be fair use, which was appealed by Oracle to the CAFC. In 2017, Stanford and 76 scientists and engineers filed an amicus brief in support of reimplementation, but in 2018, the US Court of Appeals for the Federal District again reversed the finding of the lower court, declaring it not fair use. Google has since petitioned for an en banc hearing.

This takes us to where we are today. As of late 2018, it seems you can copyright an API, which is a stark change from the previous 75 years of relatively free reimplementation. As it stands, you cannot implement an API without explicit permissions from its author. The author is granted near perpetual monopoly on the API, with their copyright extending to 70 years after the life of the author, or a total of 95 years for works from companies and groups.

There are some strong arguments to be made on either side. On the one hand, efforts to create massive APIs are seen by some to be creative works, and in those cases, it’s hard to argue that they shouldn’t be protected. As a counterpoint, the argument for the right to reimplement is that new entrants can better compete with incumbents, resulting in more interoperability, less overall expense, and less time spent litigating exchanged with greater time building.

Conclusion

Ultimately, this piece is not designed to make the argument for or against the copywriting of APIs but instead seeks to provide context to both the history and the near future of the API landscape. Whether or not APIs return to their relatively free and open historical past or whether they continue to be considered “intellectual property” that is copyrightable, this topic will only grow more complex and complicated.