"Whole" in the sense of "the whole is more than the sum of its parts" is not generally understood to imply the maximal possible scope in any given context. It's simply meant to meant to talk about how the identify an aggregation (of no particular scale) relates to the identities of its individual components.
Similarly, the API/not-API distinction is one that has to be made in contexts beyond just the relationship of function signatures to function implementations. Foo was declared as a public class, but was it meant for public consumption? Or is it intended for internal use, and was only declared public because, for practical reasons, it couldn't be declared package-private?
Moreover, there are certainly rational distinctions that could be drawn, but that does not mean that they are legally relevant. The issue at hand really doesn't have anything at all to do with how programmers understand things. The law is not what we think is right, the law is what is written in the books.
Which is how I'm using it. An API that consists of two functions and one that consists of a billion functions have completely different scales but each whole unit has an API portion and an implementation portion. And the API portion is the recipe. It's a purely factual description of what the implementation is expected to do.
> Similarly, the API/not-API distinction is one that has to be made in contexts beyond just the relationship of function signatures to function implementations. Foo was declared as a public class, but was it meant for public consumption? Or is it intended for internal use, and was only declared public because, for practical reasons, it couldn't be declared package-private?
That doesn't affect whether the API parts of it are API parts, only whether the API is regarded as internal or not, which shouldn't be relevant to copyright. Internal APIs shouldn't be copyrightable either.
> The issue at hand really doesn't have anything at all to do with how programmers understand things.
It better, or you're in real trouble, because then all you have are meaningless zeros and ones.
Compare it to x86. It's just an "API" as well. Someone can write a specification or reference listing all opcodes and even though that reference is licensed under MIT or GPL you are still not allowed to make your own x86 processor because there is an IP tool specifically designed for this case. It's called patents. Just because you are not violating Intel's copyright doesn't mean you aren't violating Intel's patents.
Google probably didn't violate copyright and probably didn't violate any patents. So it is pretty much clear cut. Oracle failed to patent its API and therefore Google is allowed to use it.
AMD, Cyrix, Transmeta
I'm 99% certain that, if Intel had legal grounds to keep them out of the market, they would have done so. I'm 100% uncertain what's different between that case and this one.
My point is that "the whole" is the implementation of the Java standard library and the API is really still just the recipe.
> It's also an interesting model case because it's inherently so very open, without (particularly pre-Jigsaw) a clearly demarcated dividing line between "API" and "implementation."
The line is clear even if the language puts them both in the same file.
"public static void Hello(String[] args)" is part of the API. "System.out.println("Hello World");" is the implementation of that function.