I was going to say the same, but it looks like the documentation mentioned is for the client indeed. If the client is MIT licensed, are you infringing on anything by writing a compatible API?
The difference is that even though the Java API was licensed under the GPL, Google did not accept the GPL license. They implemented the API without a license. Were they willing to implement their code under the GPL there would have been nothing that Oracle could have done.
I'm with others who say that an API should not be copyright-able, however it appears that in this case it doesn't matter. They may have a license! I haven't looked into it at all, but if it's true that Smartcar have implemented this API and distributed it under an MIT license, I think it will be really hard slogging to say, "We only meant to license some of the IP. We just gave a license and decided we'd wait until after the fact to tell people what it covered".
I am a huge advocate of free software, but it really bothers me when people license something without having any clue what it actually means. I can't tell you the number of projects I've encountered who say things like, "I put it under the GPL, but you can't sell it", or "I put it under an open source license, but you can't use any of the code; just look at it", or "I put this game under a free software license, but you can't use any of the story for the game because software licenses only cover code", or "I put my code in the public domain, but that doesn't mean you can make a few changes and claim that it's yours", etc, etc. If you want a "I'll tell you if it's ok after you've done it" license, don't grant a general license! Reserve all your rights and handle licencing on a case by case basis.
Google had the choice to deal with Sun, but they though given Sun's account state they would get away with it, to the point that buying Sun to own Java wasn't even considered.
The APIs discussed in that case are only "classical" APIs, i.e. code APIs, not "web APIs", which are really protocols. Despite the fact that recently people have started calling protocols APIs, the two have huge differences from a copyright perspective[1], so that extrapolating from the former to the latter is tenuous, regardless of the ultimate outcome of that case.
Moreover, the court ruling makes it seem that if the intent is interoperability, fair use may apply (only the court rules Google's intent was not interoperability, as their implementation was intentionally incompatible).
Although in this particular case, it appears they can claim copyright violation on the documentation.
[1]: Most notably, in order to be copyrightable, a work has to be "fixed in a tangible medium of expression" (https://www.law.cornell.edu/uscode/text/17/102), i.e. you need to have a specific text (or image) that you can say, this is the work (although then even derivatives are protected). This is true for APIs, but not for protocols (or REST "APIs"). Whether this distinction makes sense to programmers or not is irrelevant. The same distinction holds for programs vs. algorithms: programs are "fixed in a tangible medium", and are subject to copyright, but algorithms are not, and not subject to copyright (but can be protected by patents).
Come on, this piece is written by someone who obviously doesn't know what he his talking about..
The entirety of his examples are focused on the Oauth API, which is a standard, and all the concepts and var names he shows as a steal of API are present in each and all Oauth authentication servers.
I mean, we have in our own api about 90% of the same verbiage for our own authentication doc, this is bog standard Auth code..
The same verbiage, as in large chunks of text are word-for-word identical? Because that’s what’s being alleged here; it doesn’t happen by accident (the chances of two people independently writing identical text are astronomically low for any significant amount of text), and it certainly constitutes copyright infringement unless it turns out that Smartcar put the documentation under an open source license somewhere. If, on the other hand, you just mean that your docs have a similar overall structure, because they’re documenting a similar API, that’s something completely different.
I understand the frustration of the guy, but this is not like they copied the business API, this is just the standard Oauth.
Anyways.. I'm starting to sound like an Otonomo PR guys.. I'm not, it's just that reading this article, I found myself pondering whether my current employer could be sued for this kind of trickery. I wrote the Oauth2 code in our product, and found myself writing the exact same doc (probably with different words).
