> Each API can have arbitrarily different concepts, paradigms, organization, and naming and calling conventions. Hence even APIs for doing the exact same things can (and do) look completely different from each other.
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.
> If they're "doing the exact same things" then they're the same API.
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.
They aren't doing the same things. You can't copyright a bolt with specific dimensions and thereby prevent anyone else from making nuts compatible with your bolts or bolts compatible with your nuts because you can't copyright function. It is also true that you can't copyright the entire concept of a bolt, but how does that help you?
Let's try a specific example. Here's a function from the C library:
int tolower(int c);
The following is not the same function:
int64_t tolower(int64_t c);
Even though the concept of what the function does (convert a character to lowercase) may be the same, you still can't switch them around in the compiler's symbol table. You can't link a binary that calls one with a library that implements only the other. They are not functionally equivalent.
I don't see the relevance of that. Of course those are NOT the same function. But they would logically belong in the same overall API, where "API" as used in this particular context means an overall logical collection of modules and methods, such as that of a standard library. The more relevant comparison would be between "int tolower(int c);" and "char java.lang.Character.toLowerCase(char 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.
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.