Supreme Court rules API copying is fair use

[Karlston]

Supreme Court rules API copying is fair use

The ruling heads off an expected wave of lawsuits over API copyrights.

Enlarge / Exterior view of a Googleplex building, the corporate headquarters of Google and parent company Alphabet, May 2018.

Getty Images | zphotos

 

The Supreme Court has sided with Google in its decade-long legal battle with Oracle over the copyright status of application programming interfaces. The ruling means that Google will not owe Oracle billions of dollars in damages. It also has big implications for the broader software industry, since a ruling in the opposite direction could have triggered a wave of lawsuits against software companies that re-implemented other companies' APIs.

 

The case dates back to the creation of the Android platform in the mid-2000s. Google decided to base Android on Sun's Java programming language, enabling existing Java programmers to easily develop for the platform. Google independently implemented the Java API methods, but to ensure compatibility, it copied Java's method names, argument types, and the class and package hierarchy.

 

A few years later, Oracle acquired Sun and soon afterward sued Google, arguing that Google's copying had infringed Sun's copyrights. Over a decade of litigation, Google won twice at the trial court level, but each time, the ruling was overruled by the Federal Circuit appeals court. The case finally reached the Supreme Court last year.

 

Writing for a six-justice majority, Justice Stephen Breyer held that Google's copying of the Java API calls was permissible under copyright's fair use doctrine. The high court punted on whether APIs can be copyrighted in the first place. But the court's fair use reasoning was broad enough that it should provide a strong defense for most API copying, making the question of API copyrights much less important.

 

We'll publish an in-depth analysis of the court's reasoning once we have time to fully digest it and see what the experts are saying.

 

 

Supreme Court rules API copying is fair use

[mp68terr]

Let's hope that it also means that any company can re-use google's api without being sued by google.

[Karlston]

How the Supreme Court saved the software industry from API copyrights

The Supreme Court surprised everyone with its API copyright ruling.

Enlarge / A lot of happy developers out there in the world today.

Aurich Lawson

Google and Oracle's argument before the Supreme Court last October left opponents of API copyrights extremely nervous. For the previous decade, Google had been arguing in lower courts that it didn't infringe copyright law when it re-implemented Java for use in Android. Google had lost—twice—at the appellate level.

 

Last October, justices for the nation's highest court seemed skeptical as well. Not only were they asking Google's lawyer, Tom Goldstein, a lot of tough questions, a number of them didn't seem to even understand what an API was. That seemed like a bad sign for Google because the distinction between code that declares an API and code that implements it was fundamental to Google's argument.

 

In an interview with Ars just after the oral argument, Cornell legal scholar James Grimmelman argued that Goldstein had botched the case.

 

"He did an abysmal job," Grimmelman told me. "At the level of nuance he was willing to get into, his case was a loser."

 

But Grimmelman now admits he was wrong. "I owe an apology to Tom Goldstein," he told me on Monday. "I had my criticisms of the job he did at oral argument, but he did a good enough job to win."

 

By a 6-2 vote, the nation's highest court held that Google's copying of Oracle's Java API was fair use. The ruling means Google won't have to pay billions of dollars in damages to Oracle. It also has huge implications for the broader software industry.

 

"It's a minor miracle we got an opinion that reached the right result with pretty sound reasoning despite not one of the justices being able to explain how an API works," Grimmelman said.

An unexpected focus on fair use

Prior to the ruling, Microsoft filed an amicus brief urging the Supreme Court to side with Google. The brief, which was cited in Monday's ruling, provides one of the best explanations of the stakes in the case.

 

"Developers rely on sharing, modifying, and enhancing previously developed code to create new products and develop new functionality," Microsoft wrote. "Both a cause and effect of this collaborative development is the increased demand for seamless interoperability and compatibility—i.e., the ability of different products, devices, and applications to communicate and work together without effort from the consumer."

 

If APIs became subject to copyright protection, it would become much easier for an incumbent software provider to lock its customers into a proprietary standard. That would create more compatibility headaches for consumers, and it would make it harder for software startups to break in to established software markets. Opponents of API copyrights also warned that a ruling for Oracle could unleash a flood of API copyright lawsuits similar to the patent troll lawsuits of the last 20 years.

 

Opponents of API copyrights were hoping that the Supreme Court would declare that an API can't be protected by copyright at all, making such lawsuits impossible. Oracle, of course, was hoping the Supreme Court would reach the opposite conclusion. But as it often does, the Supreme Court chose to take the case in a different direction.

 

The high court was actually considering two different questions in the case. Google not only argued that APIs can't be copyrighted, Google also argued that its use of Oracle's Java API was legal under copyright's fair use doctrine. The Supreme Court decided to skip over the first question and focus on the second one.

 

