another G v. O preview, shorter

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.