This article was originally written and published on jbtlonline.com by Ryan Ullman.
Oracle claimed close to $9 billion in its initial suit for Google allegedly infringing Oracle’s copyright by copying verbatim without authorization the declaring code and SSO of 37 Java API packages—11,500 lines of Oracle’s copyrighted code – for use in Google’s Android smartphones. This was after negotiations between Oracle and Google had reached an impasse and Google decided to “[d]o Java anyway and defend [its] decision, perhaps making enemies along the way.”
After reviewing all of the factors, the Federal Circuit concluded that allowing Google to commercially exploit Oracle’s APIs would not advance the purposes of copyright. Although Google could have furthered copyright’s goals of promoting creative expression and innovation by developing its own APIs, or by licensing Oracle’s APIs for use in developing a new platform, it chose to copy Oracle’s creative efforts instead. The court reasoned that
“there is nothing fair about taking a copyrighted work verbatim and using it for the same purpose and function as the original in a competing platform. Android’s release effectively replaced Java SE as the supplier of Oracle’s copyrighted works and prevented Oracle from participating in developing markets. This superseding use is inherently unfair.”
Oracle America, Inc. v. Google LLC, 2018 WL 1473875 at 23.
The Federal Circuit’s decision will reverse the second jury verdict in this case since it was initially filed in 2010. At Oracle’s first trial, the jury found that Google infringed Oracle’s Java Standard Edition platform copyrights, but was deadlocked on the question of whether Google’s copying the code API was fair use. Regardless, after the verdict, 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 the district court judgment to the Federal Circuit, which found the code/SSO copyrightable and in turn remanded with instructions to reinstate the jury’s infringement verdict and for further proceedings on Google’s fair use defense. In response, Google filed a petition for certiorari on the copyrightability determination, rather than petition the Federal Circuit for rehearing. The Supreme Court denied certiorari in 2015 after calling for the views of the Solicitor General, who expressed agreement with the Federal Circuit and recommended denying review.
Tech industry response
Some involved in the tech industry are worried about potentially increased costs of software and application development as a result of the decision. Others aren’t so sure the Federal Circuit’s decision will have much of an effect.
Mike Masnick from Tech Dirt thinks the Federal Circuit’s decision was completely wrong, and “insanity.”
Masnick says “the [Federal Circuit] does an awful lot of handwaving around historical precedent to justify its decision to basically start from scratch in going through the fair use four factors. As [I]’ve discussed multiple times, one of the problems with the four factors test is that it allows a court to choose who it likes better, and then twist the four factors to give it the outcome it wants.” Masnick also argues, contrary to the Federal Circuit’s insistence, that API is not copyrightable under 17 U.S.C. § 102, which says:
In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.
According to Masnick, an “API is pretty clearly a procedure, process, system or method of operation — it’s just instructions on how to access certain elements, similar to a recipe.”
For Reuters, Google spokesman Patrick Lenihan said, “This type of ruling will make apps and online services more expensive for users.” “We are disappointed the court reversed the jury finding that Java is open and free for everyone.”
On the other side, in a press statement, Dorian Daley, Oracle’s general counsel, wrote, “The Federal Circuit’s opinion upholds fundamental principles of copyright law and makes clear that Google violated the law. This decision protects creators and consumers from the unlawful abuse of their rights.”
What about programmers who suddenly have copyrightable material they didn’t have before?
It goes without saying that many programs and languages have come out since 1978, which extends copyrights established after that year usually 70 years past the death of the holder. Now that APIs, for the foreseeable future, are copyrightable, should software developers hire lawyers to seek out infringers and get their cut?
Such efforts would probably not be very rewarding.
Because these developers didn’t expect that their APIs were protected by copyright, they wouldn’t have registered their copyrights. This means that they could only seek damages for unregistered copyright infringement, which are limited to actual damages.
Actual damages would be difficult to accurately calculate in these cases because there wouldn’t be any history of licensing revenue for the developers to look toward to establish damages. The plaintiff would thus have to resort to estimating a count of violations and a fair licensing price, which means the recoveries would likely be very low.
In addition, parties cannot be reimbursed for their attorneys’ fees for unregistered copyright claims so there would be even lesser incentive to litigate with fees taking a large chunk of an already small reward. 17 U.S.C. § 412.
Either way, the potential exists for unregistered copyright cases to pop up sometime in the future in the right circumstances. Software developers should pay close attention to Oracle v. Google to see what kind of damages are awarded at trial and what arguments Google presents.
This third trial on damages is probably not the last stop on the Oracle v. Google litigation train, but it is bound to make an impact on copyright law and software development practices moving forward, as it has done already.
Author: Ryan Ullman
Law student, productivity buff, blogger, flow-seeker. Loves the outdoors and coffee.