Hacker News Reader

Comment by rayiner | Hacker News Reader

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?

View on HN

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

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?

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

Reply on news.ycombinator.com