Federal Appeals Court Decision in Oracle v. Google

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2014/05/10/oracle-google.html

[ Update on 2014-05-13: If you’re more of a listening
rather than reading type, you might
enjoy the Free as
in Freedom
oggcast that
Karen Sandler and I recorded about this topic
. ]

I have a strange relationship with copyright law. Many copyright policies
of various jurisdictions, the USA in particular, are draconian at best and
downright vindictive at worst. For example, during the public comment
period on ACTA, I
commented that
I think it’s always wrong, as a policy matter, for
copyright infringement to carry criminal penalties.

That said, much of what I do in my work in the software freedom movement
is enforcement of copyleft: assuring that the primary legal tool, which
defends the freedom of the Free Software, functions properly, and actually
works — in the real world — the way it should.

As I’ve written
about before at great length
, copyleft functions primarily because it
uses copyright law to stand up and
defend the four
freedoms
. It’s commonly called a hack on copyright: turning the
copyright system which is canonically used to restrict users’ rights, into
a system of justice for the equality of users.

However, it’s this very activity that leaves me with a weird relationship
with copyright. Copyleft uses the restrictive force of copyright in the
other direction, but that means the greater the negative force, the more
powerful the positive force. So, as I read yesterday
the Federal
Circuit Appeals Court’s decision in Oracle v. Google
, I had that
strange feeling of simultaneous annoyance and contentment. In this blog
post, I attempt to state why I am both glad for and annoyed with the
decision.

I stated clearly
after Alsup’s decision NDCA decision in this case
that I never thought
APIs were copyrightable, nor does any developer really think so in
practice. But, when considering the appeal, note carefully that the
court of appeals wasn’t assigned the general job of considering whether
APIs are copyrightable. Their job is to figure out if the lower court
made an error in judgment in this particular case, and to
discern any issues that were missed previously. I think that’s what the
Federal Circuit Court attempted to do here, and while IMO they too erred
regarding a factual issue, I don’t think their decision is wholly useless
nor categorically incorrect.

Their decision is worth reading in full. I’d also urge anyone who wants
to opine on this decision to actually read the whole thing (which
so often rarely happens in these situations). I bet most pundits out there
opining already didn’t read the whole thing. I read the decision as soon
as it was announced, and I didn’t get this post up until early Saturday
morning, because it took that long to read the opinion in detail, go back
to other related texts and verify some details and then write down my
analysis. So, please, go ahead, read it now before reading this blog post
further. My post will still be here when you get back. (And, BTW, don’t
fall for that self-aggrandizing ballyhoo some lawyers will feed you that
only they can understand things like court decisions. In fact, I think
programmers are going to have an easier time reading decisions about this
topic than lawyers, as the technical facts are highly pertinent.)

Ok,
you’ve read
the decision now
? Good. Now, I’ll tell you what I think in detail: (As
always, my opinions on this are my own,
IANAL and
TINLA and these are my
personal thoughts on the question.)

The most interesting thing, IMO,
about this decision is that the Court focused on a fact from trial that
clearly has more nuance than they realize. Specifically, the Court claims
many times in this decision that Google conceded that it copied the
declaring code used in the 37 packages verbatim
(pg 12 of the Appeals
decision
).

I suspect the Court imagined the situation too simply: that there was a
huge body of source code text, and that Google engineers sat there, simply
cutting-and-pasting from Oracle’s code right into their own code for each of
the 7,000 lines or so of function declarations. However, I’ve chatted with
some people (including Mark
J. Wielaard
) who are much more deeply embedded in the Free Software Java
world than I am, and they pointed out it’s highly unlikely anyone did a
blatant cut-and-paste job to implement Java’s core library API, for various
reasons. I thus suspect that Google didn’t do it that way either.

So, how did the Appeals Court come to this erroneous conclusion? On page
27 of their decision, they write: Google conceded that it copied it
verbatim. Indeed, the district court specifically instructed the jury that
‘Google agrees that it uses the same names and declarations’ in
Android.
Charge to the Jury at 10. So, I reread
page
10 of the final charge to the jury
. It actually says something much
more verbose and nuanced. I’ve pasted together below all the parts where
the Alsup’s jury charge mentions this issue (emphasis mine):

