Android-Java: A Critique of the Federal Circuit’s Analysis Part I

How Do You “Transform” Computer Code?

This is the second part in my observations and analysis of the Federal Circuit’s reversal of the jury verdict of fair use in Oracle v. Google (i.e., the Java-Android case). Last time, I explained the boring but really crucial holding that fair use is not a jury question, and I suggested that, while the Federal Circuit found no fair use in this case, this holding probably strengthens fair use overall. In this post, I’ll critique the Federal Circuit’s fair-use analysis. And, yes, I do have some problems with it.

When going through the Federal Circuit’s analysis, we need to bear in mind how the Federal Circuit said it would treat the jury verdict. It would assume that the jury found all “historic facts” in favor of fair use, though it would need to guess, since the jury’s verdict was nothing more than, “Yup, fair use.”¹To be clear, as I understand it, the Federal Circuit didn’t even need to accord the jury even this much deference. The jury was effectively only an advisory jury, and the judge—and by extension the Federal Circuit—need not have accepted any of the jury’s findings. Also, having found the jury to be nothing more than an advisory jury, the Federal Circuit should have sent the case back to the trial judge for his findings, but why not cut out the middleman? Sometimes, the Federal Circuit cleaves admirably to this goal. But at a crucial juncture, it does not.

JAVA WAS IN SMARTPHONES, Y’ALL!!!

