Specifically the district court. The case made it to a federal appeals court, which ruled that APIs are copyrightable (the district court had ruled they were not), and then remanded* the case back to the district court to decide if Google's fair use defense was valid. Google appealed the federal court decision to the Supreme Court, which decided to not hear the case.
*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.
> Google appealed the federal court decision to the Supreme Court
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.
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?
fwiw to @justonepost's point the wsj pointed out [1]:
"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."
It would kind of defeat the point of publishing an API, wouldn't it? "Here's my API, but you can't use it without violating my copyright." Well, then, you might as well not have published it.
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...
You could have multiple competing implementations, they would for example either have to use the same header files provided by the copyright holder, implement a set of interfaces packaged in JAR file provided by the copyright holder (see JDBC as an example), or generate stubs from an IDL file provided by the copyright holder.
How would APIs involving callbacks work? Would they need special license acrobatics to authorize you to implement a callback of the necessary form as specified by the copyrighted API?
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.
Unfortunately this was a terrible case to have been the first of its kind (in the US). There was much more at play here than API copyright. Google didn't just copy the Java APIs, but it took the syntax as well. Oracle also presented evidence that Google had directly copied implementation of a few API functions, which Google actually admitted was true, but claimed it to be negligible. While all of these claims were examined separately, all of them combined made it much harder for any individual victory.
Yes, it was copied by the original author that wrote it back when he was employed at Sun. Additionally, those 9 insignificant lines were irrelevant to the case. The fact that it was even presented showed how desperate Oracle was.
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.
> 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 uses code from Apache Harmony for many basic Java classes. If any code was copied from Java 6, it would have happened in the Harmony project.
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.
It's more interesting than that. The engineer who wrote those 9 lines was employed by Sun working on Java APIs before working for Google. According to his testimony it was a "fix later" copy/paste mistake he made when improving Sun's OpenJDK code while working for Google.
9 lines copied by the guy who wrote the original implementation, let's not forget. This was literally a case of him saying "oh, I've done this trivial thing before, I'll just grab what I did then".
this is true, but will always be true for every court case. by definition, cases that reach the Supreme Court are those that are the most difficult to decide; if one side would/should clearly win, then the parties would virtually always settle much earlier or even avoid court in the first place.
Agreed, I'm saying that if this was a case purely around API copyright-ability and not all the other hairy bits around it, it would have made for a nicer case to set precedence.
Google didn't want to pay licensing fees to Oracle so they wrote their own implementation of the entire Java language. Not only did they write their own implementation of the standard library, they wrote their own compiler and virtual machine. Does that make sense? I can see how my original statement was unclear.
I'm familiar with the background of the case, I just don't understand what you mean by, "took the syntax as well". Android programs are written in Java-the-language. That fact neither enlarges nor diminishes the severity of Google's actions here.
As a result, I've decided to write a perl script that generates random APIs in some API-space, compress the new API and then store it all as blobs to disk while simultaneously filing for a copyright on all of these APIs.
> Inadvertent similarity can still be copyright infringement.
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.
Wasn't copyright protection only applicable to creative expressions of a human? Computer generated expressions are not protected by it, if I understand it correctly.
Would this be enough though? As I understand it the issue is that Dalvik implements large portions of the Java API so that developers can write Java and run on Android without Android actually providing a Java VM. So introducing a new language to run on the same VM doesn't work. If anything it reinforces how similar Dalvik is to the JVM.
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.
The ruling says that APIs are copyrightable. It does not say that Google is infringing, yet -- the court has yet to rule on whether or not Google's use of the Java APIs falls under a fair use exception. The argument being advanced, as I understand it, is that Google's use of the APIs does not qualify for fair use because it was not being used to create an implementation of the JVM, but because it was being used to create a different runtime (Dalvik) which uses some of the Java APIs but is NOT an attempt to be compatible with the JVM. So it is possible to rule that Google infringed upon Oracle's copyrights without ruling that something like the IBM-compatible PC infringing.
So are they claiming that it infringes copyright if your implementation is a superset or a subset of the original implementation, but if it is an exact implementation, then it's not copyright infringement?
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?"
I am not a lawyer, so take what I'm saying here with several large grains of salt.
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.
> So are they claiming that it infringes copyright if your implementation is a superset or a subset of the original implementation, but if it is an exact implementation, then it's not copyright infringement?
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.
But when you start creating an implementation, it ends up being a subset while it is a work in progress. Are you stating that works in progress are infringing, until they become "magically" not infringing at the point where they reach parity?
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?
.NET isn't relevant because Microsoft isn't trying to control it with the same kind of licensing terms that Oracle's using to try to ensure that anybody else's Java implementation adheres to their standards.
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.
The ART VM is language agnostic. As long as the language compiles to bytecode the ART AOT compiler will compile it to the native code of the CPU. The Java API's have more to do with source code interoperability with existing Java libraries.
I hope and feel like they'll back kotlin when it hits 1.0 regardless of what happens here. We can't be stuck with a half assed java 7 on Android forever.
The original judge in lower court actually taught himself coding to understand the case and came to the conclusion that APIs were not subject to copyrights (ie. he understood the issue). How the appellate court could come to a different conclusion is utterly beyond me.
I don't think those who "understand the issue" must necessarily agree with the lower court. I've been coding since I was 13 and I agree with the Fed. Cir. here. The concrete Java declarations that make up an API are a protectable work of authorship. The abstract operations they describe are not.
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.
> E.g. POSIX C headers are protectable. But Lisp FFI declarations that compile down to the same ABI do not infringe
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 wonder whether, for example, Java's "double sinh(double x)" from java.lang.Math could be found to be infringing on the pre-existing "double sinh(double x)" from math.h. The API is literally textually equivalent, right down to the variable names, despite the language being different.
(I'm genuinely curious what case law now considers the line to be; this isn't a rhetorical question.)
Infringement requires copying, not just text equivalence. If the C programmer was "writing C" and the Java programmer was "writing Java" there is probably no infringement because there is no copying.
Historically, almost everything in computing is a copy of a copy of a copy, usually ultimately leading to some pseudocode in an academic journal somewhere. If everyone along the line asserted their copyright, the whole field would collapse.
Go screw dude. That'd be like saying my copyright is being infringed by all "Lobster Thermadore" recipes or any dictionaries that contain the word "maximum".
Well, recipes are specifically exempt from copyright, but the text of them is not. If you had a recipe for "Lobster Thermadore" that was a close copy of another published version, that would be infringement.
The basics of a recipe are hard not to duplicate, but if you start writing a lengthy description of how to do it, that enters a different territory. That seems like a decent analogy for this case.
It is probably a good idea to be at least slightly rude when responding to rayiner's posts. He is HN's most prolific concern troll and he consistently drags down discussion with endless irrelevant bullshit every time he posts. On the other hand, he does provide a useful function in that you can consistently arrive at a more-or-less correct opinion by first understanding his post, and then taking the opposite opinion. Interestingly, this means there is a part of rayiner's brain that is uncannily skilled at rooting out the truth - it's just a shame that the more executive portions of his brain are wired to consistently think the exact opposite position of whatever the actual clever bit comes up with :-)
> But Lisp FFI declarations that compile down to the same ABI do not infringe...
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."
Do you think it will be OK given this law to automatically generate FFI bindings by parsing protectable POSIX C headers? In this instance a human will have invoked a program that literally copied the source in to ram, bit by bit, and then copied certain bits of it (eg symbol names). Is that materially different to invoking 'cp' (a traditional copy command)?
> "The concrete Java declarations that make up an API are a protectable work of authorship. The abstract operations they describe are not."
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.
Fair enough. But do you stand by your assertion that something more abstract than literal header file text can be deserving of copyright but ABIs shouldn't? I'd like to know how near or far your line is from Oracle's, if only to have an example of where else the line could be drawn.
Yes, but that's the usual copyright rule isn't it? You can't get around copyright by search and replacing "Harry Potter" with "Barry Potter." And it's well understood that the less creative the expression, the less has to be different for a work not to infringe. I'd say changing a couple of parameter names wouldn't do it, but changing the syntax of the declarations surely would.
Learn about the origin and general practices of the U.S. Court of Appeals for the Federal Circuit and you should get at least a little bit of enlightenment.
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.
Which people? LLVM assembly declarations are much more lower level and less accessible to developers than source code APIs. While there is a relationship between the two it's apples and oranges.
Out of curiosity (and as an exercise), what if Google decided to convert all the Java code and APIs to Scala (assuming they had permission from Typesafe)? Would that still be infringement considering they are using the JVM (Dalvik or ART) but not actual Java code? Doesn't even Scala use (or transcompile to) Java code which could be infringement?
I think Oracle has a "thin" copyright here--the literal Java declarations. Expressing the APIs in Scala (or Clojure) and compiling down to whatever they compile down to these days shouldn't infringe.
Why do you guys talk about Oracle as though Oracle created Java? Sun created Java. worked to gain greater control over it and was bought out by Oracle.
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*
Well, Sun does matter a bit when it comes to questions of what license terms were or were not offered and with what motivations. If there's any doubt about what Sun actually did back when they were independent, then Oracle is somewhat constrained by what Sun was trying to do (Open source Java), not what Oracle is trying to do (close Java while leaving only a GPL implementation open-source).
That's why we need more open source under MIT license in the API space.
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.
Couldn't Google just comply with the license and re-release their code under GPL with linking exception like the original standard library? Maybe pay a fine but at least Android survives.
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.
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 wil...
87 comments
[ 5.3 ms ] story [ 161 ms ] thread*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.
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?
"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...
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.
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?
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...
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
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.
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.)
The basics of a recipe are hard not to duplicate, but if you start writing a lengthy description of how to do it, that enters a different territory. That seems like a decent analogy for this case.
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."
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.
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.
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.
[1] https://github.com/mashape/kong
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.
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 wil...