Hacker News Reader

Comment by keht | Hacker News Reader

erm...this is confusing...what is the EFF saying here?

It appears they don't want Google to use the fair use argument. Okay. But what else are they recommending?

That the last decision that API's are copyrighted is already the problem. Google - or anyone else - shouldn't have to need to use the fair use argument for this. This is already a law suit which shouldn't be necessary.

This idea that APIs are copyrighted in the US is a bigger problem beyond its borders. I don't know how familiar Americans are about how aggressively the US pushes its own legal interpretations of copyright law into other countries, but it is a continuing hassle.

The main problem here is that many countries do not have fair use! So if the legal interpretation that APIs are copyrighted spreads, it doesn't matter if it is fair use in the US. Even if countries specifically enact laws to exclude APIs from copyright law, you can bet that there will be huge pressure from the US to include it.

The Java trap after all -- only worse. We can't even reimplement it. We can't even implement to specs unless there is a license agreement (and we thought that patents were bad...)! I hate to be Chicken Little, but the sky does seem to be moving ominously quickly in the downward direction.

In some countries, like Brazil, softwares are not copyrighted, nor ideas. They are considered as "art", like a book, so you can't copy, use, etc., without authorization. But you can get the idea and rewrite it. You can't use the same buttons from some Microsoft product, but nothing stops you from deciding that a disk symbol means "save".

That sounds like copyright.

Exactly. The original decision was that APIs are not copyrightable. That was overturned on appeal, and it's a disastrous precedent if it is allowed to stand.

Just try to imagine the history of computing if this doctrine had always existed. To give just 2 high-impact examples: PC clones wouldn't have been allowed to implement IBMs BIOS APIs, Microsoft wouldn't have been allowed to implement a Javascript capable browser to compete with Netscape.

It's an alternate history that would have been so different it would be unrecognizable to us.

PC clones were only allowed because Compaq did a clean room reverse engineering of the BIOS, exactly to prevent this kind of scenarios.

http://basus.me/writing/essays/reverse.html

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.

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.

Google's defense claimed the Dalvik VM was a clean room implementation also so that defense doesn't necessarily prevent a litigation scenario or adverse decision.

Reply on news.ycombinator.com