> I cannot reconcile this sort of argument with the Baker v. Selden precedent.

Contemporary judges, including on the Supreme Court, aren't interested in reconciling Oracle's argument with Baker v. Selden; there's no love for Baker. Courts may pay lip service to the notion that ideas can't be copyrighted, but the prospect of ruling as a matter of law that specific, concrete categories of works are categorically not copyrightable (especially if they're not patentable) seems illogical to them. Previous hard exclusions, like those related to automobile designs, textiles, and databases are already on the way out, unfortunately, just like the idea that entry into the public domain is a one-way street. The case law has been slowly moving in this direction for at least 20 years, but it's too painful for many to admit despite judges (e.g. Ginsburg) being crystal clear about the direction they want to take things.

Judge Alsup's original opinion declaring APIs not copyrightable is brilliant and the best argument anyone could possibly make. It is the best argument, period, IMO. But the basic premise is just anathema to the majority perspective on courts' role regarding the application of copyright law.

I'm not going to argue whether I think APIs should be copyrightable, but I believe creating a good API is a work of creative design, and is artistic

I design an API for graphical coding and spend significant creative energy choosing the right words, calling conventions, result types to not only make something intuitive, but emotionally pleasurable to code with

Sometimes I'll spend days writing out possible forms of the API — changing words, tense, syntax, until it looks and feels "right." These aren't arbitrary or purely functional decisions

Do I want my users to "read" text from a file, or "open" the file? Do I want them to handle keyboard events in a simple global function or assign callbacks into a keyboard handler under each character name. How are those callbacks shaped? What's easy to understand?

APIs aren't just restricted simple functions and types. Some may involve the creation of a custom DSL to make it easy to declare functionality in part of your system, or clusters of protocols that work together in very specific ways so users can implement a complex system atop them

The Google v. Oracle argument hinges on Structure, Sequence, and Organization[1]. Things like the actual package structure arguably involve creative decisionmaking, and are not strictly analogous to something like accounting methods. For example, even if the idea of a max() function that takes two integers and returns the larger of the two is not copyrightable, the specific name "java.lang.Math.max()" might still be. Especially if you're talking about not just one function, but some enormous number of methods in some large number of classes across 37 different packages.

[1]: https://en.wikipedia.org/wiki/Structure,_sequence_and_organi...

> “ Selecting and arranging recipes requires creativity. I do not believe API design of a math library is in any way the same level, having designed hundreds of APIs and several SDKs myself.”

I have designed hundreds of APIs and SDKs myself as well and I could not disagree with you more.

API design is about deliberately and creatively considering the domain model of your user (whether that domain is Int or Float for a user who is a low level system programmer or the domain is CheckingAccount and SavingsAccount for a user who is a banking application developer, or anything in between or beyond). You creatively set up APIs so that composition of the API primitives allows direct expression of solutions in the user’s domain.

This is exactly like arranging recipes in a recipe book, to organize sections for different styles, meals or amount of prep time, holiday themes, etc. That is exactly software API design to a tee.

This article highlights it for me:

https://blog.keras.io/user-experience-design-for-apis.html

The difference is that Baker didn’t involve literal copying of the accounting tables. Baker is treated as a merger case, but it’s more a case about the difference between copyright and a method patent. Baker claimed that copying the general structure of the tables was infringement. The court essentially held that the structure that was copied was the structure dictated by the method itself. And Selden couldn’t copyright any table that had the same structure because that would give him a monopoly on the method.

Here, the Java APIs were copied literally. For example, say you’ve got a function to append an item to a list:

Append(item, list) Append(list, item)

If you changed the order of the parameters, you wouldn’t be literally copying, even though it’s the same basic signature. That’s the Baker case. You can’t monopolize the method of appending an item to a list by extending copyright to all possible permutations of the limited ways to write the signature.

But what happens if you do literally copy? That’s this case. Then, the question is whether these choices of where to put the parameter reflect any creativity.

I happen to think they do—I strongly prefer the first form, which is how it’s done in the Common Lisp standard library.

Can you clarify how you think Baker applies here? The underlying point from that case is that an accounting method is an idea and copyright protection does not extend to ideas, only specific expressions of that idea. I'm not sure the situation here is all that similar.

> accounting methods are not of themselves copyrightable creative works.

True. Neither are 'ways of calling library functions" copyrightable.

But in the case of Java API what was copied was the actual Java-code in which the APIs are expressed.

Because the APIs are "fed" to the compiler as Java source-code, it is clear what was copied was not just the "way library-functions are called".

What was copied was Java SOURCE-CODE which allows a Java compiler to ENFORCE and INTERPRET such calling conventions.

Even if the API was rewritten in another programming language it would be a copyright violation if large parts of the structure of the API meaning how the methods are organized into classes and interfaces and how they refer to each other, was copied. That would clearly be a work of art that deserves copyright protection, in my view.

I think people get thrown off because an API is describe through lots of text and can be huge, where as other things are just a layout. The recipe book itself is copyrightable but the language used to describe the recipe isn’t.

I am a software engineer and it is certainly NOT open and shut for me. APIs are code definitions just as are interfaces, custom types, classes, and so forth.

I don’t think APIs should be treated differently than other code only because you need it to be so for your convenience. If APIs should be treated differently they need to be defined separately and licensed differently. Other languages and platforms makes this very clear by externalizing most APIs from the language and then adding support for the API to the language as though it is a foreign technology, because it’s definition and license are separate.