It wasn't even really a case (like say, Samba) where copying was necessary to interoperate with a closed, proprietary system.
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.
>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.
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........
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.
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?
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.
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.
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?
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'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.
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.