> 1) It is merely a guidepost to the rest of the work and doesn't rise to the level of creativity of the meat of the text. As anyone who has designed enough AP

> 1) It is merely a guidepost to the rest of the work and doesn't rise to the level of creativity of the meat of the text. As anyone who has designed enough APIs will tell you (including engineers testifying on Google's behalf during the trial, and many commenters here who disagree with the decision), an API often requires more creativity than the implementation. Sure, the implementation is also difficult to do well, but making that implementation usable by others is no less a creative task. The "table of contents" analogy is backwards: you don't write the code first and then extract the functions into an API. That's how you get poor APIs. For a well designed API it's always the other way around. With enough creativity and forethought put into an API, the implementation flows naturally, and in practice, it's exactly the opposite of the table of contents analogy. (Not to mention that a ToC may also be copyrightable.) > 2) over time the structure becomes standardized because of the nature of the information it attempts to organize suggests that standard. The "nature of information being organized" sounds like "functionality" to me. As before, it is distinct from expression. > I'd be willing to bet that if you put 10 people in separate rooms and asked them to create an API, 80% or more would be so close to one another that if someone studied one, they could find their way in another. Consider the corollary of your argument. If you asked those same people to write actual implementations for that same problem. I'd bet you get the same "80% or more would be so close" results. Do you mean that their resulting code would not be covered by copyright? Consider whatever arguments you apply to defend copyrightability of the implementation, and try to differentiate them from the API case. Unless you provide a detailed spec and enforce some conventions, I'm willing to bet nobody will have an exact duplicate of another, either for implementation or for API. An API for the same functionality, say for getting the number of absentees, may be labeled getAbsenteeCount() or nAbsentees() or NumNotPresent(). Or even absenteeList().length(). Or a poorly defined API may require something like classSize() - numPresent(). Or a really badly defined API would require iterating over each member of the class and checking the "present" flag. And that is the point: each expression of the same functionality can be unique, and hence a candidate for copyright.