Part V: Oracle Wanted the Court to See the Forest for the Trees
Last time, I explained the painstaking “abstraction-filtration-comparison” test (or “AFC test”) that most courts use to determine the extent of copyright protection for computer code. The test is tedious and difficult to apply because you have to look at the software at several levels of abstraction—from basic concept to actual lines of code—and apply the test to each level.
Oracle’s Forest
From Oracle’s point of view, the problem with the AFC test isn’t so much that it’s difficult—Oracle has plenty of money for experts and lawyers—but that Oracle loses under the AFC test. Recall that Google deliberately avoided copying the protectable part of the Java API code (the implementation), and the rest of the Java API code was (the declaration) unprotectable under the Merger Doctrine. What Oracle needs is protection for a higher level of abstraction, but the individual methods are so short, there just isn’t enough levels of abstraction before you’ve run out of protectable expression and are completely engulfed by ideas, processes and functionality.
So Oracle needed a new way of looking at the problem: to stop looking at the API as a set of individual works, but to look to the collection of Java APIs as a single work, a work with a protectable organization. To see the forest for the trees. Put in Java-speak: focus on the organization of packages, classes and methods, at the expense of the where-the-rubber-meets-the-road code in the methods. In legal-speak, focus on the “structure, sequence and organization”—better known as “SSO”—of the API as a whole.
Go back to the example of the phone book I discussed back here. I said that you can’t get protection for the way to organize an alphabetical phone book because there’s nothing creative about alphabetical order. But if you could organize the entries in the phone book in a truly creative way, you might get some copyright protection—not in the factual content (because facts can’t be copyrighted) but in the organization itself.
Oracle’s argument, then, was that the methods are organized into classes, and the classes are organized into packages in a creative way. Oracle called this a “taxonomy,” and there’s good authority that taxonomies are protectable, assuming they’re creative enough.
At a minimum, we can say that there is more than one way to organize the Java API and some of those organizations might even make more sense than the current organization. Google didn’t have to name the “max” method “max.” Google could have called it “maximum” or “maxComp.” Google didn’t have to put “max” into the “Math” class. It could have put “max” into a “Comparison” class, or it could have renamed “Math” “Numbers” or “Arithmetic” or “Arith”. In fact, why even have classes at all?*
* Actually, that’s a good question. What purpose does the intermediate classification serve in the Java API? Is it an artifact from a slower-processing, less-memory era?
Google’s Trees
But the mere fact that Google could have organized the Java API methods differently doesn’t make the organization of Java API protectable—at least, not under the AFC test. If you apply the AFC test to the organization of the Java API, you have to conclude that Google didn’t really have a choice but to exactly duplicate the organization of the Java API—if it wanted to make Android to use the Java language. And everybody agreed that the Java language itself was not protectable.
Recall how you would, in the Java language, call the “max” method:
int a = java.lang.Math.max (4, 5);
If you changed “max” to “maxComp” and “Math” to “Arith,” you would need to change the line to this:
int a = java.lang.Arith.maxComp (4,5);
The problem is that nobody who has been trained to write in Java would automatically know this. It’s like you went through the dictionary and changed all the words while keeping the definitions the same. The syntax and structure of the language is the same, but the vocabulary is different.
Google argued (ultimately successfully) that Oracle’s position was similar to Lotus’ losing position in Lotus Development v. Borland Int’l, from the mid-90’s. Do you remember Lotus? Or, for that matter, Borland? Lotus was at the time the king of business software, based mostly on its fantastically popular spreadsheet program, Lotus 1-2-3. In the 80’s, spreadsheets were pretty much the killer app for desktop computers in the workplace.*
* It was, after all, a spreadsheet that made the Apple II popular in 1979.
Borland was an up-and-coming rival, and it developed its own spreadsheet program. Borland didn’t copy Lotus 1-2-3, but it did copy Lotus’ drop-down menus—things like, “Close,” “Print,” “Copy,” “Quit”—which were much more important to computer interfaces in those days. Borland obviously thought Lotus users would be more likely to switch if the commands were where they expected them to be. Lotus sued Borland for copyright infringement of the structure and organization of the drop-down menus. The trial court agreed, on grounds that Borland had many different reasonable ways of organizing its drop down menus.
The First Circuit reversed. It reasoned that the structure of the drop-down menus were functional, since they were “the method by which the program is operated and controlled.” More to the point, Google argued, Borland did not really have a choice but to copy Lotus’ structure if it would like its users to operate its spreadsheet program in the same way as they used to operate Lotus’.*
* This controversial decision actually went up to the Supreme Court, but the justices split evenly four to four. Ties in the Supreme Court are rare because they are normally nine justices, but sudden vacancies, recusals and 4-4-1 splits can result in ties. Ties are frustrating because they amount to an affirmation of the lower-court decision without much clarifying precedential power.
To Google (and ultimately to the court), this last part was most important. There’s a good bit of legal authority favoring inter-operability. It usually comes under the rubric of fair use, even allowing full copying of computer programs if done solely to create compatibility, as in the Sega decision. At a minimum, there’s a strong policy in favor of letting people write code that can interact with different operating systems, applications, etc. Thus, Lotus’ (or Java’s) structure can be quite creative, but the strong policy for interoperability will turn even creative content into a mere non-protectable process.
Can you see the reason for this strong policy? It’s the courts looking out for the consumer. If Borland had to scramble its drop-down menus, consumers would be frustrated, and for what? To protect the order in some commands were presented. That might be creative, but it isn’t that creative.
So, we must ask—for a third time—what the heck is Oracle suing about? (Dost though detect a pattern, mayhaps?) Half its code wasn’t copied, the other half isn’t copyrightable, and the organization of all that code isn’t copyrightable, either.
To answer this question, we have to qualify that last statement. The organization of the Java API isn’t copyrightable—under the predominant AFC test. What Oracle wanted to do was introduce another test for copyrightability of software. And if you go back in time far enough, you’ll find one.
We’ll discuss this alternate test, and the judge’s reaction to it, next time.
Thanks for reading!
