4 ms·

I don't think the cited case law for exemptions for interoperability in interfaces applies to this case. For instance, the Sega and Sony cases apply for, as far

I don't think the cited case law for exemptions for interoperability in interfaces applies to this case. For instance, the Sega and Sony cases apply for, as far as I can tell, computer systems interoperating with each other. Lotus applies to humans operating software applications running on computer systems. APIs on the other hand, are mainly for humans to communicate with each other when building systems that interoperate. As such, APIs are primarily a means of expression between humans - from those who provide the interface, to those who use it. So from a copyright perspective, I don't see how binary interoperability between systems or the GUI layouts can compare to textual expression between humans. Also, as others have mentioned, the whole "method of operation" argument is also a dangerous slope to be slipping down. What is all code anything other than a "method of operation" of the hardware it runs on? I've said it before, but copyright is not really a good mechanism for IP protection of code. Software was shoehorned under copyright because 1) other mechanisms were not available and 2) there is sometimes creative expression involved in writing code. It's only the potential of creative expression what grants copyright protection to any written code. By that standard, APIs are no different from any other code.

jrochkind1 12y ago
> APIs on the other hand, are mainly for humans to communicate with each other when building systems that interoperate. I guess maybe that'd be the argument. To me, it seems pretty clear that API's are for "computer systems interoperating with each other". That's what an API is, an interface for one piece of software to interoperate with another. Seems to me and many others anyway. "Interface" kind of means "interoperation", an interface is the where and how of one component interoperating with another. I'm a bit surprised that any programmer would disagree actually, but I've been surprised before. The scary thing is that non-technical judges will have to understand what an API is and what it's for here. I do agree that software code does some weird things to copyright and starts to make the whole thing odd, and agree with you about "method of operation" thing -- the trick about code, different from former "creative expression fixed in a physical medium", is that code _does things_, in a way different from previous forms of creative expression fixed in a physical medium. Copyright is a weird edifice to begin with, and code makes it weirder, for sure. > APIs are no different from any other code. To me, API's are _not code_ at all, sot that's why they are different from "any other code." An API is a _description of code_, not code itself. Code implementing an API is surely copyrightable, but it seems to me clear that an API -- the description of classes, methods, and signatures -- is not code, it is a description of features of code. Google here lost by making code that _worked the same_ as Sun's, not because they copied Sun's Java source. And that's why it seems clear to me that it ought not, consistent with previous copyright law, to be copyrightable. But clearly people will disagree, especially non technical people, which is why this is a case. I think most technical people tend to agree with me, but obviously not all.
- throwawaykf05 12y ago
  "Interface" is an overloaded word, which muddies the waters quite a bit. It's even more confounded by the fact that one type of interface (APIs) are used in code that often compiles down to another type of interface (protocols/ABIs). In my mind, this difference is critical, because at a binary level (byte code, IR, assembly, what have you), the actual human-readable names don't matter. At the binary level, the interface essentially is nothing more than a bunch of bytes representing offsets into other byte arrays representing code, and yet more bytes arranged at other offsets representing arguments. Whether that code was generated from "File.open(fname)" or "new File(fname)" or "open(fname, O_RDONLY)" does not matter at all, because the final machine code (on x86) is essentially "mov al,0; mov ah,3dh; int 21h" (or the binary representation thereof). As such, you could generate a binary that calls code represented by an API without using the API at all. But of course, nobody really does that because human-readable "new File(fname)" is so much more expressive (and more important, much more readable) than they bytecode for "new #3; dup; aload_1; invokespecial #4". There is very limited potential for creative expression in a sequence of bytes and offsets, which is why it differs so greatly from APIs from a copyright standpoint. However, it is the bytes and offsets that is actually makes computer systems interoperable, not the names and organization of the APIs. Unfortunately, the Sega/Sony caselaw seems to exempt the former from copyright law, but the latter is what Google copied wholesale. Now Google, EFF et al are trying to conflate the two. (Of course, the fact that Android is not binary compatible with Java either is another hole in Google's own defense.) > ... APIs are not code at all... One could make convincing arguments both for or against that, but it does not matter from a copyright perspective. From what I can tell, anything that is "written" and can have "creative expression" is protected by copyright. My point is simply that, unless some exception is carved out for it, APIs being copyrightable is currently completely consistent with what copyright is intended for.

jrochkind1 12y ago

> APIs on the other hand, are mainly for humans to communicate with each other when building systems that interoperate. I guess maybe that'd be the argument. To me, it seems pretty clear that API's are for "computer systems interoperating with each other". That's what an API is, an interface for one piece of software to interoperate with another. Seems to me and many others anyway. "Interface" kind of means "interoperation", an interface is the where and how of one component interoperating with another. I'm a bit surprised that any programmer would disagree actually, but I've been surprised before. The scary thing is that non-technical judges will have to understand what an API is and what it's for here. I do agree that software code does some weird things to copyright and starts to make the whole thing odd, and agree with you about "method of operation" thing -- the trick about code, different from former "creative expression fixed in a physical medium", is that code _does things_, in a way different from previous forms of creative expression fixed in a physical medium. Copyright is a weird edifice to begin with, and code makes it weirder, for sure. > APIs are no different from any other code. To me, API's are _not code_ at all, sot that's why they are different from "any other code." An API is a _description of code_, not code itself. Code implementing an API is surely copyrightable, but it seems to me clear that an API -- the description of classes, methods, and signatures -- is not code, it is a description of features of code. Google here lost by making code that _worked the same_ as Sun's, not because they copied Sun's Java source. And that's why it seems clear to me that it ought not, consistent with previous copyright law, to be copyrightable. But clearly people will disagree, especially non technical people, which is why this is a case. I think most technical people tend to agree with me, but obviously not all.

throwawaykf05 12y ago
"Interface" is an overloaded word, which muddies the waters quite a bit. It's even more confounded by the fact that one type of interface (APIs) are used in code that often compiles down to another type of interface (protocols/ABIs). In my mind, this difference is critical, because at a binary level (byte code, IR, assembly, what have you), the actual human-readable names don't matter. At the binary level, the interface essentially is nothing more than a bunch of bytes representing offsets into other byte arrays representing code, and yet more bytes arranged at other offsets representing arguments. Whether that code was generated from "File.open(fname)" or "new File(fname)" or "open(fname, O_RDONLY)" does not matter at all, because the final machine code (on x86) is essentially "mov al,0; mov ah,3dh; int 21h" (or the binary representation thereof). As such, you could generate a binary that calls code represented by an API without using the API at all. But of course, nobody really does that because human-readable "new File(fname)" is so much more expressive (and more important, much more readable) than they bytecode for "new #3; dup; aload_1; invokespecial #4". There is very limited potential for creative expression in a sequence of bytes and offsets, which is why it differs so greatly from APIs from a copyright standpoint. However, it is the bytes and offsets that is actually makes computer systems interoperable, not the names and organization of the APIs. Unfortunately, the Sega/Sony caselaw seems to exempt the former from copyright law, but the latter is what Google copied wholesale. Now Google, EFF et al are trying to conflate the two. (Of course, the fact that Android is not binary compatible with Java either is another hole in Google's own defense.) > ... APIs are not code at all... One could make convincing arguments both for or against that, but it does not matter from a copyright perspective. From what I can tell, anything that is "written" and can have "creative expression" is protected by copyright. My point is simply that, unless some exception is carved out for it, APIs being copyrightable is currently completely consistent with what copyright is intended for.