Google denies infringing any such copyrighted material … Google agrees
that the structure, sequence and organization of the 37 accused API packages
in Android is substantially the same as the structure, sequence and
organization of the corresponding 37 API packages in Java. …
The copyrighted Java platform has more than 37 API packages and so
does the accused Android platform. As for the 37 API packages that overlap,
Google agrees that it uses the same names and declarations but contends that
its line-by-line implementations are different … Google agrees that
the structure, sequence and organization of the 37 accused API packages in
Android is substantially the same as the structure, sequence and
organization of the corresponding 37 API packages in Java. Google states,
however, that the elements it has used are not infringing …
With respect to the API documentation, Oracle contends Google copied
the English-language comments in the registered copyrighted work and moved
them over to the documentation for the 37 API packages in Android. Google
agrees that there are similarities in the wording but, pointing to differences as
well, denies that its documentation is a copy
. Google further asserts that the
similarities are largely the result of the fact that each API carries out the same
functions
in both systems.

Thus, in the original trial, Google did not admit to
copying of any of Oracle’s text, documentation or code (other than the
rangeCheck thing, which is moot on the API copyrightability issue).
Rather, Google said two separate things: (a) they did not copy any material
(other than rangeCheck), and (b) admitted that the names and declarations
are the same, not because Google copied those names and
declarations from Oracle’s own work, but because they perform the same
functions. In other words, Google makes various arguments of why those
names and declarations look the same, but for reasons other than
“mundane cut-and-paste copying from Oracle’s copyrighted
works”.

For we programmers, this is of course a distinction without any
difference. Frankly, programmers, when we look at this situation, we’d
make many obvious logical leaps at once. Specifically, we all think APIs
in the abstract can’t possibly be copyrightable (since that’s absurd), and
we work backwards from there with some quick thinking, that goes something
like this: it doesn’t make sense for APIs to be copyrightable because if
you explain to me with enough detail what the API has to, such that I have
sufficient information to implement, my declarations of the functions of
that API are going to necessarily be quite similar to yours — so much
so that it’ll be nearly indistinguishable from what those function
declarations might look like if I cut-and-pasted them. So, the fact is, if
we both sit down separately to implement the same API, well, then we’re
likely going to have two works that look similar. However, it doesn’t mean
I copied your work. And, besides, it makes no sense for APIs, as a general
concept, to be copyrightable so why are we discussing this
again?0

But this is reasoning a programmer can love but the Courts hate. The
Courts want to take a set of laws the legislature passed, some precedents
that their system gave them, along with a specific set of facts, and then
see what happens when the law is applied to those facts. Juries, in turn,
have the job of finding which facts are accurate, which aren’t, and then
coming to a verdict, upon receiving instructions about the law from the
Court.

And that’s right where the confusion began in this case, IMO. The
original jury, to start with, likely had trouble distinguishing three
distinct things: the general concept of an API, the specification of the
API, and the implementation of an API. Plus, they were told by the judge
to assume API’s were copyrightable anyway. Then, it got more confusing
when they looked at two implementations of an API, parts of which looked
similar for purely mundane technical reasons, and assumed (incorrectly)
that textual copying from one file to another was the only way to get to
that same result. Meanwhile, the jury was likely further confused that
Google argued
various affirmative
defenses
against copyright
infringement in
the alternative
.

So, what happens with the Appeals Court? The Appeals court, of course,
has no reason to believe the finding of fact of the jury is wrong, and it’s
simply not the appeals court’s job to replace the original jury’s job, but to
analyze the matters of law decided by the lower court. That’s why I’m
admittedly troubled and downright confused that the ruling from the Appeals
court seems to conflate the issue of literal copying of text and
similarities in independently developed text. That is a factual issue in
any given case, but that question of fact is the central nuance to API
copyrightiable and it seems the Appeals Court glossed over it. The Appeals
Court simply fails to distinguish between literal cut-and-paste copying
from a given API’s implementation and serendipitous similarities that are
likely to happen when two API implementations support the same API.

But that error isn’t the interesting part. Of course, this error is a
fundamental incorrect assumption by the Appeals Court, and as such the
primary ruling are effectively conclusions based on a hypothetical fact
pattern and not the actual fact pattern in this case. However, after
poring over the decision for hours, it’s the only error that I found in
the appeals ruling. Thus, setting the fundamental error aside, their
ruling has some good parts. For example, I’m rather impressed and swayed
by their argument that the lower court misapplied the merger doctrine
because it analyzed the situation based on the decisions Google had with
regard to functionality, rather than the decisions of Sun/Oracle. To
quote:

