Part III: What Happens to Copyright Protection When There’s Only One Reasonable Way to Code Something
Through philosophical discussions of motorcycle maintenance, pancakes and old 1980’s TV ads involving peanut butter and chocolate, my last two posts can be boiled down into three fundamental rules of copyright law:
1. There is no copyright protection for ideas, facts, functionality, etc., or where the expression is dictated by outside forces, such as tradition, efficiency or compatibility.
2. Where a work has both unprotectable elements and protectable elements, you have to conceptually filter out the unprotectable elements, focusing on just the protectable expression.
3. But, when there’s only one reasonable way to express an idea, fact, function, etc., that entire expression is unprotectable (because otherwise you’d get de facto copyright protection over the idea, fact, function, etc., in violation of principle no. 1).
These principles are very important—fundamental even—for all types of copyrightable works, but they are central importance for computer code precisely because computer code is fundamentally functional. Therefore, these principles play the key role in the court’s holding in Oracle v. Google that the Java APIs are not copyrightable.
I Do Declare
The great thing about a Java “method” is that each has two separate parts, which are analyzed differently under copyright law. The first part is the declaration, which describes where the “method” fits in the overall API scheme (or library—more on this later), and how the “method” is to be invoked. The second part is the implementation, which tells the operating system what to do when the “method” is invoked.
Returning to the Court’s example of the “max” method, that method’s declaration goes like this:
package java.lang;
public class Math {
public static int max (int x, in y) {
The first two lines tells you where in the Java API universe this particular method fits: its “class” and “package.” This is important because when you “call” a method, the computer needs to be able to find it (i.e., look in the “java.lang” book, open to the “Math” section, then find “max.”) The next line tells you what sort of method it is (public, static, integer), its “name” (“max”) and its inputs (two integers, x and y). Without these bits of information, you wouldn’t be able to “call” the API, which you do like this:
int a = java.lang.Math.max (4, 5);
The crucial thing here is that you can’t call the “max” method in Java without providing the information in the declaration. What’s more, Java expects to find this information in particular places. If you wrote “max public static int”—i.e., placing the method’s name first, which would have been a perfectly reasonable way of doing it—Java would get pretty confused.
Therefore, there is only one practical way to write the declaration. Sure, you could get the same information out in a number of different ways, but none of those other ways would work with Java. As we now know, choices made for the sake of compatibility isn’t protectable expression. In the end, there isn’t really a choice about what order to place the information.
Imagine if compatibility (or, more precisely, expression dictated by compatibility concerns) was protectable. It would be next to impossible to build on others’ software works. If you’re going to make your software product work with a particular operating system, high-level computer language or application, it’s fairly likely you’re going to have to incorporate some code from those sources to make them compatible. That, in turn, would greatly limit the number of software products available to the public.
Thus, Java API’s declarations are a very good example of the “Merger Doctrine” (principle no. 3 above).
I Do Implement
The implementation of “max” goes like this:
if (x > y) return x;
else return y;
You don’t need to know much about computer programming to get this very simple implementation: if x is bigger than y, the answer is x; otherwise, the answer is y.
As it happens, Google didn’t copy any of the implementations* (although it did copy the declarations). To be safe, Google decided to have its own programmers write brand new implementations. This ensured that, where there were reasonable coding choice to be made, Google’s choices were likely to be different than those made in the original implementations. And to the extent they were the same, they were likely to be the same for reasons of efficiency and compatibility. As a result, the court didn’t really get an opportunity to rule on whether the implementations were copyrightable.
* I know what you’re thinking: “Then what the heck is Oracle suing about?” I’ll explain it next time.
I have to assume that most of the implementations at issue in Oracle v. Google were significantly more complex than the two-line implementation of “max.” I’m not really sure there’s another reasonable way to compare two numbers in that computer language. (In other words, “max’s” implementation is probably also unprotectable under principle no. 3 above.)
In fact, according to the opinion, 97% of Google’s implementations were different from the original implementations. I don’t know how this figure is arrived at. But it does imply that there were reasonable coding options for achieving the same functionality.
If Oracle didn’t dispute that Google’s implementations were different from the original implementations, then what was Oracle suing about? We’ll discuss the answer to that question (spoiler: the answer is “structure, sequence and organization” and “taxonomies”) next time.
Thanks for reading!
