I don't think those who "understand the issue" must necessarily agree with the lower court. I've been coding since I was 13 and I agree with the Fed. Cir. here. The concrete Java declarations that make up an API are a protectable work of authorship. The abstract operations they describe are not.

E.g. POSIX C headers are protectable. But Lisp FFI declarations that compile down to the same ABI do not infringe because they targets the unprotectable method of operation, and do not copy the protectable textual description of those operations.

I think a lot of coders want the lower court to be right for pragmatic reasons. I totally appreciate those pragmatic arguments, but they're not based on having a better technical understanding of the issue.

> "The concrete Java declarations that make up an API are a protectable work of authorship. The abstract operations they describe are not."

Oracle was claiming rights to the "structure, sequence, and organization" of the APIs, not the text of their declarations. They were unmistakably going after something that was at least in some way more abstract and broad than the text of the declarations.

I'm not embracing the full extent of Oracle's argument in the case, I'm giving my own take on the issue.

Fair enough. But do you stand by your assertion that something more abstract than literal header file text can be deserving of copyright but ABIs shouldn't? I'd like to know how near or far your line is from Oracle's, if only to have an example of where else the line could be drawn.

Yes, but that's the usual copyright rule isn't it? You can't get around copyright by search and replacing "Harry Potter" with "Barry Potter." And it's well understood that the less creative the expression, the less has to be different for a work not to infringe. I'd say changing a couple of parameter names wouldn't do it, but changing the syntax of the declarations surely would.

> But Lisp FFI declarations that compile down to the same ABI do not infringe...

Doesn't this get into hair splitting? Somewhere in that Lisp code there's the symbolic name, as defined in the C code, for the function/entry point, and the C type-names for the parameters. Those are copyright protected. This is how I would expect Oracle to argue that changing language syntax does not excuse you from licensing their "copyright protected API."

Do you think it will be OK given this law to automatically generate FFI bindings by parsing protectable POSIX C headers? In this instance a human will have invoked a program that literally copied the source in to ram, bit by bit, and then copied certain bits of it (eg symbol names). Is that materially different to invoking 'cp' (a traditional copy command)?

> E.g. POSIX C headers are protectable. But Lisp FFI declarations that compile down to the same ABI do not infringe

This distinction does have a certain clarity to it, but isn't there a certain sense in which there's "only one way" to describe an API for a given language? "int foo(int a, int b)" is hard to write another way; perhaps I can rename the parameters.

(Your Lisp FFI example sidesteps this issue because API declarations in different languages will, of course, look different.)

In other words, I think there may be an "information content" argument. If the abstract operations are not copyrightable, and there is only one obvious way to write down the API's function prototypes in (e.g.) Java or C, does the source code really carry additional copyrightable value?

I wonder whether, for example, Java's "double sinh(double x)" from java.lang.Math could be found to be infringing on the pre-existing "double sinh(double x)" from math.h. The API is literally textually equivalent, right down to the variable names, despite the language being different.

(I'm genuinely curious what case law now considers the line to be; this isn't a rhetorical question.)

Infringement requires copying, not just text equivalence. If the C programmer was "writing C" and the Java programmer was "writing Java" there is probably no infringement because there is no copying.

Thanks, that's helpful.

(java.lang.Math is awfully similar to math.h; I actually wonder if, historically, there was copying.)

Historically, almost everything in computing is a copy of a copy of a copy, usually ultimately leading to some pseudocode in an academic journal somewhere. If everyone along the line asserted their copyright, the whole field would collapse.

Well, recipes are specifically exempt from copyright, but the text of them is not. If you had a recipe for "Lobster Thermadore" that was a close copy of another published version, that would be infringement.

The basics of a recipe are hard not to duplicate, but if you start writing a lengthy description of how to do it, that enters a different territory. That seems like a decent analogy for this case.

There is no need to be rude.

What a horrible comment.

Learn about the origin and general practices of the U.S. Court of Appeals for the Federal Circuit and you should get at least a little bit of enlightenment.

And without studying the case, just on the general principles of what copyright is supposed to do, applying it to APIs is at least a debatable point. And probably should be hashed out by the Congress and the Executive.