We further find that the district court erred in focusing its merger analysis
on the options available to Google at the time of copying. It is
well-established that copyrightability and the scope of protectable activity
are to be evaluated at the time of creation, not at the time of infringement.
… The focus is, therefore, on the options that were available to
Sun/Oracle at the time it created the API packages.

Of course, cropping up again in that analysis is that same darned
confusion the Court had with regard to copying this declaration code. The
ruling goes on to say: But, as the court acknowledged, nothing prevented
Google from writing its own declaring code, along with its own implementing
code, to achieve the same result.

To go back to my earlier point, Google likely did write their own
declaring code, and the code ended up looking the same as the
other code, because there was no other way to implement the same API.

In the end, Mark J. Wielaard put it best when he read the decision,
pointing out to me that the Appeals Court seemed almost angry that the jury
hung on the fair use question. It reads to me, too, like Appeals Court is
slyly saying: the right affirmative defense for Google here is fair use,
and that a new jury really needs to sit and look at it
.

My conclusion is that this just isn’t a decision about the copyrightable
of APIs in the general sense. The question the Court would need to
consider to actually settle that question would be: “If we believe an
API itself isn’t copyrightable, but its implementation is, how do we figure
out when copyright infringement has occurred when there are multiple
implementations of the same API floating around, which of course have
declarations that look similar?” But the court did not consider that
fundamental question, because the Court assumed (incorrectly)
there was textual cut-and-paste copying. The decision here, in my
view, is about a more narrow, hypothetical question that the Court decided
to ask itself instead: “If someone textually copies parts of your API
implementation, are
merger
doctrine
, scènes
à faire
,
and de
minimis
affirmative defenses like to succeed?“ In this
hypothetical scenario, the Appeals Court claims “such defenses rarely help you, but
a fair use defense might help you”.

However, on this point, in my copyleft-defender role, I don’t mind this
decision very much. The one thing this decision clearly seems to declare
is: “if there is even a modicum of evidence that direct textual
copying occurred, then the alleged infringer must pass an extremely high
bar of affirmative defense to show infringement didn’t occur”. In most GPL violation cases,
the facts aren’t nuanced: there is always clearly an intention to
incorporate and distribute large textual parts of the GPL’d code (i.e., not
just a few function declarations). As such, this decision is probably good
for copyleft, since on its narrowest reading, this decision upholds the
idea that if you go mixing in other copyrighted stuff, via copying and
distribution, then it will be difficult to show no copyright infringement
occurred.

OTOH, I suspect that most pundits are going to look at this in an overly
contrasted way: NDCA said API’s aren’t copyrightable, and the Appeals Court
said they are. That’s not what happened here, and if you look at the
situation that way, you’re making the same kinds of oversimplications that
the Appeals Court seems to have erroneously made.

The most positive outcome here is that a new jury can now narrowly
consider the question of fair use as it relates to serendipitous similarity
of multiple API function declaration code. I suspect a fresh jury focused
on that narrow question will do a much better job. The previous jury had
so many complex issues before them, I suspect that they were easily
conflated. (Recall that the previous
jury considered
patent questions as well
.) I’ve found that people who haven’t spent
their lives training (as programmers and lawyers have) to delineate complex
matters and separate truly unrelated issues do a poor job at such. Thus, I
suspect the jury won’t hang the second time if they’re just considering the
fair use question.

Finally, with regard to this ruling, I suspect this won’t become
immediate, frequently cited precedent. The case is remanded, so a new jury
will first sit down and consider the fair use question. If that jury finds
fair use and thus no infringement, Oracle’s next appeal will be quite weak,
and the Appeals Court likely won’t reexamine the question in any detail.
In that outcome, very little has changed overall: we’ll have certainty that
API’s aren’t copyrightable, as long as any textual copying that occurs
during reimplementation is easily called fair use. By contrast, if the new
jury rejects Google’s fair use defense, I suspect Google will have to
appeal all the way to SCOTUS. It’s thus going to be at least two years
before anything definitive is decided, and the big winners will be wealthy
litigation attorneys — as usual.


0This is of course true
for any sufficiently simple programming task. I used to be a high-school
computer science teacher. Frankly, while I was successful twice in detecting
student plagiarism, it was pretty easy to get false positives sometimes. And
certainly I had plenty of student programmers who wrote their function
declarations the same for the same job! And no, those weren’t the
students who plagiarized.