Hacker News Reader

Comment by rayiner | Hacker News Reader

The Lego example rests on the idea that you can't copyright a functional aspect of a design (because then copyright would impinge on the domain of patent). The interoperability angle there is incidental.

And applying that reasoning to code leads to the weird result that the "functional aspects" of all code (not just APIs) should not be copyrightable. Indeed, once we're talking about functionality instead of interoperability, there is an argument that APIs should be more protected than ordinary code. APIs by themselves don't do anything. They're creative, rather arbitrary designs.

View on HN

> They're creative, rather arbitrary designs.

Which isn't relevant. Harry Potter is a creative work, including the character names, but the page numbers those characters appear on are not.

Similarly, Java is a creative work, and maybe even the interfaces are "creative" in that they aren't totally determined by the domain. But after the fact they're just a listing of resources, like a list of characters in a book.

Nobody is trying to say that "Dumbledore" isn't property of JKR, but everyone agrees we can discuss him and his characteristics. We can flip to pages where he appears, etc.

The court got bamboozled on this one.

> And applying that reasoning to code leads to the weird result that the "functional aspects" of all code (not just APIs) should not be copyrightable.

Right. You can't copyright the concept of adding one to another number, nor the code. You're copying the C-lang spec, not inventing "x++" yourself.

In the mix with creative elements, the work as a whole is granted protection that isn't available to the parts. Nobody says JKR owns "wizard", or the concept of wizards at boarding school, despite owning the copyright on her book about wizards at boarding school.

An API is not just a "listing of resources."[1] API design often is the most creative part of code. It involves all sorts of creative choices in terms of what abstractions to expose, how to expose them, etc. Take the STL, for example. There is nothing particularly interesting there about the code that does stuff. Oh, it's another red-black tree implementation, yawn. The creativity is all in the API: the container abstraction, the iterator abstraction, etc.

Even minor things like order of operands are creative choices. E.g., the common lisp standard library has a style of ordering arguments as you would in an English sentence. In CL, you vector-push an item into the vector. In GLIB, you array_append_val, into the array, an item. The choice isn't at all functional, it's a matter of taste and style.

[1] I don't get your point about "after the fact." After the fact, a book is just a sequence of characters. What's the relevance of that?

> I don't get your point about "after the fact.

To pick a name is creative. To use that name afterword is not - it's literally referring to something by its given name.

My mother was being creative, you're just reading my business card.

> Even minor things like order of operands are creative choices.

They can be. But where they're standardized, they aren't.

If the API specifies these things they're now functional.

> An API is not just a "listing of resources.

Actually, that's all it is. The implementation lives somewhere else.

> It involves all sorts of creative choices in terms of what abstractions to expose, how to expose them, etc.

Right, and the API itself is a non-creative listing of them.

I'm not violating copyright by telling you that one of the characters in Harry Potter is named Dumbledore, nor would I be if I listed all the characters and the facts about them, despite that by necessity as a work of fiction they're all creative.

"Literally referring to something by its given name" is like calling an API, not copying an API. Oracle didn't sue Google for writing software that merely called the Java APIs, or writing software that included information about the APIs. If you wrote out a prose description of each Java class, each method, and the types and order of each parameter, that would not be copyright infringement, even under the Federal Circuit's definition.

> "Literally referring to something by its given name" is like calling an API, not copying an API.

I don't think they're that separable. I could take a program that called Java APIs and, through a bytecode decompiler, reconstruct a header file for that API.

In fact, I've done this very thing through reverse engineering C code. I've produced header files that allow interoperability with proprietary code. In this case, the function names and parameter orderings were copied, but the type names, parameter names, and overall organization were my original creation. I never looked at the original header file. Is that copyright infringement?

Personally, I think any attempt to find hard and fast rules is going to fail, and the intent should be the most important criterion. (NB: this is not what I'm saying the law is, as I'm not a lawyer: rather, I think this is what the law should be.)

Copying an API is just reciting a bunch of facts. Individual details which aren't protected, stripped from the protected context of the work as a whole.

If you're saying that the API reference itself can be copyrighted, yes, I agree. My typesetting of it, my method ordering, etc. All protectable. But not the facts on which it's based.

> If you wrote out a prose description of [...]

Of course that would be fine, but you don't have to go that far.

And I could take your prose description and strip the prose from it and turn it back into an API description. In that scenario, whose copyright do you think is being violated? The original work which I've never seen, or yours?

Reply on news.ycombinator.com