We must also bear in mind what it is that Google copied. Although Google was frequently accused of “copying code,” what it really copied was the way the Java APIs were organized.²You will hear some people call this “SSO,” which stands for nothing more than “structure, sequence and organization,” which says more about lawyers’ tendency to use different words to say the same thing than about the nature of copyright law. As it happens, bits of that organization wind up in the individual API files (“methods”) as “declaratory code.”³E.g., a method “max” in class “Math” in package “java.lang” requires you to put in the declaratory code part of the method’s source code “package java.lang; public class Math { public static in max (int x, int y) {”. This got us into trouble in the first appeal because, although the declaratory code is dictated by the organization, we assumed the organization itself wasn’t copyrightable. And that’s protectable, so long as the way they’re organized isn’t (a) arbitrary or random, (b) utterly conventional (like alphabetically or serially) or (c) highly systematic, such that the entire organization can be derived from the rule (in which case, you’d be protecting the unprotectable rule). True, each API method⁴Recall that the API libraries are organized into packages, then classes, then methods, which are the smallest unit. had to include the place it occupies in package’s “declaring code,” but that’s just a reflection of the organization. If the organization weren’t protectable (and not all means of organization are), then the declaring code wouldn’t be, either.

Google could have organized the API packages in some other way, but doing so would have confused Java programmers, whom Google wanted to attract for its Android project. Android might be a big deal now, and Google could probably organize the APIs however it wants now. But back then, it wasn’t clear it would be a success, and Google didn’t want to deter Java programmers from working with Android by making them learn a new way of organizing the APIs.

But that way of organizing APIs was protected by copyright, although the rest of Java was either not protectable, had been given away, or wasn’t actually copied by Google⁵In addition to declaratory code, an API method also has implementing code, which provides the actual instructions for what the method will do. Google hired programmers to re-create the implementing code without reference to the original implementing code, which is a legitimate method of avoiding copyright infringement.. If Oracle was going to license “Java,” it was going to license the organization of its APIs⁶That Google’s version of the implementing code almost exactly duplicated the original implementing code strongly suggests the implementing code isn’t copyrightable.. The question is: should this rather thin (but durable) barrier be enough to essentially protect all of Java (which, remember, doesn’t really work without APIs)? And remember: Google could have used a different organization but didn’t.

Introduction: The Federal Circuit’s View of Fair Use

Fair use is frequently described in terms of social benefit, for which copyright protection must stand aside. Under this view, the social benefit of the use must be weighed against the social benefit the copyright owners’ exclusive right to control⁷Specifically, to control the reproduction, adaption, distribution, public performance and public display of the work. the use of their works. While the social benefit of the use is usually self-evident—e.g., we now have a mobile operating system that actually can compete against iOS, which is no small thing—the social benefit of copyright owners’ control of their works is rather more abstract. It usually takes the form of the incentive to create, i.e., without copyright protection, artists and authors wouldn’t create as much or as well⁸By the way: no one says that, without copyright, we wouldn’t create AT ALL. We have been creative for at least as long as we’ve been a species. No: the idea is that we are incentivizing more and better creation.. There is also the sneaky idea that authors and artists have an inherent right to control their works, similar to parents’ right to control their children (except they never grow up).

None of that for the Federal Circuit! Instead, it couches fair use as an encroachment on the exclusive rights of copyright. It describes fair use as a “limited exception” to copyright “if it is for purposes such as criticism, comment, news reporting” and so forth. Fair use must be made to serve the Constitutional goal of copyright: to “promote the Progress of Science and useful Arts.”⁹Look at Article I, Section 8, paragraph 8. Put another way, the sole social benefit of fair use is to incentivize creation, and that benefit is found on both sides of the equation. Fair use is not, for the Federal Circuit, some kind of right we all share, perhaps grounded in the First Amendment right of free expression. It’s something courts should tolerate, not encourage.
Once you read the Federal Circuit’s description of fair use, you kind of know how it’s going to turn out.

Factor One: The Purpose and Character of the Use

The Federal Circuit divided this inquiry into three (non-controversial) sub-factors: commercial use, transformative use and “bad faith.” The Federal Circuit found Android to be commercial but not transformative, and punted on “bad faith,” so this factor weighed solidly against fair use.

Sub-Factor 1A: Commercial Use

Regarding commercial use, the Federal Circuit reached the unsurprising conclusion that Android was commercial, even though Google gives it away for free. Well, sure, but Google wasn’t giving Android away out of the goodness of its non-evil heart, and Google essentially conceded this at trial. The only question is how commercial. Fair use, after all, is a multi-factor balancing test, in which the balancing itself depends on the circumstances. So a commercial use doesn’t spell fair use’s doom, or even require the first factor weigh against fair use.

Alas, the jury didn’t tell us, and neither does the Federal Circuit. Despite its decision to defer to the jury on commercial use (which was one of those “historical facts”), the Federal Circuit wasn’t very interested in the possibility that the jury felt Android was commercial but not that commercial.

Sub-Factor 1B: Transformative Use (Heaven Help Us)

On transformative use, we are presented once again with the problem of how far we are willing to extend the concept. Are we just talking about transformation of just the underlying work (e.g., cutting it up for a collage), mixing the underlying work into another work (e.g., a mashup), or can we also consider altering the function or context of the underlying work (e.g., blowing up other people’s Instagram photographs and hanging them in a gallery)? And can we talk about transformative use in terms of degrees?

As regular readers already know, I believe the best way to handle an amorphous concept like transformative use is to let it spread everywhere, but thinner and thinner the farther out from the core you go. I’m perfectly willing to say something is slightly transformative, if all it’s doing is re-contextualizing the underlying work. It’s not nothing, but it’s not much.

The Federal Circuit doesn’t analyze transformative use this way, which I guess isn’t very surprising. It’s all or nothing—or, at least, there’s a threshold below which the court won’t recognize transformativeness: “[T]here is no bright line identifying when a use becomes transformative.” Thus, the Federal Circuit (and many other courts) wouldn’t distinguish between a wholesale knock-off and what Google has done here. And what has Google done? It has borrowed the organization of the 37 API packages so that developers of Android would be not need to learn a different organization, but also so there would be an operating system for mobile computer-phones. To the Federal Circuit, the latter doesn’t excuse the former.

Google had only one real argument for transformativeness: it placed the organization of the 37 API packages into a different context, namely, a mobile operating system. The Federal Circuit was willing to entertain the idea so long as the change in context altered the meaning of¹⁰Actual language: “alters the expression, meaning, or message of the original work.” the organization of the 37 API packages, and was “new.” One might pause here for a moment and contemplate how computer code can be imbued with new meaning. What does it mean for computer code to have “meaning”? The only “meaning” I can think of is what the computer code does, i.e., its function within the program. Putting aside the problem that much of this expression is unprotectable under the Merger Doctrine¹¹I.e., the code represents one of the few reasonable ways to achieve the desired function. Code that we might think of as aesthetic—elegant, efficient—is most vulnerable to the Merger Doctrine, ironically., it’s difficult to see how the “meaning” of software code could ever be changed. If you changed code so that the function was unchanged, is that change meaningful? And if you changed code so that the function was changed, that change is meaningful, but is it meaningful in a way that copyright protects? What about plopping the code into a different program that has a different purpose? That wouldn’t change its meaning, just its context. It would still be doing the same thing, just for a slightly different purpose.

Still, the Federal Circuit takes a shot at providing an example: to teach how to design API libraries¹²I’m giving the Federal Circuit a wee bit too much credit here. Its example is actually to teach “how to design an API,” but that wouldn’t implicate the organization of the 37 API packages, so I fixed it for them.. Perhaps we could extend this to teaching developers about how Java APIs are organized, so they can be better Java developers. Surely, this is transformative, but so obviously so that it doesn’t tell us much.

When Is Computer Code Like Graffiti Art at a Rock Concert?

Let’s instead consider a closer case cited by the Federal Circuit: Seltzer v. Green Day, in which the transformation was using a piece of art, somewhat altered, as an element of a larger mosaic for use at Green Day rock concerts. The Ninth Circuit found this change was meaningful. What would be an analogue for software? You can begin to see the problem: computer code doesn’t map neatly onto other types of copyrightable works. Perhaps if you took a copyrighted module and somehow used it, with only minor and necessary alterations, in an entirely different computer program? But what about the artistic choices in Seltzer? With code, the choice isn’t artistic but functional. And, if a mobile operating system were the “whole mosaic” and the organization of the 37 API packages like an element of the mosaic, couldn’t Android be forced into something kind of analogous to Seltzer? I’m not sure, and the Federal Circuit doesn’t consider it.

Instead, the Federal Circuit compares Android unfavorably to Infinity Broadcasting, in which the defendant merely ran radio programs through telephone lines. But that’s so obviously non-transformative that it doesn’t tell us much, either. To the Federal Circuit, all Google was doing was changing formats, from desktop to mobile devices. But that doesn’t seem right. Android is an operating system, and Java is more like a platform.¹³There used to be Java OS, but it died long ago. “Java Desktop System” is apparently a misnomer, since it doesn’t have that much to do with Java. Further, Google wasn’t taking “Java” or some hypothetical desktop operating system, but just the organization of the 37 API packages. Perhaps what the Federal Circuit is getting at is that this organization wasn’t really repurposed in Android: it was taken so developers would more easily write applications in Java. If so, the comparison to Infinity Broadcasting is off-base.

All of this was academic, as far as the Federal Circuit was concerned. It decided that, to have any hope of being transformative, it’s not enough for the secondary use to be a different context. The context has to be “new.” And by “new,” the Federal Circuit means “novel” in the patent sense: never been done before. Thus, the fact that there had been previous (failed) mobile operating systems based on Java means all subsequent attempts are not longer “new” and automatically not transformative. This is (ahem) novel theory is based on exactly no legal authority. This is a big honking mistake that only the Federal Circuit could make. When courts use the term “new context” in connection with transformative use, as in Perfect 10 v. Amazon, courts don’t mean “novel,” they just mean new in relation to what had come before, which is how the vast majority of people would understand the phrase. How did the Federal Circuit wind up making this mistake? The big clue is that the Federal Circuit mostly handles patent cases¹⁴ And hardly any copyright cases, for what it’s worth., and patents do require novelty. Please, please, please don’t let this become a thing.

Still, perhaps we shouldn’t be troubled by what seems to be a built-in advantage for software, because it sort of makes up for a built-in disadvantage, which arises in connection with the second factor. Software isn’t very expressive, which hurts it in the second factor, but that lack of human-appreciable expression makes it harder to transform. It’s also nice to know that the Federal Circuit has no better grasp of “transformative” than anyone else, something it pretty much acknowledges.

So, I’d say that Android’s use of the organization of the 37 API packages is a little bit transformative. By comparison, the Federal Circuit said it’s not transformative at all. For all my criticism directed at the Federal Circuit’s reasoning, we’re really not that far apart. We are, of course, both very far from what the jury obviously thought.

Factor 1C (Existence Doubtful): “Bad Faith”

Regarding “bad faith,” there are good reasons to believe this isn’t really a sub-factor. A close reading of the relevant authority reveals that the infringer’s state of mind shouldn’t be considered, but that the propriety of the infringer’s conduct might be. That is, if the act of infringement were also an illegal act in and of itself—e.g., stealing a manuscript—that bad act might weigh against fair use.¹⁵But almost every bad act relevant to fair you that you can think of relates to the right of first publication, which is already dealt with under the second factor.

Fortunately, it doesn’t matter here. The Federal Circuit felt that bad faith was a “historic fact” (because it goes to a value judgment), and so it credits the jury’s implicit finding that Google didn’t act in “bad faith.”

Our score so far:

• Jury’s likely calculation: somewhat commercial, somewhat transformative, no bad faith = a push on factor one.
• Federal Circuit: Seriously commercial, seriously non-transformative, no bad faith = factor one weighs heavily against fair use.
• Me: Pretty commercial, slightly transformative, no bad faith = factor one weighs against fair use, but not heavily.

Factor 2: The Nature of the Copyrighted Work

This factor looks at how expressive the underlying work is. The more expressive, the more it weighs against fair use. The Federal Circuit felt constrained to conclude that the organization of 37 API packages isn’t very “creative,” because that must have been what the jury found. The truth is that software code isn’t going to do well under this factor. Everything you can think of as “creative” in coding is almost always also non-protectable. Elegance, efficiency, clarity, or “it just plain works” all go to functionality. It’s ironic, but copyright law punishes good coding. You can’t protect function; everyone knows that. But if you come up with the most elegant or efficient way to carry out a function, your expression will “merge” with the function. The code that best carries out a function will swiftly become one of the few reasonable ways to do so, and when that happens, the expression will merge with the function. Otherwise, we’d be giving patent-like protection but for copyright-like durations—or requiring everyone to come up with dumber ways to code.

But it’s OK! Because the Federal Circuit deprecates the second factor to irrelevance. Although it’s been a factor for over 150 years, it “typically has not been terribly significant in the overall fair use balancing.”

Is this a trend? We saw this in the Second Circuit’s fair-use analysis in the TVEyes case. And it makes no sense. Historical irrelevancy—itself a doubtful point—doesn’t mean the factor isn’t relevant in this case. There’s a pretty good case that it does matter in this case, precisely because software is so hard to “transform” for the first factor. This deprecation smacks of result-oriented reasoning. You can hardly blame those who thought the fix was in.

In support of this deprecation, the Federal Circuit cites Dr. Seuss Enterprises v. Penguin Books—the notorious “Cat NOT in the Hat” case¹⁶In which the OJ Simpson murder trial was re-told in Seussian rhyme. It’s Exhibit A for what ISN’T a parody.—but that decision cites no authority for observation that the second factor is rarely important. The other decision cited, Mattel v. Walking Mountain—the notorious “Barbie enchilada” case¹⁷In which nude Barbie dolls were shown being cooked in various disturbing ways.—just cites Dr Seuss Enterprises (which, remember, cites nothing), and was a parody case anyway.¹⁸In parody cases, courts recognize that only creative works are likely to be parodied. But parody is a narrow category of fair uses. The Federal Circuit then says that “other circuits agree” and cites a single decision from a single Circuit. And guess which one it is? The TVEyes decision. TVEyes, in turn, cites Authors Guild v. Google—the “Google Books” case—which basically didn’t want to have to parse out the different types of books that Google was copying.¹⁹The problem was that there were scads of books at issue, some more expressive than others. The Second Circuit basically didn’t want to go through each book individually to look at how much weight to give the second factor.

The Google Books case does make the unremarkable observation that the second factor is rarely dispositive—i.e., determinative. Indeed, it’s hard to imagine that it would ever be solely determinative of the fair use analysis. Otherwise, factual and functional—but otherwise copyrightable—works would effectively lose their copyright protection. But that’s not the same thing as saying the factor just drops out of the analysis, or “has less significance to the overall analysis.”

Sometimes, the second factor is going to be less important than other times. Every fair use case is different, and the way we balance the factors will change from case to case. But I think this is one of those times it’s more important than usual—not dispositive, just really important. Google has taken what must be one of the least interesting works ever created: how to organize 37 packages of APIs. And before you tell me how important it was to organize them in a useful way, remember that utility isn’t expression. Indeed, if the organization were dictated by convention, for example, it wouldn’t have been protectable.²⁰Google didn’t argue this way back when, and waived this argument. Google decided to place its money on functionality, rather than lack of originality. But it’s an intriguing thought: why were the 37 APIs organized the way they were?

Does Software Need Special Protection from the Second Factor?

To its credit, the Federal Circuit did not rely on Wall Data v. Los Angeles County Sheriff’s Dep’t for its second-factor analysis, though it could have (and it cites the decision elsewhere). Wall Data was a classic under-licensing case. The Sheriff’s Department has purchased a certain number of licenses of plaintiff’s software, but made far more copies than it was allowed.²¹Basically, the Sheriff’s Department planned to install the software manually onto its computers, but that took too long, so it started installing bits of the software willy-nilly, without keeping careful track. Eventually, it made 6007 copies when it only had a license for 3663. When the Sheriff’s Department was caught with far too many installations, it didn’t have a lot of great defenses. I mean, really, it didn’t have any at all. The closest thing was: “We did a dumb thing, but no one was really hurt.” Which sort of sounds like it goes to the fourth fair-use factor, so the Sheriff’s Department raised the fair use defense—and took it all the way to appeal. Among other things, the Ninth Circuit held that the second factor weighed against fair use, even though “software products are not purely creative works.” This holding was based on the observation that “copyright law … protects computer software”, and on “undisputed evidence that [the] software products were developed over several years, and required a multi-million dollar investment.” Hmmmm. The court cited no authority for the novel (ahem) idea that sweat of the brow and money can substitute for lack of expression. Such a holding contradicts the long-accepted view that the second factor goes to the degree of expressiveness.²²Wall Data is a prime example of the unfortunate tendency of courts to find that all fair-use factors go the same way (i.e., all of them weigh against fair use or in favor of fair use).

Although the Federal Circuit doesn’t rely on Wall Data in connection with the second factor, it does share the concern that the second factor is a threat to the protection of computer programs. Well, that’s copyright law for you. I’m not aware of any type of copyrightable work that gets any categorical assistance in the fair use analysis. If product numbers come up in a fair-use context, are we going to fret how actually applying the second factor will undermine the important protection copyright provides product numbers? I’ll discuss this more later, but the second factor is the least of software’s protection problems. Without Congressional action²³And maybe not even then, depending on what the free-expression contours of fair use turn out to be., we shouldn’t just ignore a statutory factor just to help a category of works, which also happens to be an industry.

Anyway, no one is saying the second factor is dispositive, only that it’s a factor that should be put into the mix. Software might be at a disadvantage with the second factor, but as we’ve seen, it’s perhaps at an advantage with the first factor. It’s also usually going to be at an advantage with the fourth factor, since most infringement of software will affect the potential market for the underlying software. Fortunately, the vast majority of software cases involve bit-by-bit reproduction, where fair use will rarely arise.

Lots of copyright folks dislike the second factor because it puts copyrighted works into a kind of hierarchy. “Creative” or fanciful works get the most protection against fair use, and things that barely pass the (low) bar for originality, like product numbers and strangely organized phone books, get the least protection. They also point out that the factual matter in a low-originality work is free for the taking; just don’t take the way it’s organized. On the other hand, this has been a factor for a very long time (since at least 1841²⁴The original formulation was “the nature and objects of the selections made,” which has since been divided into the first and second factors, where “objects” might be re-written as “purpose”). And we might take up the Federal Circuit on its invitation to put fair use in terms of the Constitutional purposes of copyright: to encourage expression (well, “promote the progress of science and useful arts”). We are willing to give copyright protection to things we barely recognize as “works,” such as product numbers, but we sure as heck don’t value those things as much as, well, everything we do recognize as works.

The second factor does not require us to make artistic judgments, something copyright law has been careful to warn judges away from. We give copyright protection to the greatest, most imaginative novel or painting ever, and also to those weird brochures you see in your physicians’ offices while you’re waiting, you know, about “Living with [Some Condition]” or “How to Tell if You Have [Some Disease You Might or Might Not Have Heard Of].” Although the word “creative” gets bandied about in this discussion, we’re really interested in original expression, as distinct from facts, functionality and other non-protectable stuff, i.e., the products of your mind²⁵Assuming you’re human. No monkeys, please.. The rules of quidditch are more expressive than the rules of football, which are more expressive than the rules of special relativity.

The score thus far:

• Jury: Factor 1: Push + Factor 2: Weighs in favor of fair use.
• Federal Circuit: Factor 1: Weighs heavily against fair use + Factor 2: Null.
• Me: Factor 1: Weighs against fair use, but not heavily + Factor 2: Weighs significantly in favor of fair use.

Next time, I continue with this analysis for the final two factors.

Thanks for reading!

Rick Sanders

Rick is currently General Counsel for Software Freedom Conservancy. Previously, he has been practicing law as an intellectual-property litigator since 2000.