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?
The trouble is that interoperability takes many forms and can't be shoved into a neat box like that.
What does that mean? What privileges would such a copyright provide? What could I do with the copyright that I couldn't do without?
What privileges would such a copyright provide?
In practice? None.
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.
Using API and the word 'copied' in the same sentence simply doesn't mean anything.
And that's about it.
According to this case, they did.
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.
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?
To me an API, is just a formalization of declaring your intention to implement a particular functionality.
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.
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.
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.
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.
The API's that Samba uses to access that protocol are nothing like the Windows API calls (and are a completely independent implementation).
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.
And of course Samba isn't built of WIN32 APIs, that's not what we're talking about.
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.
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.
Samba never copied anything.
The interoperability argument was simple. Google wanted to use a language that was familiar to most and where developers could take existing code and port trivially. There are developer tools on the market that have done that for decades.
Davlik isn't drop-in compatible with the JVM anyway.
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.
Sun also open sourced Java which doesn't help them at all, and Oracle somewhat pathetically tried to backtrack on that.
That makes Oracle's win on the subject matter issue basically a pyrrhic victory for anyone looking to protect their APIs. They're protectable, but can't be protected in any realistic scenario.
The only sensible outcome. Had Oracle won we would have had years of court action in the developer software tools market until someone saw sense and simply ruled fair use in all cases. That may still happen.
And if you're in the camp that believes APIs should not be protected, this precedent--if it stands--means that you'll have to shoulder the expense of going to trial on the fair use issue before winning on the merits.
We'll have to get to a point where if court action is raised then it will automatically have to be thrown out. You can copyright APIs, but you can't tell others how they should be used.