> 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.
"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.
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.