6 ms·

One thing that many in the tech world get hung up on is the idea that this is arguing that designing APIs is not a creative endeavor. That's not what's being ar

One thing that many in the tech world get hung up on is the idea that this is arguing that designing APIs is not a creative endeavor. That's not what's being argued here. There are many creative acts which are not covered by copyright, and the argument is that APIs are one of them, since they are a functional description (the "method of operation"/"functional requirements for compatibility" covered by ewillbefull). It's not saying that API design is an incidental and uninteresting byproduct of the design of software, it's saying that as a method of operating that code, they aren't copyrightable. Incidentally, that may mean that these APIs could be covered by patents, but Oracle's patent argument in the original suit was extremely weak and so they dropped it, so it wouldn't be relevant to this case. It would also generally be very difficult to get patents on APIs without the Federal Circuit working a whole lot more of their patent-expansion magic.

pron 12y ago
> it's saying that as a method of operating that code, they aren't copyrightable That's an argument I could never understand. And remember, even though the term API has been borrowed in the past few years to mean "protocol", API in the context of this case pertains only to its classical meaning. As such, a specific API is indeed a method of operating code, but also a very elaborate text -- including specific class names and method names (and a specific ordering of parameters). None of the names is essential for replicating the functionality of the code. For example, String.length() could have just as easily been named string.len() or Str.size(). Because Googles "JDK" isn't actually the JDK -- and therefore does not interoperate with any actual JDK classes -- but simply a copy of them, the names, organization, etc. are absolutely not necessary in order to operate Google's code. Google's code was never meant to interoperate with Java, but to replicate it (once they've disregarded Java's GPL license this may not matter, but they've also broken the JDK's license in other ways, namely, they've made a partial, incompatible implementation). How, then, is the API being "a method of operating code" relevant to the matter at hand?

pron 12y ago

> it's saying that as a method of operating that code, they aren't copyrightable That's an argument I could never understand. And remember, even though the term API has been borrowed in the past few years to mean "protocol", API in the context of this case pertains only to its classical meaning. As such, a specific API is indeed a method of operating code, but also a very elaborate text -- including specific class names and method names (and a specific ordering of parameters). None of the names is essential for replicating the functionality of the code. For example, String.length() could have just as easily been named string.len() or Str.size(). Because Googles "JDK" isn't actually the JDK -- and therefore does not interoperate with any actual JDK classes -- but simply a copy of them, the names, organization, etc. are absolutely not necessary in order to operate Google's code. Google's code was never meant to interoperate with Java, but to replicate it (once they've disregarded Java's GPL license this may not matter, but they've also broken the JDK's license in other ways, namely, they've made a partial, incompatible implementation). How, then, is the API being "a method of operating code" relevant to the matter at hand?