Computer Scientists Ask Supreme Court to Rule APIs Can’t Be Copyrighted

There's lots of previous caselaw in the U.S. suggesting API's are not copyrightable, basically on the theory that functionality itself, as well as factual statements or descriptions of something, are not copyrightable.

For instance, if you write a recipe, the -exact text- of that recipe is copyrightable, but the actual recipe itself is not -- someone else can reword it in their own words, with the same basic ingredients combined using the same operations, and that is not protected by the recipe-writer's copyright. This is (or was?) established in U.S. law.

Similarly, in the U.S. _functionality_, behaviors or operations themselves, are not copyrightable (although it may be patent-able). You can copy a competitors functionality exactly, as long as you do it with your own original implementation -- the functionality is not protected by copyright. (This is why people do 'clean room' compatible implementations by developers who never saw the original code they are copying the functionality of). In general, the right reverse engineer and reproduce the functionality of a technical work without the permission of the copyright holder of the original work -- is (or has been?) legal and protected.

(I am not sure the judges involved realized the relationship between promoting the copyrightability of API, and what this does to the previously well-established right to reverse engineer and create compatible things).

So the belief, previous to this case, was that an API is more like functionality, or the steps in the recipe. An implementation of an API is copyrightable -- but the description of the API itself, the classes, methods and signatures, are more like functionality or statements of fact, more like the steps of a recipe or a description of behavior. Both of which are not copyrightable -- you can't prevent someone from "doing the same thing", only from copying your particular code or text), then they are like a creative work in fixed medium themselves (the exact text of a particular written recipe, or a particular code implementation. (Patent law lets you prevent others from 'doing the same thing', but that's a different law with different requirements for what is patentable vs what is copyrightable, different legal rules for determining if a violation occured and what the penalties are, etc.)

You are (or were?) allowed to copy an API in your own implementation by reverse engineering in order to create a compatible implementation, and it doesn't make a lot of sense if you lose this right because you can get the API from docs instead of reverse engineering it.

I'd imagine you can get more details from various briefs involved these cases, as far as cites to specific previous law. But to many, the fact that API's are not copyrightable is what's consistent with existing law over copyright, including the lack of copyright over the actual operations of a recipe themselves and the protected ability to reverse engineer someone elses thing to create your own compatible implementation. It seems to many that making API's copyrightable is inconsistent with much existing law.

So, the census needs maps (and best we are able to double check that, as it is used to apportion representatives). But also: the modern nation-state is, in many ways, founded on the notion of maps. A nation exists not just by itself but instead of and in place of other government. So it's pretty reasonable to assume public maps come from a time where e.g. the western border of the country was fuzzy and who controlled what was information of great importance. For instance, if it's 1823 and I'm looking to farmstead, a map both legitimizes, in some way, American rule, and delineates reality about Comanche raids (which were not something you'd want to bump into).

I generally like open government, but I think this particular practice may come from a history where maps were more interesting and relevant to the integrity of the nation-state.

It probably depends whether the people reading it know who the people signing it actually are. Vint Cerf, Ken Thompson and Ray Kurzweil now work for Google but that doesn't mean they aren't still Vint Cerf, Ken Thompson and Ray Kurzweil.

Many in this thread seem to be wondering about the legal argument itself -- that API's being copyrightable is inconsistent with existing pretty well-established law.

Which is, yes, a different thing than arguing about whether it's "a good idea" for society or innovation or whatever. The EFF summary focuses on the "good idea" thing, but the actual amicus brief addresses both -- although I bet you can find even more of the legal arguments in the first party brief.

From the amicus brief, take a look at the original brief, starting on numbered page 4, "I. The Federal Circuit’s Decision Has Disrupted Decades of Settled Expectations That APIs Are Not Copyrightable"

> That assumption was well-founded. It was based, in large part, on this Court’s own recognition, in 1996, that menu hierarchies that control functional capabilities are a method of operation, and thus uncopyrightable under 17 U.S.C. § 102(b). Lotus Dev. Corp. v. Borland Int’l, Inc., 49 F.3d 807, 815 (1st Cir. 1995), aff’d by an equally divided Court, 516 U.S. 233 (1996). Programmers and developers relied on that ruling for the proposition that APIs, like the menu hierarchy in Lotus, may not be copyrighted under § 102(b). Ninth Circuit law—which should have been controlling in this case—was the same: the “functional requirements for compatibility” between computer programs “are not protected by copyright.” Sega Enters., Ltd., v. Accolade, Inc., 977 F.2d 1510, 1522 (9th Cir. 1992); see alsoSony Computer Ent’mt, Inc. v. Connectix Corp., 203 F.3d 596, 599–600 (9th Cir. 2000) (describing Sony’s PlayStation BIOS as a “system interface procedure[]” that Connectix was entitled to reimplement under § 102(b)).

I've always understood API as "Application" (meaning application, program, something similar to script) "Programming" (creating code, writing) "Interface" (abstract definition of meaning of variables and functions, preferably with some code that makes those meanings "live", something real, "behind" those variable and function names). Maybe I'm wrong.

However code is code, be it a library, module, framework, API, program or anything else...