4 ms·

> 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 C

> 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: http://fairuse.stanford.edu/overview/fair-use/four-factors/ http://fairuse.stanford.edu/overview/fair-use/four-factors/

pron 11y ago
> you're spreading misinformation. 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.
- magicalist 11y ago
  >> you're spreading misinformation. > 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...)
  - pron 11y ago
    > is incorrect. 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 https://www.law.cornell.edu/uscode/text/17/102 [2]: http://www.mateoaboy.com/f6/blog_files/804f4c5940fe299168ea68a195376c06-3.html http://www.mateoaboy.com/f6/blog_files/804f4c5940fe299168ea6...

pron 11y ago

> you're spreading misinformation. 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.

magicalist 11y ago
>> you're spreading misinformation. > 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...)
- pron 11y ago
  > is incorrect. 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 https://www.law.cornell.edu/uscode/text/17/102 [2]: http://www.mateoaboy.com/f6/blog_files/804f4c5940fe299168ea68a195376c06-3.html http://www.mateoaboy.com/f6/blog_files/804f4c5940fe299168ea6...