U.S. Supreme Court Denies Google's Request to Appeal Oracle API Case
supremecourt.gov
supremecourt.gov
1. This is a denial of a petition for writ of certiorari, which is a fancy legal term for a request that the U.S. Supreme Court exercise its discretionary jurisdiction to consider the appeal. This means that the court can hear it or not, as it deems fit, and only if it sees some really pressing reason to do so.
2. The above standard is very tough to meet and only the rare case will do so.
3. Here, Google had prevailed on the copyright claims at the trial level because the trial judge, rather than applying precedents mechanically, had rather bravely attempted to synthesize a byzantine body of law through what I believe was a brilliant synthesis of copyright law as applied to software interfaces that allowed him to conclude that APIs were not copyrightable (see my earlier assessment here: https://news.ycombinator.com/item?id=4050490#up_4051761). On appeal to the Federal Circuit, however, the court rejected this attempted synthesis and applied conventional precedents to conclude that APIs were indeed subject to copyright protection. Even in doing so, the Federal Circuit did not grant judgment for Oracle but instead sent the case back to the trial court to determine if Google could prevail on its defense that its mirroring of the java APIs was a fair use of otherwise protectable code and therefore not infringing.
4. In exercising its discretion whether to hear an appeal of this type, the Supreme Court considers not only the importance of the issues raised by the appeal but further considers whether such issues are ripe for determination by the highest court of the land. What that means is that the court is not interested in addressing questions that may prove academic to the litigants in the case. It is interested only in resolving cases in which the issue it is being asked to resolve is critical to the outcome of the case. Here, that standard was not met. Why? Because the appeal is from a case that Google has not yet lost. Should Google have the case tried on remand, and prevail on its fair use argument such as to win definitively on the copyright issues, then there is no need for it to obtain a determination that APIs are not copyrightable at all. In such a case, that latter issue becomes moot. Thus, in denying Google's writ, the Supreme Court may well have concluded that it is simply premature to take up the API issues until all of them have been first finally decided by the lower courts.
5. The other major fact to note here is that a denial of this sort of writ by the Supreme Court has no legal significance in terms of ruling on the merits of the claims presented. The denial simply means that the court is not interested in taking up those issues at this time. It is entirely possible that the case could be tried in the lower court, that Google could lose on all copyright issues in that trial, that Google could appeal once again, that the Supreme Court would eventually grant a future writ to hear these very issues, and that the Supreme Court could rule in Google's favor that APIs are not copyrightable at all.
6. Having lost on the copyright issue before the Federal Circuit, Google has a pretty tough fight before it in this case. For the same reasons, though, that Judge Alsup had originally concluded that copyright law should not even protect APIs, it has a potentially compelling fair use argument to make and may therefore win on that issue. If it does not, it can once again appeal to the Supreme Court for redress. That would be a long shot, but it is possible.
7. The only thing certain about this case now is that a long, drawn out legal battle will follow before anything is definitely decided. The issues are important for our tech age and, in this case and otherwise in the federal courts, only time will tell whether Judge Alsup's original synthesis (or some variation) favoring freer interface use or the Federal Circuit's maximalist IP views will ultimately prevail.
E.g. POSIX C headers are protectable. But Lisp FFI declarations that compile down to the same ABI do not infringe because they targets the unprotectable method of operation, and do not copy the protectable textual description of those operations.
I think a lot of coders want the lower court to be right for pragmatic reasons. I totally appreciate those pragmatic arguments, but they're not based on having a better technical understanding of the issue.
Oracle was claiming rights to the "structure, sequence, and organization" of the APIs, not the text of their declarations. They were unmistakably going after something that was at least in some way more abstract and broad than the text of the declarations.
Doesn't this get into hair splitting? Somewhere in that Lisp code there's the symbolic name, as defined in the C code, for the function/entry point, and the C type-names for the parameters. Those are copyright protected. This is how I would expect Oracle to argue that changing language syntax does not excuse you from licensing their "copyright protected API."
This distinction does have a certain clarity to it, but isn't there a certain sense in which there's "only one way" to describe an API for a given language? "int foo(int a, int b)" is hard to write another way; perhaps I can rename the parameters.
(Your Lisp FFI example sidesteps this issue because API declarations in different languages will, of course, look different.)
In other words, I think there may be an "information content" argument. If the abstract operations are not copyrightable, and there is only one obvious way to write down the API's function prototypes in (e.g.) Java or C, does the source code really carry additional copyrightable value?
(I'm genuinely curious what case law now considers the line to be; this isn't a rhetorical question.)
(java.lang.Math is awfully similar to math.h; I actually wonder if, historically, there was copying.)
And without studying the case, just on the general principles of what copyright is supposed to do, applying it to APIs is at least a debatable point. And probably should be hashed out by the Congress and the Executive.
The only other thing were 7 test files that were not part of the implementation
But, in all seriousness, the 9 lines + 7 files are damning. It also shows that the engineers who implemented Google's project had been tainted by exposure to Java.
I think that's one of the key points. How can you claim a clean-room implementation, when there are (small) portions that have been directly copied? It weakens the case for the rest of the code.
Android's use of Java also ends in the toolchain. Android never used a Java(tm) runtime, nor Java bytecode in the runtime. by the time an app hits a device, it's in Dalvik bytecode and either interpreted/JIT-compiled by the Dalvik runtime or pre-compiled to the target system ISA for the ART runtime.
This whole thing is a travesty.
I don't understand what this is supposed to mean, and I don't see anyone else asking. So could you explain?
*Appeals courts in the United States do not rule on the facts of a particular case; they only decide if the lower courts properly applied the law. This doctrine is either by law or tradition, depending on the particular appeals court. When an appeals court overturns a legal decision made by a lower court, it typically remands the case back to the lower court to clarify any facts necessary to resolve the case.
The appeals court decision -- both the district court and the appeals court are federal courts.
> Appeals courts in the United States do not rule on the facts of a particular case
That's not always true; matters of fact can be appealed, and there are different standards of review on appeal for different kinds of fact question, however, appeals courts generally prefer not to reach fact questions, particularly if the appeal was over a question of law and not specifically on the fact question, and appeals courts generally do not answer questions -- particularly fact or mixed fact/law questions -- that have not been addressed by the court below, as is often the case where the appeals court reverses a finding of law of the lower court, which then makes relevant a fact question that the lower court did not answer because it would have been irrelevant under the lower court's view of the law.
No, it can't. Copyright violation requires an actual copy or derivative work, not independent works that have coincidental similarity.
> Sam Smith's "Stay with Me" is a good recent example.
Its an example of something where one party claimed copyright infringement, the other party claimed inadvertent similarity, and the facts were never resolved because the two parties reached an undisclosed settlement.
It is not an example of something both actually being copyright infringement while also actually being inadvertent similarity.
http://cases.justia.com/federal/appellate-courts/cafc/13-102...
The ruling found that APIs form a substantive body of work, similar to something like a play. However, if I took a play and used a computer to detect the sentence boundaries based on punctuation and randomly permuted the sentences, then wrote a book about what happened when I said random subsets of those sentences in random order to a set of undergrads, I'd be considered to be doing derivative work, even if I listed every sentence of the original work, as long as I substantially commented on each sentence in the context of my experiment.
In the context of APIs, isn't it possible to automate the performance of this experiment and writing of subsequent report?
They should have just paid the vig to Oracle and been done with it, instead they have a knock-down-drag-out and end up with a precedent that damages all software development everywhere. All involved are acting like a bunch of jerks.
Yes.
Alternatively, .NET is licensed under Google's preferred permissive license these days.
Neither of these will happen, however.
Is Google going to switch to another language for Android development? Apple has already showed it is possible.
And that's what's really terrible about this, because before you could provide a clean-room reverse-engineered implementation of something and that would be OK. If I'm understanding this decision correctly, you can't do that anymore; if this were the law 40 years ago then there would never have been an "IBM Compatible" and who knows what consumer computing would look like today.
How would that work with (e.g.) beta versions of something that was aiming for 100% compatibility, but had not achieved it yet? Are you prevented from releasing until you reach 100% compatibility?
Does this prevent MS-style "embrace, extend, extinguish?"
My understanding is that a subset and a superset would both be okay. I am more certain about subset than superset -- I am not sure that something like Microsoft's J++ would pass muster either. But a subset I think would still be permissible under fair use so long as the goal was to achieve compatibility.
Oracle's argument is that Dalvik is not the JVM, nor is it an attempt to be the JVM. It's a competitor to the JVM that uses parts of the Java API. I don't know if they're right, and I don't know that being right should mean that Google has to pay them money or what have you as a result. I do think that people are overstating the effect that a ruling that Google infringed on Oracle's copyrights would have.
They're claiming that any of the above would require an API license, and that a license (requiring GPL for the implementation) was granted only to the latter, so a subset would be unauthorized infringement.
Does Mono infringe on Microsoft's .NET API because it has always lagged behind the official .NET API, even though the goal of the project is to achieve compatibility?
Yes, the jury ruled that there was infringement
A jury verdict is not a court judgement. Because the district court ruled against copyrightability, it did not rule on infringement. When the court rules on infringement -- and the court is not necessarily constrained by the jury verdict on that point, and there will be further motions on it -- then someone will likely be upset and appeal that judgement to the Court of Appeals again. And whichever way that goes, there will no doubt be an appeal to the Supreme Court again.
And, after all that is done, then we'll have a final answer.
Alsup asked the jury to rule as if API's were copyrighteable so that ruling stands
Deleted comment
And, even if they lose on fair use, they can appeal the final ruling, including on the question here. There were arguments (including from the Solicitor General) that the Supreme Court should not take this case because the fair use question had not yet been addressed, so its perhaps premature to read into it whether the Supreme Court would take this question up, or how it would rule if it did, were the case otherwise finalized in the lower courts.
"U.S. Solicitor General Donald Verrilli responded with a brief that urged the court to sidestep the case, particularly because the fair-use issue hadn’t been resolved in the lower court. Mr. Verrilli also said one of Google’s main arguments against copyrights on the Java packages was without merit."
Times like this when I miss groklaw.
[1] http://www.wsj.com/articles/supreme-court-denies-google-appe...
But the issue here is actually re-implementing the API, not calling it. The court could rule that an API could be copyrighted (and therefore freely called, but not freely re-implemented). The result would be that an API becomes a one-way interface. You couldn't have multiple competing implementations, you could only have one. That's still a big change for the software landscape...
A lot of us here don't identify Java with Oracle, we just regard Oracle as "a great vampire squid wrapped around the face of Java ecosystem and the software industry, relentlessly jamming its blood funnel into anything that smells like money*
LOL
Fast growing OSS projects like KONG [1] for API management or Strongloop are a way to avoid to invest in technologies that are not fully open or usable under the right license.