"Given the rapidly changing technological, economic, and business-related circumstances, we believe we should not answer more than is necessary to resolve the parties’ dispute," Justice Stephen Breyer wrote in his majority opinion. "We shall assume, but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copyrighted."

 

In other words, the Supreme Court didn't provide any guidance on whether an API can be copyrighted—the main question everyone expected the court to answer. Instead, the court ruled that even if APIs can be copyrighted, Google's copying was protected by fair use.

 

Back in 2016, followers got a look at Oracle's argument against fair use via court slides

First image of article image gallery. Please visit the source link to see all images.

Google went four for four on fair use

As regular readers know, fair use is one of the most important ideas in copyright law. It allows a news site like Ars to blockquote a paragraph from another publication for purposes of commentary and criticism. It allows consumers to record broadcast television shows for later viewing and to transfer legally purchased music between personal devices. A number of Google products rely on fair use, including thumbnails in Google Image Search and scanning for Google Books.

 

Courts consider four major criteria when decided whether a use is fair. The party that wins on a majority of these factors usually wins the case. In Monday's ruling, Justice Breyer concluded that all four of these factors point in Google's direction.

• One factor is the nature of the original copyrighted work. Some types of work get stronger copyright protection than others. Creative works like novels get stronger protections (and hence stricter limits on fair use) than utilitarian works like dictionaries or phone books. In Justice Breyer's view, the code that defines an API is more like a dictionary than a novel. "The declaring code is, if copyrightable at all, further than are most computer programs from the core of copyright," he wrote.
• Another factor is the purpose and character of the copying. Copying is more likely to be fair if it is "transformative"—if it's used to do something new or innovative. The high court pointed to two common reasons people copy APIs: the desire to ensure interoperability between software products and the desire to enable programmers who learned skills on one platform (in this case the Java language) to re-use those skills elsewhere (like making Android apps).
• The third factor is how much material was copied. Google took 11,500 lines of code—mostly function declarations—from Java. That might sound like a lot, but Justice Breyer pointed out that this was a tiny fraction of the 2.8 million lines that make up Oracle's official Java implementation.
• The final factor is the effect of the copying on the market for the original work. Oracle argued that Google's copying had undermined Oracle's business licensing the Java platform to other tech companies. But Justice Breyer wasn't persuaded. He noted that Sun had struggled to gain traction in the mobile phone market in the years before Google launched Android.

Google didn't need to win on all four of these factors in order to beat Oracle. But the fact that Google did win on all four will be important to future defendants, since it gives them a greater margin for error. Even if a defendant can't show that their API copying was exactly like Google's, they're still likely to prevail if they can convince a court that their use was similar to Google in at least three of these four areas.

Justice Breyer’s moment

It's not surprising that Justice Breyer wound up writing the majority opinion. As one of the court's most senior members (after Justice Thomas and Chief Justice Roberts), he is one of the first to choose which opinions to write. Moreover, he is the court's leading copyright scholar, having written a treatise on copyright law way back in 1970.

 

Most importantly, in last October's oral argument, Justice Breyer was the most articulate defender of Google's position—sometimes explaining it more clearly than Google's own lawyer. Here's how I described Breyer's performance last fall:

"It's like the QWERTY keyboard," Breyer said in a question to Oracle's lawyer. "You didn't have to have a QWERTY keyboard on typewriters in the beginning. But my God, if you let somebody have a copyright on that now, they would control all typewriters, which really has nothing to do with copyright."

 

Just as a QWERTY copyright would lock typists into using a particular company's typewriters, Breyer suggested, a copyright to the Java APIs would lock programmers who have learned Java into using only Oracle-licensed Java implementations.

Beyond the specifics of Breyer's fair use analysis, the really important thing about Breyer's ruling is that it clearly articulated how code that defines an API is different from an ordinary computer program and why this difference is important. Justice Breyer repeated his QWERTY analogy in Monday's ruling and compared an API to a gas pedal.

 

"One can think of the declaring code as part of an interface between human beings and a machine," Breyer wrote.

 

Breyer's opinion focused a lot on the role of programmers in the Java ecosystem. A key reason Google wanted to re-implement Java rather than designing a new language from scratch was to make it easy for existing Java programmers to write Android code. Breyer noted that much of the value in Java comes from the time that many Java programmers have invested in learning the Java API.

 

Breyer argued there was no particular reason why the fruits of those investments should belong to Oracle rather than to the programmers themselves. Yet if Oracle has a copyright in the Java API, it would have the power to prevent programmers from taking their skills to new platforms without Oracle's permission.

 

The ruling "focuses attention more clearly on the fact that the interface was held out as a public API," Grimmelman argues. "Programmers have learned how to use Java's APIs and that investment is not something that Sun created."

