> Alito's not unreasonable to suggest that a Supreme Court ruling in Google's favor might raise difficult questions about how copyright law applies to software in general.

That's true, and while I have a very clear way I would like the Court to handle that personally, it's probably a good reason for the Court to look for an excuse to punt hard on copyrightability if it is open to them (and the procedural issue on fair use seems to offer that opportunity) and let the Circuit Courts (and I don't mean the Federal Circuit dubiously interpreting some regional circuit’s law) develop this issue more before resolving it at the Supreme Court level.

> The law understands that the whole is more than the sum of its parts.

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 class Foo {
    public static void Hello(String[] args) {
        System.out.println("Hello World");
    }
  }

"public static void Hello(String[] args)" is part of the API. "System.out.println("Hello World");" is the implementation of that function.

You're drawing lines in places that best serve your position, rather than considering the whole landscape.

"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.

> "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.

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.

An API is an invisible thing. It's not in the code. It has absolutely nothing to do with code. You can create an API without any code at all. Therefore copyright does nothing because there are ways of copying an API that do not violate copyright.

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.

> you are still not allowed to make your own x86 processor

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.

>Alito's not unreasonable to suggest that a Supreme Court ruling in Google's favor might raise difficult questions about how copyright law applies to software in general.

Which in of itself is a long avoided question that sorely needs to be addressed.

And should be addressed by the legislature, not the judiciary.

Yes, but the judiciary gets to decide whether a tortured application of a law is absurd.

>The law understands that the whole is more than the sum of its parts.

No it doesn't. If that was the case then you could just do piecewise reinvention and then later on recombine the result.

Grasp the difference. Copyright prevents 1:1 copies, not against reinvention, patents do that.