The Copyright Law of Interfaces

Winter break has ended and so, too, has my brief blogging break. I've blogged before (many times) about the ongoing Oracle v. Google case. My opinion has been and continues to be that nobody is getting the law exactly right here, to the point where I may draft my own amicus brief supporting grant of certiorari. But to the extent I do agree with one of the sides, it is the side that says API (Application Programming Interfaces) developers must be allowed to reuse the command and parameter structure of the original API without infringing copyright. My disagreement is merely with the way you get there. Some believe that API's are not copyrightable at all. I've blogged before that I'm not so sure about this. Some believe that this should be fair use. I think this is probably true but the factors don't cleanly line up. My view is that this should be handled on the infringement side: that API's, even if copyrightable, are not infringing when used in a particular way (that is, they are filtered out of an infringement analysis). It's the same result, but (for me, at least) much cleaner theoretically and doctrinally.

But make no mistake, this sort of reuse is critically important, as Charles Duan (R Street Institute) points out in his latest draft: Internet of Infringing Things: The Effect of Computer Interface Copyrights on Technology Standards (forthcoming in Rutgers Computer and Technology Law Journal). The draft is on SSRN and an abstract is here:

This article aims to explain how copyright in computer interfaces implicates the operation of common technologies. An interface, as used in industry and in this article, is a means by which a computer system communicates with other entities, either human programmers or other computers, to transmit information and receive instructions. Accordingly, if it is copyright infringement to implement an interface (a technical term referring to using the interface in its expected manner), then common technologies such as Wi-Fi, web pages, email, USB, and digital TV all infringe copyright.

By reviewing the intellectual property practices of the standard-setting organizations that devise and promulgate standards for these and other communications technologies, the article demonstrates that, at least in the eyes of standard-setting organizations and by extension in the eyes of technology industry members, implementation of computer interfaces is not an infringement of copyright. It concludes that courts should act consistent with these industry expectations rather than upending those expectations and leaving the copyright infringement status of all sorts of modern technologies in limbo.

 As noted, I agree with the end result, so any critique here should be taken as one of the paper, and not of the final position. I think Duan does a very nice job of explaining what an interface is: namely, the set of commands that third-party programmers send to a server/system to make it operate. There is value in standardization of these interfaces - it allows people to write one program that will work with multiple systems. Duan uses two good examples. The first is HTML/CSS programming, which allows people to write a single web document and have it run in any browser and/or server that supports the same language. The second is SMTP, which allows email clients to communicate with any email server. The internet was built on these sorts of interfaces, called RFCs.

Duan then does a nice job of showing the creativity that goes into selecting the commands - as with Java, there were choices (though limited) to make about each command. Because the set of functions is limited, number of ways to describe the function is limited, but there are some choices to be made. The article then shows how those commands are grouped together in functional ways.

Finally, Duan nicely shows how many important standards are out there that follow this same pattern, and shows how standards organizations handle any copyright--they don't. In short, allowing contributors to claim copyright ownership would destroy systems, because there is no requirement that contributors allow others to use the interface. Duan's concern is that if individual authors owned the IP in their interface contributions to standards (a potential extension of Oracle v. Google) then holdup might occur that harms adoption. This, of course, is hotly debated, as it is in the patent area.

I think it's a really interesting and well-written paper. Before I get to a couple critiques, I should note that Duan is focused more on how the current legal8 rulings might affect standards than critiquing the rulings themselves (as I have done here). Thus, my comments here may simply not have been on his radar.

My primary thought reading this is that the paper doesn't deal with the declaring code. That is, in order to implement the Java commands, Google created short code blocks that defined the functions, the parameters, etc.  Here is an example from the original district court opinion:

package java.lang;
java.lang public
class Math {
class Math public static int max (int x, int y) {

This code is what the jury found to be copied (though presumably Google wrote it in some other language). But the standards interfaces don't provide any code, per se. They only provide explanations. Here is an example definition from the RFC for the SMTP protocol discussed in the paper:

mail = "MAIL FROM:" Reverse-path

In other words, standards will define the commands that must be sent, but there's not a language based implementation (e.g. public, static, integer, etc.). As with the sample line above. Most say: send x command to do y. And people writing software are on their own to figure out how to do that. And you can bet the implementing code looks very similar, but there's something different about how it is specified at the outset (a full header declaration v. a looser description). So, the questions this raises are a) does this make standards less likely to infringe, even under the Federal Circuit's rules (I think yes), and b) does this change how we think about declaring code? (I think no, because the code is still minimal and functional, but Oracle presumably disagrees).

Secondarily, I don't think the article considers the differences between Oracle's position (now - it changed, which is one of the problems) and that of a contribution to standards. Contribution to a standard is made so that others will adopt it, presumably because it gives you a competitive advantage of some sort. By not being part of the standard, you risk having a fragmented (smaller) set of users. But if Oracle doesn't want others adopting Java language and would rather be limited, then that makes the analogy inapt. If Google had known this was not allowed and gone another way, it may well be that Java is dead today (figure that in to damages calculations). But a fear of companies submitting to standards and then taking it back is to me different in kind from companies that never want to be part of the standard. (Of course, as noted above, there is some dispute about this, as Sun apparently did act as if they wanted this language to be an open standard).

A final point: two sentences in the article caught my eye, because they support my view of the world (confirmation bias, of course). When speaking of standard setting organization policies, Duan writes: "To the extent that a copyright license is sought from contributors to standards, the license is solely directed to distributing the text of the standard. This suggests that copyright is simply not an issue with regard to implementing interfaces." Roughly interpreted, this means that these organizations think that maybe you can copyright your API, but that copyright only applies to slavish copying of the entire textual document. But when it comes to reuse of the technical requirements of the standard, we filter out the functionality and allow the reuse. This has always been my position, but nobody has argued it in this case.