It’s a valid question, and I think in the case of Oracle the appeals court did indeed buy into the argument that a large collection and arrangement of these small APIs did amount to something creative therefore deserving of copyright protection.

I’m not trying here to argue there is no creativity in such work. There’s some creativity in designing a power socket, for example. Rather, I’d say the interoperative purpose of specifying such machine interfaces means that we as a society should not allow copyrights to be placed on them, because there is an overriding value to the public in allowing multiple implementations and in allowing interoperability.

Software is often akin to a machine in that is has functions and must connect to other pieces of hardware and software to operate. Software is a functional piece of many machines. Sometimes it is also artistic or entertaining in nature, but for now let us just consider the more machine-oriented uses of software. Things like a database being a tool to store and retrieve data, or an operating system or hardware driver or a programming language that allows your computer or phone to run. This kind of software clearly must move data around, and operates rather like a machine.

An electrical analogy may be useful. A single function’s interface is an API, and I’ve used the analogy of a single power socket. There’s a little creativity there. A collection of function interfaces is also an API, just a larger one. Think of a collection of mathematical operations for doing trigonometry, e.g. sine, cosine, etc. The electrical analogy might be a power board with many sockets arranged with switches and a power light. You might say there’s more creativity there, because there’s an arrangement of smaller APIs into a single, bigger API. The question is at what point should we say "this collection now meets some criteria that mean it now can be owned by only a single company, rather than being available to all?"

As an engineer, I’d like a clear line to be drawn so I know where that line is. I don’t think the law can or will supply such a clear line. That creates risk for companies and individuals in implementing any software. I think that lack of clarity is to the net detriment of society.

I think there is a clear line that can be drawn in many cases between API interface, and implementation. The API is the name of the function (with some input/output specification), whereas the implementation does the work. It’s long been accepted in the industry that the implementation can be subject to copyright, but the present dispute is about the widely held belief that APIs were not copyrightable, when now it seems some US courts may hold otherwise. Google acted on that widely held belief and got burned, but this is surprising to many in the industry. It upends entire industry wide practices such as clean room reverse engineering, for no clear benefit. Reverse engineering allows companies like AMD for example to use the same silicon chip instruction sets, so as to compete with the likes of Intel and NVidia (which promotes competition via different implementations).

Here’s a car analogy: An individual API might be the shape of a steering wheel. Another small API might be a gear change stick. Another might be a pedal for the brake, and another pedal for the gas. Put these things together and you have a larger API. You might say that’s more creative. Let’s say Benz invented that. Allowing copyright on that larger collection would force other car manufacturers to do one of two things: either pay Benz a licensing fee (perhaps until the end of time) to use the same arrangement, or else each car manufacturer must invent their own unique arrangement of controls, and possibly even their own kind of controls too (think hexagonal steering wheels or joysticks in some car models). I argue both outcomes are not useful in the long run to society, and we should curb copyright at the interface.

I’ll reply to this statement more directly:

Is it true that an API is merely a collection of very many such functional definitions? (a curated list of your favourite recipes) Might that length have an impact on copyright law? (substantial novelty)

Although I have a different idea of what an API is (since I believe the term is wide enough to encompass even a single function declaration), the important point in the above quote is the term "curated list", in particular the word "list" (I would actually use the term "index" or "table of contents").

All analogies can be fraught, but let’s go with a recipe book analogy, in order to examine why the term "recipe" is incorrect. A single recipe is a procedure for making something happen. It’s like an algorithm in computer terms. A recipe is thus very much like an implementation. However, the name of the recipe is its API, its functional declaration. Just as "Salmon Salad" give you an idea of what the recipe might entail without telling you the details (the specific recipe), so too does the function name CalculateCircumference reveal something about what that software function might do, without really telling you the implementation.

If we’re talking about a "curated list of recipes", that is a larger API that is akin to a recipe book’s table of contents. You might say a recipe book is large and inventive and is deserving of copyright, and fair enough, but what of its table of contents? Does having all the fish recipes listed before the poultry with the desserts at the end of the book constitute sufficient novelty to be deserving of copyright protection? What of having "Salmon Salad" right before "Crab Soup"? Should a cookbook author be able to sue any other cook who writes a cookbook having identically named recipes in the same order (despite the actual recipes being different) just because the table of contents can be copyrighted? Because to me that’s what the Oracle ruling seems to boil down to (please excuse the pun).

The table of contents of a recipe book is like the API, but the implementation is the actual recipes. Google took the Sun Java APIs (freely given away by Sun) and implemented their own recipes behind the scenes. But for the sake of interoperability, they used the same recipe names, in the same order. They copied the table of contents, but invented their own recipes within their recipe book.

The question of whether the length of a list should impact the copyrightability seems to me to be the wrong question to ask. There is a difference in copyright law between the idea and the expression of the idea. In theory, copyright should cover only an expression, not the idea itself. An API is, like a table of contents in a recipe book, merely a collection of ideas albeit in a specific order, whereas it is the implementations, the recipes, that are the expressions of those ideas. This distinction between API and implementation mirrors the distinction made in copyright law between idea and expression, so it seems to me APIs shouldn’t be copyrightable any more than ideas should be, and thus that’s the correct place to draw the line between what is and isn’t copyrightable: between the interface(API) and the implementation.