Google’s Supreme Court faceoff with Oracle was a disaster for Google

I think the disagreement here is as a frequent API author I don't see any stylistic aspect in the design of API code. API code as an artifact itself is purely functional. This distinction becomes important because of the case precedent at hand.

Prior to creating any API, one must have a specification of the system the API is meant to model and control. If one skips writing the specification, that doesn't mean there isn't one, it's just largely in the brain of the implementer and possibly underspecified or inconsistent in spots. Every unit of API code therefore has an implied specification, whether or not a documented, written specification exists.

The API code is simply a mechanical translation of the specification into machine readable form. Parameter names, method names, those do not matter to the technical function of the system they are there solely to enhance use. The specification is possibly a patentable invention. A book describing the specification to a human audience is possibly a copyrightable work.

API code is neither of those things, rather it is an embodied practice of interacting with that specification in a machine-readable form and therefore IMO [IANAL] not eligible for copyright under Baker.

> For example, how to structure groups of functions for dealing with various kinds of buffers. Insofar as those stylistic decisions are expressed in literal code, that's the domain of copyright.

These structures are not inherent to the function of the API code, except incidentally due to implementation details. The purpose of these structures is to model the system being interacted with.

I think part of the misunderstanding here is the contemporary expectation that all code is self-documenting. Which is an admirable goal, but it obscures some important nuances about what an API as opposed to an API contract actually is.

API code, particularly old or highly specialized API code, has a TON of undocumented behavior, quirks, etc that exist. Where do they exist? Besides in the heads (optimistically) of the implementers, it also exists in the specification the API code together with its implementation translate.

> But what if you design the API by writing the declarations first, and filling in the methods afterwards?

Presumably it's the human and not the computer writing the API code so the human has some notion of what the API code is representing. The act of writing this code is translation. Just because the original is not always captured does not mean that it doesn't exist. It must exist for there to be API code in the first place.

European judges got that right.

> The crux of the case, then, is the copyrightability of those design decisions about how the API members are arranged. The set of specific functions it performs is, as per Baker not the focus of the argument.

To me, many of the analogies being bandied about don't really capture the distinction you're making. The football playbook for example. Rather than considering the playbook as a description of the game, and thus thinking of what Google did as analogous to copying the playbook, it seems to me that what Google did is analogous to copying the playbook's legend that describes the meaning of the Xs, Os, and arrows that comprise the playbook diagrams, as well as the playbook's table of contents, but none of the actual play diagrams.

To alter the metaphor a bit, Let's say that an author swipes the table of contents for the Lord of the Rings, and nothing else, and writes their own story that conforms to the LotR plot only to the extent that the ToC requires it. Characters and location names that appear in the ToC are used, but nothing else about them is the same. The page numbers don't even have to match as the new work is half the length. We also omit a few things from the ToC, like the several afterwords and appendixes, as well as anything that mentions Tolkien by name. Finally, the work itself isn't called "The Lord of the Rings", but "Doom of Shadows", or whatever.

The work isn't a parody or a satire, nothing is the same except to the extent necessary to make the identical ToC work (in terms of the name, order, and organization of the chapters).

To me, this is a good analogy. The two works are "compatible" in the sense that the ToC is an interface like an API, the ToC and the organization of the book were obviously copied verbatim, but nothing else was.

In this analogy (which presupposes that there are other works that use the ToC as an API), the same sort of questions from this case can be asked: 1. Is the ToC copyrightable per se (since there is obviously some creativity in naming, ordering, and grouping the chapters, but the ToC has slo), and 2. even if it is, is copying it to serve as the outline of a new work fair use?

Does the answer change if the book isn't fiction, eg. a cookbook (dish categories and recipe names, but not the actual recipes) or a textbook (only structure and organization of the subject matter copied, not the actual text or excercises)?

To me it seems fairly obvious that the correct answers are 1. mmmmaybe for the fiction example though I think not, but definitely not for the cookbook or textbook, and 2. It is absolutely fair use for all categories of works, even fiction

IIRC there is durable precedent that mechanical collections of information w/ no creative "touch" are ineligible for copyright. I wonder if that can be extended to the meta information definition you came up with.