Hacker News Reader

Comment by cromwellian | Hacker News Reader

Excellent analysis, but I have one question. So if you cannot categorically state that APIs should not be copyrightable (how does this relate to previous industry efforts around clean room engineering and cloning, like the IBM PC/firmware clones and x86 processor clones? Why did those escape the courts?) , how does one even go about, on a item-by-item basis, of providing APIs should be copyrightable?

For example, take the Java package java.io used for reading/writing files among other things. How can you construct an argument that the structure of the API itself should be copyrightable? And what would be an example of an API that couldn't be copyrighted for that matter?

View on HN

Even though I am not averse to IP rights generally, I strongly believe they need to be applied with their proper goals in mind and that it is deeply prejudicial to all concerned when they are misapplied - in that vein, my view is that APIs should not be copyrightable, as this to me is an abuse of the principles of copyright (if a rare API design is so novel as to be worthy of protection, it should be protected by patent).

In the Ninth Circuit, however, the same Johnson Controls case that held that the components of a computer program are to be assessed item-by-item to determine what is protectible and what is not also set forth the (judge-invented) doctrine that the structure, sequence and organization of elements in a computer program can be protected by copyright even if the discrete pieces are not in themselves expressive. Taking this as its point of departure, Oracle argues at length about all of the "expressive choices" that were made in the 166 API packages that are part of Java (and in the 37 API packages specifically at issue in this case), how they are named in special ways, how they are structured to take certain parameters and not others, how some call certain classes and methods not others, etc. Oracle further argues that Google could have achieved the same functionality that it gained from copying the APIs through "other means" such as APIs with different names and the like and that it could have done so without using the identical "sequence, structure, and organization" used in the Java APIs. It analogizes all this to a musical composition that is readily protectible under copyright even though individual notes are not.

I personally think the Oracle argument is a crock but, when you are able to devote huge resources to developing a case, when you can hire the best experts who can attest to the countless forms of "creative expression" of the type alluded to above, when you can pay the best lawyers to spin it out endlessly from every conceivable angle, you get the scary prospect of a court buying into this sort of analysis and mechanically concluding that, yes, all this is protected by copyright because it is "expressive" and not merely functional. This is why I think that the judge, who is bound to follow the Ninth Circuit precedent, will really need to dig deep to make a definitive ruling here that APIs are not protectible by copyright as a matter of law. An appeals court will have more freedom, however, and can focus on the purpose of copyright law and on why it is absurd in light of modern programming realities to give any party the power to monopolize API-style functionality in ways that will paralyze the industry. The judge is a very good judge and he may also land on the right conclusion - it is just harder for him because he is bound by some restrictive precedents.

I'm having difficulty with this. I also agree that APIs should not be copyrightable, because that defeats the purpose of an API. Their value to technology in general goes down if people can claim copyright infringement if someone else implements the same API. And that is, I think, the true test for what should and should not be legal: how will this impact society? I think that being able to copyright an API is a clear harm to society.

My difficulty comes from the fact that designing a good API is hard, and I think that there clearly are creative aspects to it. Doing a good job requires having an intimate knowledge of the component being interfaced with, and how programmers are likely to use it. The mere fact that we have said before "This API sucks" implies that it is not just a mechanical process.

Basically, I want one result because I feel it's better for society. But based on first principles, that's not the conclusion I arrive at.

I like the idea of rewarding effort, too, but US courts have determined that the amount of work exerted does not matter for the purposes of copyright.

That's not my point. My understanding of grellas' argument for why APIs are not copyrightable (which, again, I don't want them to be) hinges on "expressive" versus "functional." I am not a lawyer, so I don't understand the legal version of those concepts, but as a layman, APIs seem to me to be expressive; they require creativity and insight to create. If anyone would like to explain why they are not considered "expressive" constructs under the law, I would be glad to hear it.

The "subject matter" for copyright is defined in 17 U.S.C. section 102. Part (a) of the statute defines what can be copyrighted (essentially, original works of authorship) and part (b) defines what cannot. For policy reasons, the (b) part says, in effect, that even if something is an original work of authorship (meaning it is expressive and creative and otherwise eligible for copyright), nonetheless certain things cannot be copyrighted because this would not further the goal of copyright law (to further the progress of science and the arts) and would otherwise potentially harm society.

Section 102(b) reads as follows: "In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work."

The idea here is not to give anyone a monopoly via copyright over such fundamental concepts as ideas, etc. Things that are purely functional within systems and the like fall within 102(b) and cannot be copyrighted even if they are otherwise expressive. That is what Google is arguing about the 37 Java API packages in this case.

> they require creativity and insight to create.

So did Huffman encoding. So did the Laplace transform. So did quicksort, red-black trees, and hell, even the Universal Turing Machine. These are all the result of many hours of creative endeavor, yet they are none of them copyrightable.

This is the same thing that makes Wolfram's claims of ownership of the existence of a proof of Rule 110 CAs as universal calculators particularly onerous.

I gladly accept grellas's arguments. But your examples are ideas, which would fall under patents, not copyright. Source code does fall under copyright, so we need reasoning to explain why APIs - which are a part of source code - do not.

"It analogizes all this to a musical composition that is readily protectible under copyright even though individual notes are not."

This is a nice analogy. APIs are more expressive than individual notes but hardly raise themselves to the level of a fully formed composition.

Imagine a list of musical phrases. That includes scales and progressions at the simplest level and pleasing variations on those themes but not enough to form a contained composition themselves -- at most a couple of bars.

Each entry could show what scales and progressions they are derived from and even suggest which other entries, in simple combination, are common or otherwise musically sound. Let's further assume that they are given convenient names.

Would that rise to the level of copyright? If someone were to create a distinct variation on that list but slightly different for use with instruments tuned in an unusual way but used all of the same names because ultimately the way all of the phrases relate to one another is the same, would that be fair?

I haven't thought this scenario all of the way through, but it seems useful to take my familiarity with software out of the process...I have to admit, at first blush, I am a bit torn.

Perhaps it's reading too much into things, but doesn't that raise the possibility that this judge, knowing more than the average about computer science, is working hard to carefully justify as definitive ruling as possible arguing against the copyrightability of APIs?

At least, that's my hope. The transcripts indicate that he understands the tech better than most.

My reading of the trial is that he knows how difficult and significant any decision on API copyrightability would be, so he'd been trying to avoid it.

I'm pretty sure that door is closed now, so I hope you're right.

Reply on news.ycombinator.com