Source: https://www.ipwatchdog.com/2018/03/27/google-copying-java-api-packages-not-fair-use/id=95319/
Timestamp: 2019-04-22 07:29:25+00:00

Document:
Earlier today, the Federal Circuit issued the latest opinion in a long-standing copyright dispute between tech giants Oracle and Google. See Oracle America, Inc. v. Google LLC. This copyright case returned to the Federal Circuit after a second jury trial, which focused on Google’s fair use defense. In a ruling that is virtually certain to be appealed, the Federal Circuit found Google’s use of Java application programming interface (‘API packages’) not fair as a matter of law, reversing the district court’s decision on the matter. The decision resurrects a multi-billion dollar copyright case brought by Oracle Corp against Google.
If Google does not request en banc rehearing by the full Federal Circuit and does not appeal to the United States Supreme Court, the case will return to the district court for a trial on damages. Having said that, it is worth noting that this 56-page opinion authored by Judge Kathleen O’Malley (and joined by Judges Plager and Taranto, at times reads like a treatise on fair use. There are certainly no obvious errors in the Federal Circuit’s analysis, and the opinion heavily cites to Supreme Court precedent, as well as the record evidence. Indeed, this decision is written in such a way as to likely make it extraordinarily difficult for Google to successfully convince the Supreme Court to review and ultimately reverse the Federal Circuit’s decision.
Oracle America initially filed suit against Google in the United States District Court for the Northern District of California, alleging that Google’s unauthorized use of 37 packages of Oracle’s Java API packages in its Android operating system infringed Oracle’s patents and copyrights. At the first trial, the jury found that Google infringed Oracle’s copyrights in the Java Standard Edition platform, but deadlocked on the question of whether Google’s copying was a fair use. The jury found no patent infringement, and the patent claims are not at issue on appeal.
After the jury verdict in the first trial the district court found that the API packages were not copyrightable as a matter of law and entered judgment for Google. Oracle Am., Inc. v. Google Inc., 872 F. Supp. 2d 974 (N.D. Cal. 2012). Oracle appealed that determination to the Federal Circuit, and the Federal Circuit reversed, finding that declaring code and the structure, sequence, and organization (“SSO”) of the Java API packages are entitled to copyright protection. Oracle Am., Inc. v. Google Inc., 750 F.3d 1339, 1348 (Fed. Cir. 2014). The Federal Circuit remanded the matter to the district court with instructions to reinstate the jury’s infringement verdict and for further proceedings on Google’s fair use defense and, if appropriate, on damages. Id. at 1381.
Google subsequently filed a petition for certiorari on the copyrightability determination. The Supreme Court called for the views of the Solicitor General, and the Solicitor General agreed with the Federal Circuit’s ruling, ultimately recommending the Supreme Court deny certiorari. The Supreme Court did, in fact, deny certiorari in 2015. See Google Inc. v. Oracle America, Inc., 135 S.Ct. 2887 (2015). This resulted in the case being returned to the district court for proceedings on Google’s fair use defense, and damages in the event the district court found fair use unavailable to defend Google’s copying.
At the second jury trial, Google prevailed on its fair use defense. After the jury verdict, the district court denied Oracle’s motion for judgment as a matter of law (“JMOL”) and entered final judgment in favor of Google. Oracle filed a renewed motion for JMOL and separately moved for a new trial. The district court denied both motions. Given that the district court found Google’s copying to be a fair use, no damages verdict was rendered.
Oracle then appealed from the district court’s final judgment and its decisions denying Oracle’s motions for JMOL and motion for a new trial. Google cross-appealed from the final judgment in order to preserve argument that the declarations/SSO are not copyrightable. Google did not, however, advance any argument for why the Federal Circuit could or should revisit the copyrightability decision made in the first appeal. Therefore, the Federal Circuit dismissed Google’s cross-appeal.
It was undisputed that Google copied Oracle’s declaring code and SSO for the 37 API packages verbatim. Therefore, the question presented was simply whether that verbatim copying constituted a fair use. Because fair use is an affirmative defense to a claim of copyright infringement, it was Google’s burden to prove that the statutory factors weighed in its favor of finding fair use pursuant to 17 U.S.C. 107.
On appeal, Oracle argued that each of the four statutory factors weighed against a finding of fair use. Specifically, it argued that: (1) the purpose and character of Google’s use was purely for commercial purposes; (2) the nature of Oracle’s work is highly creative; (3) Google copied 11,330 more lines of code than necessary to write in a Java language-based program; and (4) Oracle’s customers stopped licensing Java SE and switched to Android because Google provided free access to it.
The purpose and character of the use of the copyrighted work is the first factor that must be considered in a fair use analysis. On this point the Federal Circuit was simply unconvinced that Google’s use of the API packages was “anything other than overwhelmingly commercial”.
Although the Copyright Act does not use the word “transformative,” the Supreme Court has consistently ruled that the first factor in the fair use analysis is for the purpose of determining whether and to what extent the use of the copyrighted work is transformative. The more transformative a work the less significant any of the other factors become. Indeed, a finding that a work is transformative can be nearly dispositive.
The final relevant consideration under the first factor is whether the defendant acted in bad faith. “[E]ven assuming the jury was unpersuaded that Google acted in bad faith, the highly commercial and non-transformative nature of the use strongly support the conclusion that the first factor weighs against a finding of fair use,” wrote Judge Kathleen O’Malley for the unanimous Federal Circuit panel.
Accordingly, Google’s non-transformative, commercial use of the Java API packages weighed against a finding of fair use.
This second factor in the fair use analysis turns on whether the work is informational or creative, recognizing that certain works are closer to the core of what copyright protection is intended to cover. On this factor the Federal Circuit found the nature of the work, although creative and copyrightable, to be influenced by functional considerations.
The third factor to be considered focuses on how much of the work is used, but does so in the context of the copyrighted work, not in the context of the infringing work. Fair use can be denied even if amount taken can be seem relatively de minimus if that which is copied lies at the heart of the copyrighted work. Indeed, in Harper & Row Publishers, Inc. v. Nation Enters., 471 U.S. 539 (1985), the Supreme Court found that 350 words copied from book were too many because they were qualitatively the most valuable (i.e., the reason why President Gerald Ford pardoned President Richard Nixon).
“Even assuming the jury accepted Google’s argument that it copied only a small portion of Java, no reasonable jury could conclude that what was copied was qualitatively insignificant, particularly when the material copied was important to the creation of the Android platform,” wrote Judge O’Malley.
Although none of the factors can be viewed in isolation, the Supreme Court has referred to the final factor in the fair use analysis as “undoubtedly the single most important element of fair use.” See Harper & Row, 471 U.S. at 566-67.
In light of the fact that the Federal Circuit found the most important factor weighing against a finding of fair use (i.e., Factor 4) and similarly found the work to be a non-transformative, commercial use (i.e., Factor 1), the Court had little problem finding Google’s use to fail to qualify as a fair use.
I suspect Google will seek an en banc rehearing by the Federal Circuit, which will be denied. I also expect Google to petition the Supreme Court for a writ of certiorari, which will likewise be denied. Ultimately, with copyrightability and fair use decided, this case will head back to the district court for a damages trial with the sole question being how much money Google owes Oracle America. That sum could be enormous.
It’s been a while since I read the court documents. I will refresh my memory if a have a chance. This case arises from terminological confusion.
In the C programming, one defines an application programming interface (API or interface for short).
One can specify a C interface by defining the function or subroutine name as well as the formal parameters and order thereof with which the function is called. Such a definition involves no copying of software source code (i.e, IP), which might be subject to copyright restriction.
In Java an interface (almost never called an API by a software engineer that actually programs in Java) is a Java code construct which a Java class may implement (a Java language key). Thus copying a Java interface inherently means copying software source code, which in this case is subject to copyright restriction.
In a Maven build a Java application might depend on classes and interfaces found in Java packages which are located in a Java ARchive or JAR. One can view a Maven pom.xml (Project Object Model . eXtended Markup Language) here. The pom.xml identifies the JARs (and other things) on which a Java project depends. The Java development world is different from the C language development world.
Google generally does not respect the IP rights of others and appears to have hoped that terminological issues in this case would make it possible for Google to get away with IP theft.
This terminological problem would not have arisen if Java used the keywords of Scala (another JVM language). Scala uses the keyword trait more or less as Java uses the keyword interface. A Scala object or class has a trait whereas a Java class implements an interface.
The above pom.xml causes the KnightMove application to incorporate the Simple Logging Facade for Java (even if the interface is not actually used in the code).
There is a lot of source code in that Github repository.
The URL below gives the Unix System V Interface Definition. One won’t find a lot actual System V source code there even if there is some example code.
So, I am trying to get my head around what this means for software protection.
What should we be looking at to protect with copyright?
OT, but another narrative that the anti-patent judicial activist keep pushing is that the claims of US patents are broader and easier to get than in other countries.
I do a lot of prosecution. I write about 30-40 applications a year. I do probably 40 foreign office actions a year (only the important ones) and probably about 100 US office actions a year.
In my experience it is just as hard to get claims allowed in the US as anywhere in the world. The claims I prosecute are typically charted claims. I also write like 20 claim charts a year. It has become common place for me to get a positive IPRP (which means lots of countries will allow the claims) and yet be fighting tooth and nail with the US. I often get claims allowed at the EP that fall in the US. The US examiners are tough and clever. They often think outside the box to reject claims and know that KSR and Alice have their back.
Reality is that getting claims allowed in the US is as tough as anywhere in the world. The only thing the EP has over us is they do a better search and I think they do a better job of assigning the applications so it is rare to deal with an EP examiner that is familiar with the field of the claims.
Nature will find a balance and Google leaderships luck will run out. The AIA lobbying, win over Viacom for YouTube, and calendistine weakening of rights of creatives in the name of progress have gone too far.
The short answer: same as it ever was: expression.
Are you slipping back into some sort of “either/or” paradigm with the different avenues of intellectual property protection?
Please keep in mind that a single creation of the hand of man may rightfully obtain different protections for different aspects of the creation under the different IP regimes.
Something that has the aspects of functionality and utility may also have aspects of expression. It is only at the extreme end of the spectrum (the merger doctrine) that the expression aspects can no longer obtain the different protection of copyright.
>>that is NOT familiar with the field of the claims.
I get that Anon. Just trying to think about what to tell clients and how to think about this. So, a client with a new website and some new functionality. Just not sure how to think about this clearly.
Where does the “NOT familiar” come from and how does that intersect with the rather straight forward notion that something may have multiple different aspects that garner protection under multiple different IP regimes?
You seem to be making this more difficult than necessary.
Seems to me that the API is functional, and that since copyright does not protect functional features, the API is not protectable and the doctrine of Baker v. Selden, 101 U.S. 99 (1879) should apply.
The API is functional and is not protected by copyright. The code is not functional and is protected by copyright.
Your citation to Baker v. Selden, which relates to a printed form, is entirely misplaced. The copyrightability of software has been thoroughly litigated in many courts for many years and is very well settled.
The issue of copyrightability of the code for an API is not at issue, and has been finally decided in this case years ago. That decision was not taken by the Supreme Court, and even the Solicitor General said the Federal Circuit got that issue correct. It is no longer debatable (if it ever was).
It is NOT an “either/or” proposition, and it is ONLY the expressive aspects of the item that may also have functional aspects, to which any copyright protection extends to.
This has nothing to do with the case that you offer.
May I suggest that you review the copyright merger doctrine to clarify this for yourself?
Gene you can’t perform the function of Baker’s bookkeeping without using the form, so the form is not protected. In the same manner, you cannot connect to Java without using the API. I will defer to Anon’s comment that the merger doctrine is more apt when talking copyrightlawese, but the legal effect should be the same.
Frankly, I think Oracle is being given functional, patent-like protection for it only-copyrighted work.
Oracle is not being given patent like protection for a copyrighted work. Go through the latest Federal Circuit decision and note that Google admitted that they could have coded the API differently, but chose to copy it exactly in order to make things easier. That is a copyright violation pure and simple. It also specifically addresses your point and proves that Oracle is not receiving patent like protection. With a patent on software the owner can prevent someone from creating the same functionality regardless of the coding language, regardless of the coding choices (i.e., how it is coded). With a copyright the only thing that is protected is copying. Typically the only thing protected is identical copying really (but legally too broad to say that in all copyright cases). Still with software code a copyright has historically only prevented cut and paste copying. If you write the code in a different language, or if you use the same language but write different code independently and without cutting and pasting, then there could not be a copyright violation. This is why copyrights in software code do not protect function, but rather protect the explicit expression of the code.
You might also search for cases from various Courts of Appeals that explain that software code is protected under the First Amendment because it is expressive. This issue came up about 20-25 years ago in a number of encryption cases.
In those cases in which merger doctrine is established, the result WILL BE the same.
The items being merged are the example of the extreme situation. Most all situations will NOT be that extreme, and the (rather simple) notion that the different aspects relating to different coverage for different IP yields a NON-binary “either/or” position.
Should read: …Yields a NON-binary “something other than either/or” position.

References: v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v.