The Supreme Court Questions on Google v. Oracle lawsuit
For Oracle and Google, the lawsuit is about whether Oracle, which owns Java Standard Edition ,is now entitled to a piece of Android, to the tune of billions of dollars For everyone else, *the lawsuit is about whether language compatibility is tantamount to copyright infringement.*
The case revolves when Google Oracl JV fell apart.. these 37 APIs were reimplemented in a clean room. _Oracle is not asserting that they are verbatim the same, but rather that the “structure, sequence, and organization” of the APIs are so similar as to violate copyright law. By this, it means that the packages, classes, and methods in these APIs are named the same.
The Supreme Court’s decision in Google v. Oracle might have huge ramifications for the software industry, most importantly because the Supreme Court may be revisiting the copyrightability issue the question of whether the declaring code and structure, sequence, and organization of the Java APIs are covered by copyright law at all which hasn’t been in play since 2014. as per the Verge release.
Ten years after Oracle first sued Google over the code in the Android platform, the two tech giants are finally facing off in the Supreme Court. Since then, there have been three trials and two appeals. Billions of dollars are at stake; many millions have been likely spent on a parade of seasoned litigators, expert witnesses, and bizarre trial exhibits intended to explain programming to non-technical juries. All this may be coming to an anticlimactic close on Wednesday morning, with a teleconference Supreme Court oral argument in the middle of a pandemic.
When Google first developed Android, it decided to make the mobile platform compatible with Java. At the time, apps for the iOS environment were written in Objective-C, a language that was similar to the ubiquitous C but otherwise pretty much only used in the context of iOS app development. Apple had a significant head start in mobile.
Google was aiming to make Android competitive by making the platform interoperable with Java, a popular programming language with a robust developer community. In order to do that, the company reimplemented several Java APIs, including the 37 that are at issue in the lawsuit. For Oracle and Google, the lawsuit is about whether Oracle - which owns Java Standard Edition - is now entitled to a piece of Android, to the tune of billions of dollars. For everyone else, the lawsuit is about whether language compatibility is tantamount to copyright infringement.
To say the very least, it was a different world when the case was first filed. Both companies have changed hands - the lawsuit began while Larry Ellison was still at the helm of Oracle and Eric Schmidt was the CEO of Google. Google is now a subsidiary of Alphabet. Android is on version 11. The only thing that seems to have stayed the same is the popularity of Java as a programming language.
But far away from Silicon Valley, there’s been a sea change that encompasses much more than a mere $6 billion and the future of copyright law. Three Supreme Court seats have been vacated since the last time Google asked the high court to review its case. In 2014, SCOTUS denied certiorari, sending the case back to the district court in San Francisco for a retrial. Since then, one justice has retired and two have passed away - most recently, Justice Ruth Bader Ginsburg.
The absolute least important part of Ginsburg’s legacy is that she was the most reliable vote in copyright law cases, tending to vote in favor of rights-holders. Her loss also means that Google v. Oracle is being heard by eight justices and is therefore prone to a split court. (In the 1996 software copyright case Lotus v. Borland, an eight-justice court split evenly and was unable to set national precedent).
When Google v. Oracle began in 2010, it involved seven patents as well as a copyright claim; by 2012, the case had been whittled down to a mere 37 Java APIs, made up of about 11,500 lines of code. (Estimates put Android around 12 million lines of code.) The 11,500 lines of code at issue were written in a “clean room,” a project siloed away from the existing code they were reverse-engineering. This feat of engineering became necessary when negotiations between Google and Sun Microsystems - which owned the Java platform - failed. Oracle acquired Sun in early 2010; by August, it had filed suit against Google.
An application programming interface (API) in this context is a collection of well-defined interactions in software programming. It is a shorthand to quickly access services, libraries, and other functions. An API can condense commonly used or verbose code, allowing programmers to build without having to reinvent the wheel.
An API is not exactly a dictionary, but it’s close enough to one that Oracle v. Google poses a huge problem. Technically, you can program in Java without using the 37 Java API packages at issue. But you probably wouldn’t be writing anything useful, since those APIs include java.lang and java.util, basic packages that offer functions like doing math or representing dates and times. I can also technically write this article without any metaphors or similes, but it’s not something that I would want to do, or that anyone would want to read.
To be clear, the 37 Java APIs were reimplemented in a clean room. Oracle is not asserting that they are verbatim the same, but rather that the “structure, sequence, and organization” of the APIs are so similar as to violate copyright law. By this, it means that the packages, classes, and methods in these APIs are named the same. A line of code written to run in Java Standard Edition won’t necessarily run on Android, but it’ll come a lot closer than it would have otherwise.
The very first run at the lawsuit resulted in a bifurcated trial in 2012 - one trial for the patent claims, and a second trial just for the copyright claims. In the patent trial, the jury ruled that Google had not infringed any patents. In the copyright trial, two separate legal points were at issue: first, whether the declaring code and “structure, sequence, and organization” of the APIs were copyrightable; and second, whether Google’s use was a fair use. The judge ruled on the copyrightability issue, and sent the fair use issue to be assessed by the jury.
The jury hung on fair use. But the judge - who coincidentally wrote code as a hobby - ruled that the declaring code and SSO of the APIs were not covered by copyright after all. The Copyright Act does not apply to any “idea, procedure, process, system, method of operation,” and the way that the packages, classes, and methods were named and sorted was too functional to be deemed worthy of copyright.
It was this specific ruling that was overturned by the Federal Circuit in 2014. Because the first jury had hung on fair use, an entirely new jury had to be convened for yet another trial on fair use in 2016. The jury sided with Google.
But in 2018, the Federal Circuit - the same appeals court that in 2014 had sent the case back to the jury - ruled that the jury verdict had to be set aside in favor of Oracle, because the evidence presented at trial clearly indicated that no fair use determination could be reached, and therefore should not have gone to a jury in the first place.
Setting aside a jury verdict is Big Judge Energy in a way that is bound to be controversial to the Supreme Court, and it’s likely that Wednesday’s oral argument will feature a good deal of discussion about the role of judge versus jury in a copyright case. The question of who gets to decide fair use, and when, is something that can be extrapolated out to a lot of different legal cases (which SCOTUS loves) and also has nothing to do with math (which SCOTUS does not love).
Unfortunately the real heart of the case lies in the part with all the math and such. The Supreme Court’s decision in Google v. Oracle might have huge ramifications for the software industry, most importantly because the Supreme Court may be revisiting the copyrightability issue - the question of whether the declaring code and structure, sequence, and organization of the Java APIs are covered by copyright law at all - which hasn’t been in play since 2014.
This decade-long grudge match between Google and Oracle is not an entirely rational one. Google’s reimplementation of the Java APIs is part of a long tradition of iteration that was mostly taken for granted until now. Products like Oracle’s own MySQL were created as iterations of IBM’s SQL.
This is not to say that copy-pasting is the heart of Silicon Valley. But there is a point at which you want to encourage things to look the same, rather than to be different for the sake of difference. To put things roughly: coding is the process of speaking to the machine. But very few people who develop software in this day and age actually speak directly to the machine. Software exists in layers upon iterative layers, a game of whispers that eventually reaches the bare metal of the computer. New languages are derived from the old; new libraries are built on existing ones; dependencies are stacked on top of each other like a game of Jenga that is about to end at any moment. And Google v. Oracle is a case that is happening at one of the lowest levels of an ongoing game of Jenga.
We’re about to find out whether the Supreme Court knows it.
Yotta Infrastructure and Pi enter into Strategic Partnership
Yotta Infrastructure and Pi have entered into a strategic partnership to...
Samsung regains its number 1 position in the India Smartphone
According to a report by Counterpoint, Samsung has regained its number o...
Alibaba stock grows by 80%
According to the research data analyzed and published by StockApps.com, A...