Part IV: Why Oracle Needed a New Legal Theory Worse Than Huey Lewis Needed a New Drug
Last time, we looked at why half of each Java API “method” wasn’t copyrightable (because there was only one reasonable way to express the functionality) and that the other half of each Java API was probably copyrightable.* But then I dropped a little bomb. It turns out, Google didn’t copy the copyrightable part of the Java API. It had its own programmers code them from scratch. Oracle appears not to have disputed this.
* Again, I’m kind of skeptical about this. At least with respect to some of the really simple APIs, the Merger Doctrine must surely apply. Within the confines of computer language and desired functionality, there can’t be very many reasonable ways to code for that functionality. At the same time, apparently 97% of Google’s versions of the Java APIs were different from the original code, which suggests that Google managed for find different ways to code the same APIs. I just find that kind of hard to believe.
At that point, you probably exclaimed, “Then what was Oracle suing about?”* That’s a really good question.
* Well, at least with respect to copyright. There was also a patent component to the case. Oracle lost that portion of the case, too, on a jury verdict.
Here’s the answer. Oracle had a theory that even if you didn’t copy the actual code, you can still infringe the “structure, sequence and organization” of that code, better known as “SSO.” Rather like Huey Lewis’ new drug, it had to be just right*. Alas, like Huey’s new drug, Oracle’s new theory probably doesn’t exist, except in the dreams of its lawyers.**
* Because it would be weird if Oracle’s face broke out.
** Fun fact: This song was itself part of famous legal dispute.
This idea isn’t as crazy as it sounds, though Oracle’s application of this theory might have been a bit crazy. Copyright law protects works not only at the level of actual expression—i.e., actual words, brush strokes, pixels, musical notes, etc. It can also protect somewhat more abstract elements, like overall composition, pattern, organization and so forth. The questions is: how much more abstract?
Here’s a well-known example. You can’t get copyright protection in a phone book that lists names alphabetically, but you might be able to get copyright protection in a phone book that organizes the names in some creative way. In a sense, an alphabetical ordering is a method of organization, but a method that clearly and deeply in the public domain. It’s just not creative. But, in theory, there may be other, creative ways to order the names.
Recall principle no. 2 from the last blog. If there are protectable and non-protectable elements, you must filter out the non-protectable elements. Thus, in the phone book example, you would get copyright protection only in the method of organization, not in the information the phone book contains. Anyone would be free to use the names, phone numbers, etc. in your phone book. They just wouldn’t be able to organize that information as you do.
As you can imagine, providing copyright protection to abstractions can and often does bump into principle no. 1: no copyright protection for ideas. At a sufficiently high level of abstraction, you’re really just talking about ideas, not patterns, organization, composition, etc.
This has proven a particularly devilish problem for literary works. Consider this 1990 appellate-level decision involving the TV show, The Equalizer, which was about highly-trained operative who (gallantly) comes to the assistance of the powerless. Note how the court found that “a man who will equalize the odds, a lone man working outside the system” is an unprotectable idea, but a man who also seeks out such powerless people to provide assistance that conventional law enforcement cannot provide, so as to “equalize” the odds, is potentially protectable expression. Do you see a clear line between those the idea and the expression? I thought not.
Applying all this to computer code, though, is initially somewhat easier because computer code has several layers of easily identifiable abstraction. Computer code is intrinsically hierarchical. This is especially apparent when you consider how software is developed. You have to identify the problem you’re trying to solve; map out the requirements; think at a fairly high level how you go about solving the problem within the requirements; create multiple flow charts of the overall structure and any major modules and routines you have to develop (i.e., aren’t getting from somewhere else); and so forth.
At the level of “how to solve the problem within requirements,” software is clearly just an idea. At the level of actual code, it’s clearly expression. Somewhere in between, the software changes from idea to expression. But where? No one knows for sure.*
* If I had to guess, it’s at the point where you start creating complex flowcharts.
But figuring out what is expression is just the first step. Not all expression is protectable. So the next thing you have to do is filter out the non-protectable elements of the expression, most notably:
- elements subject to the Merger Doctrine (including those dictated by efficiency and demands of the computer language involved); and
- elements already in the public domain (e.g., routines that everyone learns during certification, at school, or were dedicated to the public domain in a publication).
Courts call this process “abstract-filtration-comparison” (or “AFC”). It was first developed in 1992 in the decision Computer Associates Int’l v. Altai. You break both the original and accused software down into levels of abstraction; then, starting with the highest level of abstraction, filter out the non-protectable elements; then compare what’s left over to each other to see if there is “substantial similarity”; then do it all over again for the next level of abstraction. It is an exhausting process, requiring lots of expensive expert testimony.
It should be pretty clear that Oracle wasn’t going to do very well under the AFC test. The Java API’s methods are pretty short, so there just aren’t very many levels of abstraction. Further, the constraints placed on the structure of the methods are so significant that the Merger Doctrine is going to filter out every abstraction layer except the lowest (and even then I’m skeptical).
So, again, the question is raised. If Google didn’t copy the actual code, and if Oracle can’t win under the AFC test, then what was Oracle suing about? The answer is that Oracle wasn’t accusing Google of infringing its code, but of infringing the way the code was organized at a very high level—specifically, the way the methods, classes and packages were organized. We’ll discuss that theory, and the big problem with it, next time.
Thanks for reading!
