Hacker News Reader

Comment by gpderetta | Hacker News Reader

Clear room prevented any copyright claims on the implementation, but if the API itself between the bios and the OS/application was copyrightable [1], or even between the bios and the hardware, there wouldn't be any PC clones at all.

[1] Although that's arguably a much simpler API where a fair use defense would be more likely to succeeds.

View on HN

IANAL but as I see it, the interface between hardware components is a binary interface, and this is where the difference lies between this case and others like Sony and Sega. The API here is not a binary interface but rather a textual description for humans to consume, and hence has aspects like creativity and expressivity, the very things copyright applies to. Binary interfaces have none of that. They are literally numbers for machines to interpret. Copyright cannot protect that because that is pure functionality and has no capability for expression.

Not to say there's no creativity there, there certainly is. But that creativity exists in the ideas and solutions used to solve technical problems, which is then the realm of patents.

Google tries to conflate these two issues. Programmers may find it reasonable because of course binary code seems equivalent to program code, the former being deterministically derived from the latter. But from a copyright perspective they are very different. Binaries enjoy copyright protection as they are "derived" from copyright-eligible software code, but Google is not accused of copying binary code here, rather textual APIs that they did not clean room reverse.

Unfortunately tech media and organizations like the EFF of course portray it differently because they have an agenda, and most people accept it without critical thought.

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.

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.

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.

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.

Reply on news.ycombinator.com