Enlarge / Last fall, Justice Stephen Breyer argued that API copyrights were akin to allowing a typewriter company to copyright the layout of the QWERTY keyboard.

MANDEL NGAN/AFP via Getty Images

 

This style of reasoning—thinking about the economic and social consequences of legal restrictions—is more familiar to most judges than technical questions like the difference between declaring and implementing code. By focusing on fair use rather than the more fundamental question of whether an API can be copyrighted at all, Breyer may have provided judges with a roadmap for future cases that they will find it easier to understand and follow. That could ultimately lead to a more coherent body of law since it doesn't depend on judges understanding what an API is.

 

Still, University of California legal scholar Pam Samuelson, a critic of API copyrights, argues that there's a significant downside to the focus on fair use rather than copyright eligibility: it might take longer for defendants in API copyright cases to put an end to lawsuits.

 

If an API can't be copyrighted at all, Samuelson says, then defendants can win a motion to dismiss, one of the earliest steps in the litigation process. By contrast, defendants often won't be able to raise a fair use defense until the later summary judgment stage, which means defendants could face higher legal bills.

A broad defense of interoperability?

Monday's ruling will be most helpful for a defendant who copies a public API to build a product that's compatible—but not directly competitive—with the original. This is particularly true in cases where programmers or other professionals have invested time to learn the API as part of their job.

 

But not every case of API copying meets these criteria. For example, sometimes people develop open source re-implementations of proprietary software products. If the new product too closely duplicates the functionality of the original product, a plaintiff could argue that the use is not as transformative as Google's use of Java in Android. A plaintiff could also argue that a directly competitive product undermines the market for the original.

 

But while this week's ruling may not be a slam-dunk for defendants in those circumstances, both Grimmelman and Samuelson argued that the new ruling will be helpful to anyone copying an API for purposes of interoperability.

 

"I read the ruling as having quite a bit of breadth," Samuelson said.

 

While the court didn't say that APIs can't be copyrighted, it also didn't endorse the Federal Circuit's view that APIs can be copyrighted. And that's important because it leaves in place prior appeals court rulings that were widely viewed as prohibiting API copyrights prior to the Federal Circuit's 2014 ruling in the Oracle v. Google case.

 

Probably the most important is a 1996 appellate court ruling that held that Lotus couldn't copyright the organization of the menu hierarchy in its then-popular Lotus 1-2-3 spreadsheet software. Because this menu hierarchy was used in Lotus' system for keyboard macros, it amounted to a primitive API. Breyer cites the Lotus ruling four times, including a passage that directly analogizes an API to a menu hierarchy:

The Sun Java API is a “user interface.” It provides a way through which users (here the programmers) can “manipulate and control” task-performing computer programs “via a series of menu commands.”

This sentence is immediately followed by a citation to the Lotus case. It's hard not to read this as a hint to other courts that Breyer not only considers Lotus to be good law, but he also sees a parallel between Lotus' menu hierarchy and modern APIs.

 

Moreover, Samuelson points out that Breyer approvingly cited two landmark cases from the 1990s—Sega v. Accolade and Sony v. Connectix—that offer strong support for the idea that interoperability is legitimate grounds for fair use.

 

Both cases involved defendants who reverse-engineered gaming consoles to create interoperable products. These old rulings focused on the copies of code made during the reverse-engineering process rather than on the copyright status of APIs. But Samuelson argued that the Supreme Court's favorable citation of these cases is a signal that the high court considers them important precedents relevant to broader questions about interoperability and fair use.

There have been happier weeks at Oracle.

Peter Kaminski / flickr

Broad implications for fair use

"For the Supreme Court to say that it perceived Google's use as transformative as a matter of law, that was a really significant thing," Samuelson said. "It will have spillover effects for other fair use cases, even beyond software. That's one of the reasons a lot of copyright industry groups were filing in support of Oracle on the fair use issue."

 

Fair use law has been shaped by a series of legal precedents that straddle different types of creative works, from books to music to software. For example, the idea that fair uses are often transformative uses dates back to a 1994 Supreme Court ruling finding it was fair for rap group 2 Live Crew to make an unauthorized parody of Roy Orbison's "Oh Pretty Woman." But the concept of transformative use has since been adapted to a wide range of fields—including in this week's Oracle v. Google ruling.

 

By the same token, lawyers representing defendants fighting future copyright battles over books, songs, and movies as well as software will mine Monday's decision for arguments that could support their clients' fair use defenses. The broad language of the ruling will give them a lot of material to work with.

 

Correction: I originally said that Justice Breyer was the most senior associate justice. He is actually the second most senior after Justice Thomas.

 

 

How the Supreme Court saved the software industry from API copyrights

 

(To view the article's image gallery, please visit the above link)