Quick question: Why can't an API be copyrighted? My understanding is that the purpose of a copyright is to protect a specific arrangement of ideas. A piece of music, a book, a painting. All of those things are an arrangement, and the arrangement itself is what's protected by copyright, not the physical object that was created.
So, given that an API is an arrangement of ideas, and that copyright apparently protects arrangements of ideas, why is copyright inapplicable here?
If the argument is that copyrights shouldn't apply to APIs, then I understand. It's probably more harmful than beneficial, and thus should be prevented. But if the argument is that copyright is incompatible with the domain of APIs, as if you were trying to copyright a taste like chocolate or copyright a smell, then I don't understand that at all. Would anyone mind clarifying?
> purpose of a copyright is to protect a specific arrangement of ideas
The purpose of copyright is to encourage innovation and creativity. In a broader sense, the ultimate goal is to benefit society. I think the real question we you should be asking is "will society benefit more from copyrighted APIs or not?". I personally think the answer is that it would be a net negative for society but that's my own opinion.
One thing that many in the tech world get hung up on is the idea that this is arguing that designing APIs is not a creative endeavor. That's not what's being argued here.
There are many creative acts which are not covered by copyright, and the argument is that APIs are one of them, since they are a functional description (the "method of operation"/"functional requirements for compatibility" covered by ewillbefull). It's not saying that API design is an incidental and uninteresting byproduct of the design of software, it's saying that as a method of operating that code, they aren't copyrightable.
Incidentally, that may mean that these APIs could be covered by patents, but Oracle's patent argument in the original suit was extremely weak and so they dropped it, so it wouldn't be relevant to this case.
It would also generally be very difficult to get patents on APIs without the Federal Circuit working a whole lot more of their patent-expansion magic.
> it's saying that as a method of operating that code, they aren't copyrightable
That's an argument I could never understand. And remember, even though the term API has been borrowed in the past few years to mean "protocol", API in the context of this case pertains only to its classical meaning. As such, a specific API is indeed a method of operating code, but also a very elaborate text -- including specific class names and method names (and a specific ordering of parameters). None of the names is essential for replicating the functionality of the code. For example, String.length() could have just as easily been named string.len() or Str.size(). Because Googles "JDK" isn't actually the JDK -- and therefore does not interoperate with any actual JDK classes -- but simply a copy of them, the names, organization, etc. are absolutely not necessary in order to operate Google's code. Google's code was never meant to interoperate with Java, but to replicate it (once they've disregarded Java's GPL license this may not matter, but they've also broken the JDK's license in other ways, namely, they've made a partial, incompatible implementation). How, then, is the API being "a method of operating code" relevant to the matter at hand?
"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 common belief is that an API meets this "system or method of operation" standard.
I really don't understand how an API is a method of operation in any sense. It's an understanding between people about how to use a software library. The only sense that I could see it being a method of operation is literally "This is a description of how you operate the software library." In other words, an API is an instruction booklet for people, not computers. But in that case, why are instruction booklets copyrightable, but not software APIs?
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.
Also, an API is much more than you think. An API might be Windows' system APIs which applications use to interact with the operating system -- put a license behind that and WINE is gone overnight. An API is also totally indistinguishable from a network protocol, in both a technical and legal sense.
So, I think you are right that computer software problematisizes much of copyright law, and this is how we get to this confusing situation.
But to be clear, instruction booklets are copyrightable, but the _instructions_ are not. (Or haven't been prior to this case? I think some worry that if the logic of this case if carried through, many things that were previously not protected by copyright will become so).
Let's say you figure out, say, a great new way to assemble some tool, and write down instructions for it (1. Get a ball of twine. 2. Get some chewing gum. 3. Affix the chewing gum to twine.)
Your instruction booklet itself is copyrightble -- nobody can photocopy it without your permission. But the steps you figured out are not copyrightable, someone else can write down those steps in their own words, hey, look what we can do with chewing gum and twine, and that is not protected by copyright. You can't stop someone from sharing those steps with others in their own words, and you can't stop someone from carrying out those steps. (Under copyright, that is. The steps may be patentable; that's a different law. But they are not copyrightable. Or... didn't used to be?).
That's the way copyright has been. It seems to many that the API itself, and the ability to make new software with the same API, is more like "following the steps yourself in your own words", than it is like the "instruction booklet." If someone writes docs for their API with lots of good narrative instructions and examples -- nobody else can just copy that documentation ("instruction booklet") wholesale, that's protected by their copyright, nobody disputes that. But the classes, methods, and signatures themselves, prior to this case, most everyone thought were more like "steps themselves" and not subject to copyright.
An "an understanding between people" has in fact never been copyrightable in itself, you can't stop someone else from sharing the same understanding, under copryight. You could stop someone else from copying particular text describing that understanding, but only the particular text.
>* But in that case, why are instruction booklets copyrightable, but not software APIs?* //
The instructions themselves are not copyrightable only a specific presentation of those instructions.
So if I create a new recipe for a dish. You can include that recipe in your book but you can not include the specific presentation - so you should rewrite in your own words, not duplicate my layout, not copy my picture without permission, but you are free to recreate the recipe as it's a method of preparation rather than a form of presentation. Now arguably my layout of the dish could be copyright too so you may have to plate it differently.
That isn't really a problem. You can have two programs that do the same thing, e.g. BSD cat and GNU cat, but you're copyrighting the specific implementation rather than the method of operation. Each method of operation can have arbitrarily many different implementations.
By that logic, copyrighting APIs is not really a problem either: Each API can have arbitrarily different concepts, paradigms, organization, and naming and calling conventions. Hence even APIs for doing the exact same things can (and do) look completely different from each other. Compare, for examples, the Java APIs with those for C++, C#, Python, Ruby, Go, etc. etc.
> Each API can have arbitrarily different concepts, paradigms, organization, and naming and calling conventions. Hence even APIs for doing the exact same things can (and do) look completely different from each other.
If they're "doing the exact same things" then they're the same API. That's what an API is -- it's a formal declaration of the function(s) implemented by the implementation. Its purpose is literally to separate the part that can be implementation specific from the part that can't. The purpose of an API is to be the part that can't.
> If they're "doing the exact same things" then they're the same API.
And yet somehow I can reliably differentiate the Java API from the C++ API from the Python API etc. etc. doing all the same things in their respective standard libraries. That is, each one expresses the same concepts in different ways. You seem to be conflating the concepts represented by an API with the specific expression of that API. This being a copyright case, the issue at hand is clearly the expressive aspect.
They aren't doing the same things. You can't copyright a bolt with specific dimensions and thereby prevent anyone else from making nuts compatible with your bolts or bolts compatible with your nuts because you can't copyright function. It is also true that you can't copyright the entire concept of a bolt, but how does that help you?
Let's try a specific example. Here's a function from the C library:
int tolower(int c);
The following is not the same function:
int64_t tolower(int64_t c);
Even though the concept of what the function does (convert a character to lowercase) may be the same, you still can't switch them around in the compiler's symbol table. You can't link a binary that calls one with a library that implements only the other. They are not functionally equivalent.
I don't see the relevance of that. Of course those are NOT the same function. But they would logically belong in the same overall API, where "API" as used in this particular context means an overall logical collection of modules and methods, such as that of a standard library. The more relevant comparison would be between "int tolower(int c);" and "char java.lang.Character.toLowerCase(char c);"
This specific case is not talking about copyrighting "java.io.File(String filename)" or "Character.toLowerCase(char c)" in isolation, but rather the overall collection of the whole API. It's all about covering the "structure, sequence and organization" of the API, and there's not much of that in a single function call.
But your point about linking relates to another point I made elsewhere (https://news.ycombinator.com/item?id=8581069): you can compile arbitrary textual code to binary code that links to the same symbol in the function table. That is, "new File(fname)" in Java and "open(fname, 'r')" in Jython can both point to the same symbol ("invokespecial #4" in Java bytecode). This is what I mean by "different API for same functionality". Google argues that they needed "binary compatibility" (by citing the Sega and Sony cases), but you do not need to copy the API wholesale for that! They could very well have defined their own new API (e.g. "android.fs.FileObject android.fs.FileSystem.openReadOnly(String fname);") that compiles down to the same bytecode, but then they wouldn't have been able to leverage the widespread pre-existing Java knowledge in the industry.
It's important (and sometimes difficult for us technically oriented types) to recognize that the law isn't necessarily (despite what Scalia would have us all believe) a slavish dedication to the precise words, and that the broader context and purpose of the law is taken into account when making judgements.
Just because a particular reading of copyright law might suggest that APIs could be copyrighted, doesn't mean that in the presence of a greater good ("...To promote the progress of science and useful arts..") the court might just decide that allowing the copyright of APIs would be incorrect.
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.
Actually a recipe can be copyrighted for it's content as well as patented.
Pharmaceuticals do it all the time, the biggest problem of copying a drug is not breaking what its made off but how is it made which is exactly what a recipe is.
You can run skittles, coke, or Viagra trough a mass-spec and get exactly what they are made off but it won't get you any closer to understanding how to make them.
Pharmaceuticals patents as well as patents in other industries like cosmetics and the food industry are all about the "recipe".
As far as API goes it's slightly more tricky but it's also something that needs to be thought off as they allow your competition to replicate functionality and directly take business from you by being compatible to every business partner you currently have.
Take for example the S3 API there are 100's of "Cloud Management Solutions" now that take advantage of the S3 API, as well as 1000's of developers already familiar with it's syntax and function. Now you want to set up your own cloud computing provider so you replicate the API for your own systems, under the hood they might be completely different but as far as integration goes they are identical.
While some might say well you can't copyright expressions and syntax others might say Amazon invested millions in developing their API, perfecting it's interoperability, investing money in partners and early adopters to get tools out there and get it to catch now you are coming and reaping all the benefits without investing anything whilst stealing potential costumers from Amazon.
API need to be open to survive, however as things go there should be a way for companies to control how and who implements them especially on the server side.
Those are on recipes. Clearly not copryightable in US law, really.
Pharmaceutical companies typically use patent, not copyright. The one place pharmaceutical companies try to use copyright is in "product information documents" (not the pharmaceuticals themselves), and even that is tenuous, as some courts have considered them statements of fact that are not copyrightable, and there was actually specific legislation about pharmaceutical product information sheets recently, which I don't know the details of well enough to speak on.
Drug companies patent both compounds and processes.
Your post seems to argue for patenting an API, not copyrighting it. I can't think of why an API can't be a patentable process. The claim tree might be rather complex.
I don't recall which case this was in, but the court in one of the early API cases noted that allowing copyright of APIs would give the copyright owner control over the use of their software that is almost the same as the control a patent gives a patentee over the use of their invention--except for a much much longer term, and without any requirement of novelty or non-obviousness.
Copyright is supposed to protect just the expression of an idea, not the underlying idea itself. With API copyrights, there isn't room left for others to express the same idea.
Simple answer - it's too generic of a level to allow copyrighting it. It ends up in vendor lock-in and anticompetitive behavior. Same reason abstract ideas aren't allowed to be copyrighted - it gives too much monopoly to those who would claim them.
So, given that an API is an arrangement of ideas, and that copyright apparently protects arrangements of ideas, why is copyright inapplicable here?
If the argument is that copyrights shouldn't apply to APIs, then I understand. It's probably more harmful than beneficial, and thus should be prevented. But if the argument is that copyright is incompatible with the domain of APIs, as if you were trying to copyright a taste like chocolate or copyright a smell, then I don't understand that at all. Would anyone mind clarifying?