Comment by rayiner | Hacker News Reader

Comment by rayiner | Hacker News Reader

Parent Full thread

I think the Google v. Oracle example actually cuts against your theory. In that case, the jury found non-infringement on the patent claims, and literal infringement of portions of the code and API. The real question in that case was a legal one: whether the structure and organization of APIs was copyrightable. On appeal, the federal circuit found that it was, and remanded for a determination on Google's fair use defense. Another jury then found that Google's incorporation of Oracle's API was fair use (and that is on appeal).

I'm not really sure how a jury of software developers would have changed the result.

And as a general matter, I'm wary of assertions that judges or juries would decide things differently if only they had "knowledge of the underlying subject matter." In Oracle v. Google, for example, the policy question was: does the fact that Google copied Oracle's API for interoperability purposes outweigh the fact that Google is making a profit by leveraging a platform Oracle built? The disagreement between the Federal Circuit and software developers did not have anything to do with knowledge of the subject matter. Everyone understood what an API was, etc. It had to do with values and priorities. "Interoperability" is something with a lot of value in the software field, but is more or less irrelevant to copyright. On the other hand, protecting authors from others profiting off their efforts is the primary value underlying copyright.

Take Lego-branded building bricks. The functional aspects of the bricks (the sizes and tolerances of the pips) are not copyrightable. Being essential to their function, I am allowed to make competing bricks with interoperably-sized pips and voids. (I am of course prohibited from putting the Lego script on the pips or from marketing them as "Legos" or anything more than "compatible with Lego brand building bricks".)

In so doing, I'd be profiting in part on the Lego-built platform, yet it seems crystal-clear in IP law that this is permissible.

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.

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

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