[gpderetta]

I don't think you deserve the downvotes, still the objection seems invalid; a binary ABI derives as much from a textual description (but not necessarily declarative) as a binary object from its source code. In fact I would say that the actual precondition, invariant definition, postconditions and data layout (which an ABI reimplementation would need to match) are a much more significant expression of creativity than the mere naming of functions.

So, assuming the copyrightability of APIs in the first place, an ABI should get as much protection as a textual API. The problem is that everybody had assumed until this ruling was that while APIs, ABIs and protocols were definitely an expression of creativity, they didn't reach the bar for copyright protection, especially when contrasted with the legally recognized right of reverse engineering for interoperability.

IANAL, of course.

[throwawaykf05]

The ABI, being essentially an ordering of bytes at specific offsets, has no expressive capability. Tons of creativity, sure, but of the functional kind, the stuff copyright explicitly exempts.

Note that if only ABI compatibility was required, Google could very well have defined their own API. For instance, they could have defined an API called "openFile()" that compiles down to the exact byte code as "new java.io.File()". But they were not after binary interoperability, they were after the Java developer base Sun had spent billions building.

[gpderetta]

An ABI is certainly not just an ordering of bytes at a specific offsets, no more than a text file is just a long string of bytes. There are very specific semantics assigned to those bytes.

[throwawaykf05]

Yes, and those semantics are purely functional, lacking any form of expression, which copyright expressly excludes from protection. The only reason binaries are copyright-protected is because they are "derivative works" from the original copyright-protected program code.