IPLAC/CBA (Chicago) panel
Intro by Adam Wolek, Taft Law
Chris Mohr, GC/VP for IP, Software
& Information Indus. Ass’n.: Didn’t participate in this case b/c we have
members on both sides. Tension b/t © protection of expression and functionality
historically protected by patent. Always been true, including in runup to 1976
Act. Sec. 117 added protections for possessors of lawful copies; rental
protections came later; provisions for machine repair. 102(b) polices two
important boundaries: patent (functionality, e.g. recipes) v. (c) and First
Amendment freedom of ideas. If APIs are protected by (c), then you must
consider fair use and SCt hasn’t spoken on that for over 25 years, so that’s
attracted a lot of amicus focus.
Charles Sanders, outside
counsel, Songwriters Guild of America:
When elephants fight, mice
get trampled; the mice provide the lifeblood through which the elephants run.
There’s a value gap. FAANG are worth billions, even trillions. Meanwhile, 80%
of songwriters lost their jobs as staff writers, other ways of relying on
creative output for living. Same is true for novelists and journalists. There
are many reasons, but unfair and unbalanced marketplace is responsible in large
part. This isn’t what the Framers intended. 12 of 13 original colonies had
copyright laws [that protected neither journalists nor musicians]. Berne
Convention, Human Rights conventions, EU directive recognize cultural and
economic value of ©.
We are hoping SCT will not
continue trend of imbalance. Of course tech advances aren’t hurting creators—creators
love tech advances. It’s predatory market practices of corporations that run
tech that are the problem. Silicon Valley has to realize that the ability to make
trillions gives it a responsibility to the people who supply the raw materials
on which their businesses are built. Spotify is $50 billion on the backs of
music creators solely, and they don’t want to pay market royalties. The concept
that shareholders dictate what boards must do ignores the fact that if you
destroy those who provide you with raw materials to wring short term profits,
you destroy the industry long term. Google is trying to stop the CASE Act,
despite congressional support. They didn’t want to pay market royalties to the
publishers in Google books, and they’re trying to expand fair use around the
world. They’ve received billions of DMCA notices, full albums posted, and they
say that it’s none of their business. [Um, they do have both Content ID and
robust takedown practices.] Infringement isn’t a “permissionless innovation”
technique.
Nation v. Harper & Row: ©
protection was and will always remain the engine of free expression, but 30
years later the 9th Circuit of Silicon Valley [and Hollywood] decide in Lenz
that you have to consider fair use before sending a takedown.
[For really interesting
writing on Spotify and the techniques used by the labels using their deals with
Spotify to cut artists out of the payment loop, I recommend Kristelia Garcia’s excellent
work.]
Peter Menell, Berkeley Law: If
this were Grokster, he’d be more in line with Sanders.
Baker v. Selden:
process/method for accomplishing a task can be protected by patent, not by ©.
Idea/expression frames the dividing line, including methods, even as their implementation
through code is protectable. Thus while detailed code is protectable
potentially, algorithms, function names, and other things necessary to operate
a machine are not. When idea & expression merge, © gives way to avoid monopolistic
protection of functionality.
A car manufacturer could use
a rigid pattern with sculptural qualities as a key to the car, but couldn’t use
© to prevent others from using the same cut pattern for a key to start the car.
The same is true if the ignition switch is digital and turned on with a haiku:
it’s an unprotected purpose. The digital key can be copied as necessary to
start the car because it’s functional. Another example: a beautiful cash
register, with gears/levers essential to functionality unprotected so far as
other cash registers are concerned. Though separable features are protectable—nonmerged
implementing code—only utility patent law can protect features necessary to
operate the machine; indeed this case began as a © case.
Oracle doesn’t dispute that
Google independently implemented the specifications at issue. It did so in a
clean room, using no code from Oracle. This is different from the qwerty
keyboard b/c Java is complicated—you need 1000s of declarations to implement
the API—but that just makes it a very complicated key. Google looked at
publicly available declarations to implement them when negotiations failed,
like hiring a locksmith to make you a new key when you’re locked out.
RT (shorter version of last
week, based on this
amicus): At its core, the fair use argument for Google is about why fair
use is a multifactor test and why there are different kinds of fair uses.
Fair use has four
nonexclusive statutory factors: the purpose of the use, the nature of the
accusing work, the amount of the original work taken, and the effect on the
market for the original work.
Beginning as usual with
factor one: The extent to which a new work has a new meaning, message, or
purpose—transformativeness—is often and rightly prioritized in the fair use
analysis. But what constitutes transformativeness is often contentious. Here,
the new purpose of Google’s new code implementing the declarations was the
creation of a new computing environment in which Java programmers could readily
create programs on multiple platforms, which required the use of limited
portions of highly functional declarations. This type of purpose has been
recognized as transformative because of its role in furthering competition and
innovation. A computer interface supports the creation of other creative works,
and in such situations, it is important to avoid locking in third parties to
specific platforms.
Factors two and three of the
fair use test help define the boundaries of this type of fair use.
The jury heard evidence that
the declarations and classes of the Java SE API were functional, not merely in
the way that all computer code performs a function, but specifically in that
these particular declarations perform their mini-duties in noncreative ways.
The Federal Circuit acknowledged the thinness of the copyright, but it stated
that the second factor never has much weight. But the reasons that factor two
favored Google are highly relevant to the overall fair use analysis. No matter
how much work and how many choices went into producing Java SE, the highly utilitarian
nature of declarations means that copyright grants them thin scope at best.
This thinner scope of protection naturally leads to a broader scope for fair
use, especially in conjunction with factor three.
On factor three, amount, as
the jury heard and evidently credited, Google took an amount from Java SE
considered in the industry to be reasonable in light of its purpose of
developing new, compatible works. In a fair use analysis, it is vitally
important to identify the allegedly infringed work or works. As the statute
commands, the proper inquiry considers the amount taken “in relation to the
copyrighted work as a whole.” As Justin Hughes has written, “If our goal is to
create special incentives for the building of houses, we do not necessarily need
special incentives for the making of bricks or the mixing of mortar. . . ..”
So what was the work at
issue? Both the copyright registrations and industry practice were clear: the
work is Java SE, which had about 5 million lines of code; Google’s implementation
expressing the declarations at issue totals about 11,500 lines. As a
quantitative matter, what was copied was a rounding error.
What’s more, a large number
of books have been published that set forth the Java SE API, in whole or in
part, including the declarations and class structures. Numerous witnesses,
including Sun’s then-CEO who was there when it developed Java, testified that
Google behaved according to industry practice: write your own implementing code
but APIs are for everyone to use. Contrary to what you might have taken away
from the intro, the evidence showed that reimplementing APIs was standard
practice in the industry including
by Oracle.
In this way, the thinness of
the copyright—factor two—interacts with factor three: even if APIs as a whole
cross the line into copyrightability, Google should be able to use declarations
(and the organization they necessarily reflected) that were reasonably
necessary to pursue its legitimate goal of enabling the creation of an
environment accessible to Java programmers.
Which leads to factor four:
By downplaying the relevance of the nature of the work and the amount taken,
the Federal Circuit fell into the well-known trap of circularity: reasoning
that, because Oracle could have charged a license fee for this type of use if
fair use were unavailable, Oracle therefore suffered cognizable market harm.
A thin copyright for
software, including Java SE, provides software copyright owners with meaningful
protection against copying of significant amounts of expression, but meaningful
protection does not require the expansive rights that the Federal Circuit
granted.
Q: what about derivative
works/what do we do about market harm?
RT: Traditional, reasonable,
or likely to be developed is important constraint, and traditional/reasonable
behavior here was something jury heard testimony on. Derivative work right does
not extend to every use, especially when the © is by necessity thin b/c of its
functionality. Same issue comes up with maps and charts, which have thin ©.
Q about scope of what was
taken.
Menell: 11,500 definitions
were taken but those are button labels. They’re not lines from a JK Rowling novel
but names of functions; “ProtectionDomain,” and “Add,” etc. They had to be
included to let someone write a program for Android that would use features
that were part of the Java programming environment. They specified actions
& their interrelationship. That’s why the definitions circulated freely for
programmers, including on Sun/Oracle’s website.
Q: why did so many entities
weigh in? If this wasn’t the right way to protect Oracle’s IP, what should it
have done?
Mohr: Not going to answer #2,
but you see concern from open source companies worried about when they use a
variety of APIs in their language that they will step into a liability
minefield if it’s affirmed; other software companies want to license like
Oracle wants. The other side of it is about avoiding collateral damage—MPAA and
Copyright Alliance, library and user groups. When the SCt says thing about fair
use, it’s so infrequent that it sticks for a while. Language in the Nation
case, about acquiring rightful access to the work. That required some cleanup
and Judge Leval has a long lecture about exactly this point. Thus there’s
concern about how this decision plays out in other areas if the API is found to
be protectable.
Q: is this a good case to
provide guidance?
RT: when the SCt encounters a
multifactor test it almost never leaves things less confusing. Star Athletica
at least went from seven contradictory tests to only one internally contradictory
test, but that wasn’t even a multifactor test.
Sanders: we want the SCt to
issue a narrow decision and not speak carelessly in a way that could haunt the
creative industries for decades.
Q: predictions?
Menell:
not good at those. Breyer will be interested in Google’s position, but SCt
doesn’t see itself as clarifying law or dealing w/fragmentation of law; in IP
they have an instinct for the capillary. They get caught up in issues of stare
decisis and what they call textualism [this is why I’m worried about what they’ll
do with the jury questions]. 102(b) is about as clear as you can get, and it’s
based on one of the greatest cases ever, Baker v. Selden, but the Fed Cir didn’t
see it that way. Asking for supplemental briefing is also a signal—the Court
may not want to overrule a jury finding lightly. There was a big trial, at the
Fed Cir’s direction. This could sidestep the (c)ability issues and that might
be the result.
No comments:
Post a Comment