3 ms·
You're referring to a distinction that's largely a peculiarity of how technological terminology has been shoehorned into an ad-hoc legal framework; there's no r
by wtallis 7y ago
You're referring to a distinction that's largely a peculiarity of how technological terminology has been shoehorned into an ad-hoc legal framework; there's no real deep insight here. If you ask the lawyers in this case what "an API" (singular) is, they'll give you a definition that's more on par with what a developer would call a single function/method signature. If you ask a developer to name some common APIs he uses, he'll list off named collections of functions, and such collections in the abstract are pretty much what Oracle's suing over. So when a developer rather than a lawyer says that Oracle's suing over "the Java API", they're trying to convey the correct meaning, and using the right terminology for the context. "Structure, sequence and organization of APIs" sounds much more like a legal test (in the same vein as the factors considered in determining fair use) rather than a decent name for the kind of creative work at issue.
- staticautomatic 7y agoYou've conveniently avoided mentioning the most significant question, which is whether the implementation was different.
- wtallis 7y agoI'm pretty sure that's not actually in question any more. And it's quite orthogonal to the question of whether it's appropriate to simplify "copyright of structure, sequence and organization of the API" down to "copyright of the API".
- staticautomatic 7y agoI don't think "copied the declarations" and "copied the declarations and implementation" are interchangeable or generally understood to be interchangeable. If you told me someone "copied your API", I would absolutely assume that they'd copied the implementation and not just the declarations or the way the declarations were organized/named. The "SSO" language is not an arbitrary or legal distinction. It is a technical one that is necessary to convey the exclusion of the implementation precisely because people would otherwise assume we were also talking about the implementation when we say "API".
- wtallis 7y ago> If you told me someone "copied your API", I would absolutely assume that they'd copied the implementation and not just the declarations or the way the declarations were organized/named. That's just you being unreasonable. I've literally never seen anyone else make a similar assertion or assumption, while the opposite is very common—most APIs that get copied are ones where the source code to the implementation is not even readily available to be copied, or where even looking at the original implementation's source code is dangerous for the author of a clone because of its license terms. Confusing the API with the entire standard library implementation is not a common mistake, especially among people who pay any attention to this legal case. > The "SSO" language is not an arbitrary or legal distinction. It is a technical one that is necessary to convey the exclusion of the implementation precisely because people would otherwise assume we were also talking about the implementation when we say "API". The "SSO" language is not about clarifying that the API is separate from the implementation; that distinction is pretty clear on its own. It's about trying to make sure the API doesn't run afoul of copyright law's exclusion of "any idea, procedure, process, system, method of operation, [...]", by making APIs out to be something more than just a collection of parts that are individually not copyrightable.
- staticautomatic 7y agoConfusing the API with its implementation may not be a common mistake among people following this case, but the people following the case are not the ones deciding it (much as I wish that were true).
- gpm 7y agoHuh? That's irrelevant and wasn't a question you raised before. The implementation was different in this case though, so apart from the above the answer to this question also doesn't support what you are arguing.
- staticautomatic 7y agoIt's very much relevant to what we're talking about when we talk about "the API". I am skeptical that when people think about what the above reply described as the "creative work at issue", they're not thinking about the implementation at all.