> This mixes up the functional aspects of designing methods with the stylistic aspects of API design. I think the disagreement here is as a frequent API author

> This mixes up the functional aspects of designing methods with the stylistic aspects of API design. 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.