"In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work."
The common belief is that an API meets this "system or method of operation" standard.
This isn't helpful: http://legal-dictionary.thefreedictionary.com/Method+of+oper...
I really don't understand how an API is a method of operation in any sense. It's an understanding between people about how to use a software library. The only sense that I could see it being a method of operation is literally "This is a description of how you operate the software library." In other words, an API is an instruction booklet for people, not computers. But in that case, why are instruction booklets copyrightable, but not software APIs?
for example...
Ninth Circuit law—which should have been controlling in this case—was the same: the “functional requirements for compatibility” between computer programs “are not protected by copyright.” Sega Enters., Ltd., v. Accolade, Inc.
Also, an API is much more than you think. An API might be Windows' system APIs which applications use to interact with the operating system -- put a license behind that and WINE is gone overnight. An API is also totally indistinguishable from a network protocol, in both a technical and legal sense.
But to be clear, instruction booklets are copyrightable, but the _instructions_ are not. (Or haven't been prior to this case? I think some worry that if the logic of this case if carried through, many things that were previously not protected by copyright will become so).
Let's say you figure out, say, a great new way to assemble some tool, and write down instructions for it (1. Get a ball of twine. 2. Get some chewing gum. 3. Affix the chewing gum to twine.)
Your instruction booklet itself is copyrightble -- nobody can photocopy it without your permission. But the steps you figured out are not copyrightable, someone else can write down those steps in their own words, hey, look what we can do with chewing gum and twine, and that is not protected by copyright. You can't stop someone from sharing those steps with others in their own words, and you can't stop someone from carrying out those steps. (Under copyright, that is. The steps may be patentable; that's a different law. But they are not copyrightable. Or... didn't used to be?).
That's the way copyright has been. It seems to many that the API itself, and the ability to make new software with the same API, is more like "following the steps yourself in your own words", than it is like the "instruction booklet." If someone writes docs for their API with lots of good narrative instructions and examples -- nobody else can just copy that documentation ("instruction booklet") wholesale, that's protected by their copyright, nobody disputes that. But the classes, methods, and signatures themselves, prior to this case, most everyone thought were more like "steps themselves" and not subject to copyright.
An "an understanding between people" has in fact never been copyrightable in itself, you can't stop someone else from sharing the same understanding, under copryight. You could stop someone else from copying particular text describing that understanding, but only the particular text.
The instructions themselves are not copyrightable only a specific presentation of those instructions.
So if I create a new recipe for a dish. You can include that recipe in your book but you can not include the specific presentation - so you should rewrite in your own words, not duplicate my layout, not copy my picture without permission, but you are free to recreate the recipe as it's a method of preparation rather than a form of presentation. Now arguably my layout of the dish could be copyright too so you may have to plate it differently.
void* foo(int bar);
The more dangerous question is "what is a computer program except a method of operation?"
If they're "doing the exact same things" then they're the same API. That's what an API is -- it's a formal declaration of the function(s) implemented by the implementation. Its purpose is literally to separate the part that can be implementation specific from the part that can't. The purpose of an API is to be the part that can't.
And yet somehow I can reliably differentiate the Java API from the C++ API from the Python API etc. etc. doing all the same things in their respective standard libraries. That is, each one expresses the same concepts in different ways. You seem to be conflating the concepts represented by an API with the specific expression of that API. This being a copyright case, the issue at hand is clearly the expressive aspect.
Let's try a specific example. Here's a function from the C library:
int tolower(int c);
int64_t tolower(int64_t c);
This specific case is not talking about copyrighting "java.io.File(String filename)" or "Character.toLowerCase(char c)" in isolation, but rather the overall collection of the whole API. It's all about covering the "structure, sequence and organization" of the API, and there's not much of that in a single function call.
But your point about linking relates to another point I made elsewhere (https://news.ycombinator.com/item?id=8581069): you can compile arbitrary textual code to binary code that links to the same symbol in the function table. That is, "new File(fname)" in Java and "open(fname, 'r')" in Jython can both point to the same symbol ("invokespecial #4" in Java bytecode). This is what I mean by "different API for same functionality". Google argues that they needed "binary compatibility" (by citing the Sega and Sony cases), but you do not need to copy the API wholesale for that! They could very well have defined their own new API (e.g. "android.fs.FileObject android.fs.FileSystem.openReadOnly(String fname);") that compiles down to the same bytecode, but then they wouldn't have been able to leverage the widespread pre-existing Java knowledge in the industry.