I am gearing up for API copyright heading to the Supreme Court, having another look at whether or not the naming and ordering of your API interface is copyrightable, as well as whether or not reimplementation of it can be considered fair use. To help strengthen my arguments that API should not be copyrightable I wanted to work through my thoughts about how APIs are similar to other existing concepts that are not copyrightable. One of the new concepts I’m looking at understanding better, and add to my toolbox of API copyright arguments is the blank form, which APIs resemble in more than one way.
As I was refreshing my understanding of what copyright is and isn’t I was working my way through Copyright.gov, and found this snippet about the copyrightability of forms—which I think applies pretty nicely to what APIs accomplish in a digital way.
Blank forms typically contain empty fields or lined spaces as well as words or short phrases that identify the content that should be recorded in each field or space. Blank forms that are designed for recording information and do not themselves convey information are uncopyrightable. Similarly, the ideas or principles behind a blank form, the systems or methods implemented by a form, or the form’s functional layout are not protected by copyright.
A blank form may incorporate Works Not Protected by Copyright 4 images or text that is sufficiently creative to be protected by copyright. For example, bank checks may be registered if they contain pictorial decoration that is sufficiently creative. Contracts, insurance policies, and other documents with “fill-in” spaces may also be registered if there is sufficient literary authorship that is not standard or functional.
In all cases, the registration covers only the original textual or pictorial expression that the author contributed to the work, but does not cover the blank form or other uncopyrightable elements that the form may contain. Examples of blank forms include • Time cards • Graph paper • Account books • Diaries • Bank checks • Scorecards • Address books • Report forms • Order forms • Date books and schedulers.
APIs are forms — often times literally. Whether a language, framework, or web API, each API is a blank form waiting to be submitted. It contains one or more fields or parameters that can be submitted or retrieved. Like forms, APIs may contain copyrightable content or algorithms, but the interface themselves are just a title applied to give the API context, and a set of words organized in a certain order to solicit a specific response. Like a physical form, APIs can represent many types of resources, depending on how you organize the fields and parameters, providing a pretty versatile and flexible way to communicate online.
The challenge here for most business and technical folks is separating the API from the backend code, and the content, media, and algorithms flowing through the API pipes. Your API is nothing more than just a menu, form, and recipe for making digital resources available via the web. While they may feel like you’ve created something unique, special, and are a form of expression—they aren’t. We can’t let the creative bar be so low. We also can’t attach copyright friction to the interfaces that are desktop, web, mobile, device, and network applications will use to provide access to our valuable resources, which may or may not include copyrightable, patentable, and trademarked elements.
