> with the caveat of the ruling serving as a precedent, as other commenters say
No, this is incorrect. Because it was a copyright case decided by the Federal Circuit, it is precedent nowhere. Literally no court will need to treat it as precedent. Please educate yourself further before making these lengthy posts in threads like this; you're spreading misinformation.
> Also, copyrighted APIs are only "language-level" APIs... not web APIs (or protocols, as we used to call them)
From this and your post below, this appears to be a distinction you have made up (to appeal to the audience here? I have no clue). "Structure, sequence and organization" are certainly aspects of web APIs that could be copyrightable under the Federal Circuit's ruling.
Also, no one called web APIs "protocols" anymore than they called system calls "protocols". Unless you're talking about actual protocols, in which case I'd just stick to calling them "protocols" because that's what we still call them.
> There are several fair use defenses, but two apply to the industry in cases like this: 1/ non-profit use, 2/ use for the sake of compatibility (to prevent vendor lock-in).
Non-profit use is neither necessary or sufficient for fair use (see Google's recent book scanning ruling, for instance), and the compatibility argument is not with existing JVMs but with existing Java source code.
As for the rest of you post on fair use, I would suggest other readers to take a look at the actual four factors of fair use in the US, as your summary is a poor one. One good source:
I am most certainly not. I concede that I am not clear on how much this serves as a precedent if at all, but that has little or no bearing on what I've said on the case.
> From this and your post below, this appears to be a distinction you have made up (to appeal to the audience here? I have no clue). "Structure, sequence and organization" are certainly aspects of web APIs that could be copyrightable under the Federal Circuit's ruling.
You can apply "structure, sequence and organization" to anything you like, but if you want it to be copyrighted, your work must be fixed. If it is not fixed -- as in the case of web "APIs" -- it cannot be copyrighted no matter what other properties it may have. If there is a piece of text long enough to be considered "a work" that must be replicated verbatim (or through some copyright-preserving transformation) for you to implement my web API, then that could be copyrighted.
The problem is that even if you have a fixed media form you may not be eligible to copyright (which is where structure, sequence etc. applies).
> and the compatibility argument is not with existing JVMs but with existing Java source code.
Android is not compatible with Java sources.
> I would suggest other readers to take a look at the actual four factors of fair use in the US, as your summary is a poor one. One good source
That is indeed a much better summary of fair use than my poor attempt. Nevertheless, it has no bearing on my point, which is that the result of this lawsuit has little to no effect on any other players.
> I am most certainly not. I concede that I am not clear on how much this serves as a precedent if at all, but my comments are not predicated on that issue in the least (it is a minor point at best).
This:
> The only difference is that before (as Google did) you could make two arguments: 1) that APIs aren't copyrightable to begin with, and 2) if they are, then you're making fair use of them. Now only option 2 exists (with the caveat of the ruling serving as a precedent, as other commenters say).
is incorrect. Whether or not your comments are predicated on, you know, your comments themselves, I don't care.
> Android is not compatible with Java sources.
There is a whole lot of code that works on Android because those 37 Java packages are API-compatible, which was pretty important back in 2008. You can argue that's creating an incompatible Java ecosystem in order to allow Google to bootstrap an Android ecosystem, but that is compatibility.
As for your web APIs/protocol thing you're on about, I'd suggest defining what exactly you're talking about for anyone to discuss it with you. As it is you seem to be vaguely waving at something you've already defined to not be subject to copyright in order to give an example of something not subject to copyright...but now with a name that appeals to a broad audience (speaking of PR...)
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).
No, this is incorrect. Because it was a copyright case decided by the Federal Circuit, it is precedent nowhere. Literally no court will need to treat it as precedent. Please educate yourself further before making these lengthy posts in threads like this; you're spreading misinformation.
> Also, copyrighted APIs are only "language-level" APIs... not web APIs (or protocols, as we used to call them)
From this and your post below, this appears to be a distinction you have made up (to appeal to the audience here? I have no clue). "Structure, sequence and organization" are certainly aspects of web APIs that could be copyrightable under the Federal Circuit's ruling.
Also, no one called web APIs "protocols" anymore than they called system calls "protocols". Unless you're talking about actual protocols, in which case I'd just stick to calling them "protocols" because that's what we still call them.
> There are several fair use defenses, but two apply to the industry in cases like this: 1/ non-profit use, 2/ use for the sake of compatibility (to prevent vendor lock-in).
Non-profit use is neither necessary or sufficient for fair use (see Google's recent book scanning ruling, for instance), and the compatibility argument is not with existing JVMs but with existing Java source code.
As for the rest of you post on fair use, I would suggest other readers to take a look at the actual four factors of fair use in the US, as your summary is a poor one. One good source:
http://fairuse.stanford.edu/overview/fair-use/four-factors/