Think of it like you put in the effort to curate a collection of recipes that work well together, and that curation is what’s copyrightable.
I don’t know what will happen with the law, and if APIs like this will be deemed a “curation”, but it makes a lot more sense to me from that perspective.
Ex.
Anyone can have a `Math.remainder` function, but the curation of an entire `Math` library might be copyrightable, since the effort was in collecting all of the correct things that work well together, even if they aren’t individually copyrightable.
A mega-recipe containing other recipes would be like making a `Math.AddAndThenMultiply`, which even if someone else had created the Add and Multiply methods, you aren’t stealing their API curation of methods, you’re just combining logic/algorithms (ingredients) from multiple methods (recipes) into a bigger method (mega-recipe).
Suppose I want to compile the big book of all known recipes. Then it will contain every recipe in your book, in its entirety, as well as every recipe in every other book. But if I can put the entire contents of your book in my book then what is it that you're really claiming to protect? The order the recipes appear in the book, i.e. the order the classes appear in the file? Which isn't generally regarded as part of the API.
A ToC cares what order it's in. You can't move Chapter 4 to before Chapter 2 or the implementation has to change. By contrast, the order of functions within a class, or classes within a package, isn't really part of the API -- they're most often in alphabetical order, which is totally mechanistic, and changing the order doesn't change the API.
A ToC is also not a rigid formal specification (like a recipe), but that's the core of what an API is.
> A ToC cares what order it's in. You can't move Chapter 4 to before Chapter 2 or the implementation has to change.
This isn't true.
Table of Contents
Foreword.................i
Introduction............ii
Preface................xvi
Chapter 1................1
Chapter 2...............17
Chapter 3...............30
Chapter 4...............51
Chapter 5...............58
Chapter 6...............76
Table of Contents
Foreword.................i
Introduction............ii
Preface................xvi
Chapter 4...............51
Chapter 1................1
Chapter 2...............17
Chapter 3...............30
Chapter 5...............58
Chapter 6...............76
> individual recipes are generally not copyrightable, but if you compile a set of recipes and publish them in a cookbook, the cookbook itself becomes copyrightable.
(emphasis mine)
The law understands that the whole is more than the sum of its parts. And Java adds up a lot of parts. It's also an interesting model case because it's inherently so very open, without (particularly pre-Jigsaw) a clearly demarcated dividing line between "API" and "implementation." Alito's not unreasonable to suggest that a Supreme Court ruling in Google's favor might raise difficult questions about how copyright law applies to software in general.
That's true, and while I have a very clear way I would like the Court to handle that personally, it's probably a good reason for the Court to look for an excuse to punt hard on copyrightability if it is open to them (and the procedural issue on fair use seems to offer that opportunity) and let the Circuit Courts (and I don't mean the Federal Circuit dubiously interpreting some regional circuit’s law) develop this issue more before resolving it at the Supreme Court level.
My point is that "the whole" is the implementation of the Java standard library and the API is really still just the recipe.
> It's also an interesting model case because it's inherently so very open, without (particularly pre-Jigsaw) a clearly demarcated dividing line between "API" and "implementation."
The line is clear even if the language puts them both in the same file.
public class Foo {
public static void Hello(String[] args) {
System.out.println("Hello World");
}
}
"Whole" in the sense of "the whole is more than the sum of its parts" is not generally understood to imply the maximal possible scope in any given context. It's simply meant to meant to talk about how the identify an aggregation (of no particular scale) relates to the identities of its individual components.
Similarly, the API/not-API distinction is one that has to be made in contexts beyond just the relationship of function signatures to function implementations. Foo was declared as a public class, but was it meant for public consumption? Or is it intended for internal use, and was only declared public because, for practical reasons, it couldn't be declared package-private?
Moreover, there are certainly rational distinctions that could be drawn, but that does not mean that they are legally relevant. The issue at hand really doesn't have anything at all to do with how programmers understand things. The law is not what we think is right, the law is what is written in the books.
Which is how I'm using it. An API that consists of two functions and one that consists of a billion functions have completely different scales but each whole unit has an API portion and an implementation portion. And the API portion is the recipe. It's a purely factual description of what the implementation is expected to do.
> Similarly, the API/not-API distinction is one that has to be made in contexts beyond just the relationship of function signatures to function implementations. Foo was declared as a public class, but was it meant for public consumption? Or is it intended for internal use, and was only declared public because, for practical reasons, it couldn't be declared package-private?
That doesn't affect whether the API parts of it are API parts, only whether the API is regarded as internal or not, which shouldn't be relevant to copyright. Internal APIs shouldn't be copyrightable either.
> The issue at hand really doesn't have anything at all to do with how programmers understand things.
It better, or you're in real trouble, because then all you have are meaningless zeros and ones.
Compare it to x86. It's just an "API" as well. Someone can write a specification or reference listing all opcodes and even though that reference is licensed under MIT or GPL you are still not allowed to make your own x86 processor because there is an IP tool specifically designed for this case. It's called patents. Just because you are not violating Intel's copyright doesn't mean you aren't violating Intel's patents.
Google probably didn't violate copyright and probably didn't violate any patents. So it is pretty much clear cut. Oracle failed to patent its API and therefore Google is allowed to use it.
AMD, Cyrix, Transmeta
I'm 99% certain that, if Intel had legal grounds to keep them out of the market, they would have done so. I'm 100% uncertain what's different between that case and this one.
Which in of itself is a long avoided question that sorely needs to be addressed.
No it doesn't. If that was the case then you could just do piecewise reinvention and then later on recombine the result.
Grasp the difference. Copyright prevents 1:1 copies, not against reinvention, patents do that.
A lot can be interpreted into the law when it is beneficial for everybody to do so. But interpretation has its limits. Some laws must be made explicit by the legislature.
Not the algorithm. The algorithm is essentially the recipe. The algorithm is merge sort, or depth first search. It's the contract the API gives you, more or less. "This function does merge sort." But there are unlimited possible implementations of merge sort and each one is copyrightable. And one implementation doesn't infringe the copyright of the other ones, even when they're the same algorithm, but you have to write your own. Copyright doesn't protect function, it protects works of authorship.
Copyright protects how code is written not what it does. And the how applies just as much to interfaces as implementations.
Splitting hairs like that doesn't change anything because it's still not the algorithm which you get a copyright on. It's the work of authorship implementing it.
But you can certainly produce multiple implementations of source code that are not only functionally equivalent in practice but actually generate identical machine code.
> Copyright protects how code is written not what it does. And the how applies just as much to interfaces as implementations.
The issue is that the interface is strictly the what it does part. Given the implementation, or the need for compatibility with one, the API is purely a factual description of the call spec. You can't rewrite it or it changes the what, which means there is no room to change the how, and the code correspondingly required shouldn't be copyrightable because it's purely functional and leaves no room for alternative compatible implementations.
It doesn't protect against reinvention because it's easy to bypass copyright through clean room designs which is probably what Google did.
This is not the most common type of contract in APIs. More like "this function sorts", or perhaps "this function sorts in O(N*log N) time". Sorting can be done with many different algorithms.
Is there still a way to protect your cookies? Yes, it's called patent law. It's explicitly designed to prevent reinvention.
It's hard not to use it when it's the one from the case law.
> That's not quite the same thing as curating a set of recipes into a cookbook and thereby exercising creativity in the "selection, coordination, and arrangement" of those recipes.
Exercising creativity can't be the hook if recipes have that and aren't copyrightable. You exercise creativity in choosing whether to specify chocolate chips or peanut butter chips or licorice bits etc.
APIs have hierarchy, but recipes have that too. You make butter from milk. You make cookies from butter. You make cookie crumb topping from cookies.
It's all already there in a recipe without reaching the result you want. You choose chocolate chips over peanut butter chips. You combine them with cookie ingredients to make cookies and brownie ingredients to make brownies. Selection, coordination, and arrangement. But the end result is still just a list of facts about how to make those cookies/brownies.
So why look at those things sometimes but not others? Because sometimes it applies to a work of authorship, but sometimes it applies to function, and you can't copyright function. So the functional part shouldn't count.
And that's what an API is. It's a formal functional specification. It's a list of facts about how to call those function implementations. It's the exact piece you don't get credit for.
Anything required for interoperability, is functional.
Sure, creativity is a requirement but it isn't the only requirement. But think about why a cookbook of selected recipes is copyrightable even if the recipes individually aren't.
> And that's what an API is. It's a formal functional specification.
The problem for Google is the Java API is also code, which is generally copyrightable. You seem to be saying that since this particular code happens to form a specification it should be treated differently under copyright law, but I'm not sure the court would find that argument very convincing.
The problem with this theory is that class and package declarations are still just recipes. There is a recipe for making chocolate chips. Then there is a recipe for making chocolate chip cookies where one of the ingredients is chocolate chips. It's recursive but it's not fundamentally different. Saying you can copyright a recipe for chocolate chip cookies because it's just organizing the recipes for chocolate chips and butter and brown sugar is pretty ridiculous.