Rss

Thing Is, APIs *Should* Be Copyrightable

A bunch of my friends, particularly on the F/OSS and Android side, are issuing a new call to the barricades to make the case that APIs should not be copyrightable. In particular, the EFF wants developers to send in stories of how they’ve reimplemented APIs for reasons of competition, interoperability, innovation, etc. The issue is heating up again because a three-judge Federal Circuit panel is going to revisit Judge Aslip’s ruling in Oracle v. Google, where the jury found that Google willfully infringed Oracle’s copyright on the Java APIs, but the Judge found that APIs aren’t copyrightable in the first place, rendering the jury decision moot.

This isn’t the slam dunk some people think it is. During the trial, Florian Mueller pulled up relevant case law to show that copyright has traditionally considered the design of computer code (and, implicitly, its public interfaces) to be protected.

Furthermore, the case against copyrightability of APIs strikes me as quite weak. If software deserves copyright at all — and there are good arguments against it, but that’s not what we’re talking about here — then drawing the line at published interfaces doesn’t hold up.

There are basically two arguments I’ve heard against API copyrightability. Here’s why I think they’re bunk:


If APIs are copyrightable, interoperability will suffer

So?

Seriously, that’s not an argument. Well, it is, but it’s an “ends justify the means” argument, one that says “you don’t deserve exclusive use of this thing you’ve created, because we need it more.” To say that interoperability trumps IP ownership is to say that George Lucas doesn’t deserve exclusive control of the Star Wars universe, because it interferes with Joe Schmo getting his Jar Jar / Yoda slashfic into the official canon. Hey, he’s just trying to interoperate with the rest of the Star Wars universe! He’s innovating! Why should Lucas be able to stop that?

Interoperability doesn’t end if APIs are copyrighted, it just means that people and companies who create stuff control how it’s used — that’s literally what copyright is, after all — which may or may not include seeking/wanting/tolerating interoperability or reimplementation.

Of course, it’s hugely ironic to hear anyone talking about interoperability in the context of Oracle v. Google, because Google’s Android was never meant or claimed to be interoperable with Java, at least not in bytecode. The only compatibility is with the accumulated knowledge and experience of the Java community, which Google hoped to co-opt (and succeeded in doing so).


APIs Aren’t Substantial Enough Creatively to Deserve Copyright

There’s no way this argument holds up. As Mueller pointed out above, earlier case law has found that the design and architecture of a program is as copyrightable as the specific instructions. By analogy, consider that traditional architecture is protected by copyright. A house is not just the nailing of studs and the pouring of concrete; the ideas of how it bears weight, resists weather, provides comfort, etc., as tangibly represented by blueprints and other design documents, are all protected by copyright.

This same thing applies to the design of code. The software architect who designs a public API has to make value judgements about readability, feasibility, practicaility, implementability, and so on. She has to conceive of both how the code will be implemented, and how it will be used, how it it is likely to consume resources (storage, I/O, db, CPU) under different use scenarios, and how to deliver value to whoever calls it. In a way, this is the most abstract, highest-level of thinking we do in software. Why would that be unworthy of copyright, but the drudgery of all the for-next blocks in its implementation be protected? This is backwards!

In practice, of course, many of us have a more holistic approach to developing public APIs: we develop some functionality and then expose only those parts that need to be called by an outsider. Why should moving a method signature or function declaration into a .h file, or changing its Java access modifier from private to public negate its copyrightability?

Passions on this issue are likely heated by pro-Android sentiment (in some camps, Google is always right), and a distaste for IP overreach in general (patent trolls, absurd copyright terms, etc.). Regardless, that’s not enough to make the case that APIs don’t deserve copyright protection.

I know I’m against the crowd yet again on this one, but I remain entirely unconvinced.

Comment (1)

Leave a Reply

Your email address will not be published. Required fields are marked *