Hacker News Reader

>Oracle were never going to get away with that crap argument. To say that had Google copied all the APIs and created a compatible JVM that would have constituted fair use is laughable frankly.

Besides, how is the argument that Google effectively didn't copy enough at all consistent with the fair use factor regarding the amount of expression copied?

It's not, but Oracle had got themselves into a bind over the definition of 'interoperability'. They did indeed argue that Google hadn't copied enough, in so many words.

The trouble is that interoperability takes many forms and can't be shoved into a neat box like that.

> You can copyright APIs, but you can't tell others how they should be used.

What does that mean? What privileges would such a copyright provide? What could I do with the copyright that I couldn't do without?

I think you've just started to delve into the problem domain of copyright vs copyleft and why there are legal considerations when you allow people to access your software using an API.

It is as ridiculous as it sounds. There is simply no case at all where API use cannot be sensibly argued as fair use. That's why you use an API in the first place........

What privileges would such a copyright provide?

In practice? None.

> There is simply no case at all where API use cannot be sensibly argued as fair use.

An API being used by a client and an API being copied by a competitor to be used by those same clients are two completely different situations.

Nope, they aren't, or at the very least, the difference between them is as to be indistinguishable. That's what the jury decided here.

Using API and the word 'copied' in the same sentence simply doesn't mean anything.

Wave around a piece of legal paper with your name on it, if you file it with the copyright office.

And that's about it.

> Samba never copied anything.

According to this case, they did.

Nope. Not sure where you're getting that from.

Samba is API compatible with Windows file server.

Unless you are arguing that network protocol compatibility is a different thing? It seems to me that there is a lot of overlap, since Samba relies on re implementing the same behavior as a Windows file server.

Copyright doesn't care about the software's behavior, just the text and structure of the code. Samba implemented CIFS without looking at or copying any Microsoft code.

This is such a key point and yet also quite confusing. Obviously copyright is not patents. Copyright is about preventing literal copying of someone's creation.

So.., if you implement an API in a different programming language, such that the text and structure is different, and yet the function remains the same... then have you not infringed any copyright?

Copyright is about literal reuse of someones functional product, not about reuse of the abstract ideas that make up it.

To me an API, is just a formalization of declaring your intention to implement a particular functionality.

That basically used to be true, but this trial was over the "sequence, structure, and organization" of the API.

Reverse engineering is not a defense against infringement if the subject of reverse engineering is copyright-protected.

It generally is. That's the whole point of clean-room reimplementation. You have one set of engineers that reverse engineers a product to develop a spec, and another set that implements the same functionality from the spec. That's kosher and has been upheld in several court cases.

The trouble for doing that with Java APIs is the spec basically is the class declarations. You don't just need to "do the same thing" you need a tangible source file that has at least in part the same text.

It kind of depends - in some jurisdictions, for example, interoperability requirements is a sufficient defense against copyright infringement, i.e., if you've built your product so that interoperating with it requires [re]using copyrighted parts, then it's okay to do so (up to the extent required for interoperability) even if you explicitly forbid it.

Sane laws such as that automatically prevent issues such as this Java API dispute and also things such as the attempts to block interoperability for coffee machine "pods" by requiring a copyrighted magic string and using DMCA to prevent others from using it.

How can you copy an API without looking at the original API? They might not have looked the implementation, but if the API itself is copyrighted, won't looking at it suffice to be infringement?

If there is one thing I've learnt for sure from all the random forum posts used in this trial, it is that "IANAL" is a good thing to say!

Nonetheless, I don't think the clean-roomness or otherwise of an implementation has an impact on this. Otherwise someone could copy music by listening to it and replaying it.

Like you said: the copyright is on the text, pattern and structure of the code. But it doesn't matter how it was replicated.

Samba uses NO Windows APIs.

Please learn the difference between an API and a network protocol, else you end up looking foolish.

https://www.samba.org/ftp/tridge/misc/french_cafe.txt

Please learn the difference between an API and a network protocol, else you end up looking foolish.

I don't believe that the distinction is that clear at all. Hence my comment:

Unless you are arguing that network protocol compatibility is a different thing? It seems to me that there is a lot of overlap, since Samba relies on re implementing the same behavior as a Windows file server.

I think it is pretty easy to argue that the pattern of network calls needed to make calls (eg authentication) is an API.

Is a WSDL SOAP definition an API? I think most would say yes. A REST endpoint and the definition of how to use it? Why exactly is the definition of the HTTP protocol different to the definition of the REST endpoint?

IANAL, etc. Which seems important these days.

A linearized network protocol is not an API. That distinction is very clear. Read the Microsoft protocol specs. They say nothing about API's used to send/receive the protocol - only how the protocol elements are encoded on the wire.

The API's that Samba uses to access that protocol are nothing like the Windows API calls (and are a completely independent implementation).

I don't disagree at all!

I'm just pointing out that it isn't at all clear to me that the strong distinction that software people see between APIs and protocols is as clear under law.

It's not nearly as cut and dry as you're making it. Wiki of all places defines 'API' to be broad enough to include network wire protocols and endpoints. This trial was over "sequence, structure, and organization" rather than literal copying.

And of course Samba isn't built of WIN32 APIs, that's not what we're talking about.

If you automatically throw out cases, what's the point of having a law enabling and encouraging those cases in the first place? Or maybe a better question is: what would legitimate infringement look like, if what Google did is fair use?

I don't know if APIs should be subject to copyright or not. I certainly don't want them to be. But since APIs have been found copyrightable, it's hard to understand how this wasn't open and shut for Oracle.

Thus far, APIs have only been found copyrightable by the court that is specifically about patents. It's highly doubtful that any court capable of setting binding precedent on the matter will agree, especially to the same industry-destroying extent.

It should be expected that when a district court and its jury have their hands tied by a bad appeals court decision, the outcome will look a bit odd. In many ways our system of case law functions like a body of software where patches can only add lines of code, not remove them. Convoluted solutions to work around previous mistakes end up practically set in stone and refactoring is at best a once in a lifetime opportunity.