Even if it is, calling that "spreading misinformation" is a stretch, as the words "at worst" would make the statement completely true.
Also, if the case serves as no precedent whatsoever how could it have an effect? If it does have some, then what I said holds, and if it doesn't, then there was no cause for panic to begin with, and my point doubly holds.
> There is a whole lot of code that works on Android because those 37 Java packages are API-compatible.
In general, no Java library works on Android except by happy coincidence, as Android conforms with none of the several Java standards. Some libraries (that happen to only use the particular subset Google has chosen to implement) may just so happen to work, true, but it is not true that Android is interoperable with Java for any well-accepted definition of "interoperable" or "Java". Whether or not that's enough to make Google's implementation fall under fair-use is a separate question, but my point is that even if Google's use isn't fair use, that has little bearing on other cases where much stronger "drop-in" compatibility was sought.
> I'd suggest defining what exactly you're talking about for anyone to discuss it with you.
Certainly. I am referring to this: "Copyright protection subsists .. in original works of authorship fixed in any tangible medium of expression"[1]. Explanation here[2]. A specific description of a web API is certainly copyrighted (like any text), but the API it describes is not because it is not fixed. There can be many wildly different texts all describing the same web API. This is not true for library APIs, that are fixed text, just like any other code (that is not sufficient to make them copyrightable, but it is necessary).
Programming languages are -- similarly to web APIs but not library APIs -- not fixed.
> In general, no Java library works on Android except by happy coincidence
This is not true at all.
Every single library I have ever added in my build.gradle has always worked. Every. Single. Time.
Even libraries that were compiled with Java 8, which is the most baffling thing, if you think about it (since Android doesn't support Java 8).
Most of these libraries were compiled and deployed to the Maven repo by Java developers who had no idea whether their library was going to be used on Android. And yet, it does.
From Android's perspective, of course it isn't coincidence. Google implemented those APIs that they thought would be useful to Android developers. But from Java's perspective it is coincidence. If I have a Java application or a library (designed for SE or ME -- doesn't matter), it will only work on Android if I'm lucky (I'm not saying there's a 10% chance of it working, but it isn't 90% either). As a maintainer of several Java libraries -- none work on Android -- I feel this pain when people ask us to support Android, and there's a lot of work involved in making that happen.
While I think your understanding of the business situation is accurate, I don't think your distinction about language vs. web APIs stands. My (non-lawyer) take on the situation is this: The interoperability exception for copyright applies only at the system level, for things like binary protocols, byte code and machine instructions. This, I think, is because at that level there is only purely functionality and little expression. Copyright law explicitly covers creative expression and not functionality.
APIs, on the other hand, are required for humans to create systems that interact with other systems. As such they are meant for human consumption and communication and can have significant creative expression. Note that to be interoperable with other Java code, Google did not have to re-use the existing API. They could have used their own APIs, or heck their own language, that compiled down to the same byte-code. This is why I think the interoperability exception does not apply to this case.
As such, I think this ruling does mean that most web APIs, being text-based and intended for human consumption, could be copyright-eligible.
> most web APIs, being text-based and intended for human consumption, could be copyright-eligible.
But the very first condition of copyright eligibility is that the work have some fixed media representation. What fixed representation does a web-API have, a representation that must be replicated for the API to be implemented?
It is true. No Java standard is supported by Android: not SE (maybe some of the new SE compact profiles, but those don't apply to Android's version of Java), not any ME profile, and not any other more obscure Java standards. If a Java library happens to only use the "Android subset" then it will work, but as that subset is not specified by any Java edition or profile, such compatibility can only be coincidental (of course, Google made sure that the libraries they thought may help their ecosystem will work, so it's not a coincidence from that perspective, but it certainly does not make their case for interoperability).
Even if it is, calling that "spreading misinformation" is a stretch, as the words "at worst" would make the statement completely true.
Also, if the case serves as no precedent whatsoever how could it have an effect? If it does have some, then what I said holds, and if it doesn't, then there was no cause for panic to begin with, and my point doubly holds.
> There is a whole lot of code that works on Android because those 37 Java packages are API-compatible.
In general, no Java library works on Android except by happy coincidence, as Android conforms with none of the several Java standards. Some libraries (that happen to only use the particular subset Google has chosen to implement) may just so happen to work, true, but it is not true that Android is interoperable with Java for any well-accepted definition of "interoperable" or "Java". Whether or not that's enough to make Google's implementation fall under fair-use is a separate question, but my point is that even if Google's use isn't fair use, that has little bearing on other cases where much stronger "drop-in" compatibility was sought.
> I'd suggest defining what exactly you're talking about for anyone to discuss it with you.
Certainly. I am referring to this: "Copyright protection subsists .. in original works of authorship fixed in any tangible medium of expression"[1]. Explanation here[2]. A specific description of a web API is certainly copyrighted (like any text), but the API it describes is not because it is not fixed. There can be many wildly different texts all describing the same web API. This is not true for library APIs, that are fixed text, just like any other code (that is not sufficient to make them copyrightable, but it is necessary).
Programming languages are -- similarly to web APIs but not library APIs -- not fixed.
[1]: https://www.law.cornell.edu/uscode/text/17/102
[2]: http://www.mateoaboy.com/f6/blog_files/804f4c5940fe299168ea6...