...I don't really see what the difference is. In both cases Google would end up with exactly the same API specification. There's no room for them to come up with an "original" API, because if the API they end up with is not an _exact copy_ of Oracle's, then software written for Oracle's Java implementation would not be compatible with Google's Java implementation (and vice-versa).

So? The proper response would have been for Google to either pay the license or develop their own write once use anywhere software. Instead, the took the shortcut of copying someone's hard work.

By that logic WINE shouldn't be allowed to exist either, since it copies Windows' API.

Copying APIs is strictly necessary for interoperability. Allowing APIs to be copyrightable encourages monopolies by legally prohibiting newcomers' software from being compatible with their competition.

It'd be like if Microsoft were allowed to sue Google Docs and Libreoffice for making their software able to open Word documents. (Except in this case the "documents" are source code.)

I'm not sure how WINE works. But I just don't see that being the case. All WINE has to do is capture the API calls and transform them into a different WINE API call that ends up performing the same function and then proceed with zero copyright issues.

> All WINE has to do is capture the API calls and transform them into a different WINE API call that ends up performing the same function

How can it "capture" the calls without knowing what it's capturing? It has to know that there's a windows API function called "CreateWindowEx" that takes particular parameters, otherwise how could it possibly "translate" it? And the fact that CreateWindowEx takes particular parameters is precisely the API.

Of course the implementation of that API will be different in WINE, just as Google's implementations of the Java API are different from Sun's (aside from the 9-line rangeCheck which is a separate issue). In fact it would be fair to describe what Android does as "capture the API calls and transform them into a different Dalvik API call that ends up performing the same function".

> All WINE has to do is capture the [Windows] API calls

So... you're saying it needs to implement the Windows API? If APIs are copyrightable, then that's a violation of Microsoft's copyright. You've included a copy of Windows' API in WINE.

Interoperability trumps copyright IMHO.

Unfortunately courts don't pay attention to your opinion. They only pay attention to grumpy old codgers who don't really understand technology or innovation. They only understand precendents or long ago useless decisions of previous courts and the pragmatism of someone raised on thoughts on computers and ideas of fairness from the 1950s.

It is effectively impossible to take something as complex as the Java API, do black box testing, and come up with an exact copy. Google's API being slightly different is ultimately the point. The process yields a new original work even if it ends up being 99% the same as Oracle's API.

The 1% that's different being... what? Bugs? Like I said, any differences in Google's version of the API would, by definition, be interoperability problems that need to be corrected.

To make that more concrete: if Oracle's string concatenation function is called `String.concat` and Google's is called `String.append`, then code which calls `String.concat` isn't going to work with Google's implementation, and code which calls `String.append` isn't going to work with Oracle's implementation. It doesn't matter if the APIs are "similar" or not, they have to be _identical_ in order for code written for one system to be interoperable with the other.

The 1% will be things like String.methodNoOneUses or ObscureClass. Even if they aren't identical they will be close enough for 99.999% of the programs people write.

So bugs nobody files then? Why do you think this is a useful distinction. Either APIs aren't copyrightable or we should pass a law that says they aren't immediately.

APIs are copyrightable under a CAFC decision notionally applying 9th Circuit law in this case which the Supreme Court declined to review because, pending the resolution of other issues, they viewed it as not ripe for review. Since this is not within the CAFCs special subject-matter domain (patents or any of the other areas which bring a case within it's jurisdiction; this case is at CAFC because to once had patent claims even though they are no longer live), this ruling doesn't seem to be binding precedent on any lower court. So, it's “law” in only a very weak and tenuous sense.

Well, I would love to hear about a circuit court case that says otherwise. Seriously, I have no idea, but I do not believe such exists.

Basically it's not the law yet and may never be the law.

Uhh. No. At least under any interpretation I know about what the law "is."

It's neither express in the statute nor is it in case law binding on any court, because while CAFC decisions are nationally binding, that is only on the subject matter uniquely assigned to the CAFC, but that doesn't include copyright. Those are claims the CAFC decided under 9th Circuit case law in a case that is in its jurisdiction because it once had patent claims, even though those claims aren't active. Had the actual 9th Circuit ruled this way, it would be 9th Circuit case law, but the CAFC applying (notionally) 9th Circuit case law doesn't create new 9th Circuit case law. It doesn't even create precedent binding on future CAFC panels, even if those panels are themselves applying 9th Circuit case law. It is at most persuasive authority, rather than binding authority, in any future case, so it is only “law” in the sense that, e.g., scholarly treatises on the law are “law”.

So, barring this case being both heard and affirmed by the Supreme Court, this interpretation of copyright law, while potentially decisive in the outcome of the present case, isn't, substantially, law, so much as an idea of what the law might be.

Bugs are a red-herring to the discussion. Bugs doesn't get you out of copying. The question is: did you copy or not? Google argued "we certainly did copy but APIs can't be copyrighted." Which was not the law at the time they did the copying and is not the law now .

Except it is the law now and then that APIs aren't copyrightable according to the court that's generally supposed to handle such things, in this instance The US Court of Appeals for the Ninth Circuit. They've ruled plenty of times on the matter, and have developed decades of case law stating that implementing APIs is totally kosher. Sony v. Bleem is great example. There the appeals court ruled that not only could Bleem ship a PS1 emulator with reverse engineered APIs of the kernel (explicitly as a commercial venture even!), but they could port it to a competitor's game console (the Dreamcast), and use Sony's IP in screenshots.

But, because Oracle v. Google case had an ancillary patent question in an earlier appeal, the appeals are instead going to the Court of Appeals for the Federal Circuit. This court is really only supposed to answer patent questions. The CAFC can't set precedent in these matters, and overwhelmingly defers to the district courts' precedent. Bot for some reason they have chose to ignore all of that this time and make their own, fresh (and super weak) precedent that only applies to copyright cases with patent questions.

I bet if one looks hard enough he would find links between these judges and moneyed interests tracing back to Oracle.

Eh, I wouldn't go that far. CAFC judges just tend to be appointed (at least a little) for how much of a hard on they have intellectual property rights in general. The whole circuit was setup pretty much only to do patent appeals for the most part. The judges probably just think of themselves as 'principled'. And they are technically allowed to do this, despite it being kind of a dick move.

>APIs aren't copyrightable according to the court that's generally supposed to handle such things, in this instance The US Court of Appeals for the Ninth Circuit

That is just not true. According to the well-pleaded complaint rule, the Federal Circuit had jurisdiction.

> According to the well-pleaded complaint rule, the Federal Circuit had jurisdiction.

The Federal Circuit has the right to hear and decide this particular case, but they do not have the right to establish binding precedent on lower courts or other appeals courts in matters of copyright law. This has been explained to you repeatedly.

>not only could Bleem ship a PS1 emulator with reverse engineered APIs of the kernel

Not all types of reverse engineering is considered copying. See IBM PC BIOS cases.

There weren't "IBM PC cases". All of that work was based on Apple v. Franklin, a 9th circuit case that held that APIs aren't protected by copyright.

How do you propose they do this black box testing?

Write code, run it through the compiler and create specifications based on what you observe.

And once again, you'd end up in exactly this legal situation since the names are visible via reflection, but somehow aren't functional as viewed by the court.

That's one of the most important issues with this ruling; it effectively bans even black box reimplementations.

It is not copyrights problem that obeying the law might be difficult.

People who reversed engineered the IBM BIOS had the API specification -- actually they had the entire source code. They didn't just fire random interrupts at the BIOS and see what it did. But what they did do was take that specification and describe it the detail necessary for completely fresh implementation.

Not true at all. It was a clean-room reverse engineering job. Yes, they could have looked at the API, but they did not. More specifically, they erected an information wall between those who had the API specification and those who did not, and used the results from those who did not.

One team looked at the API and source code and everything and used that to develop the specification for the "clean" team to implement. That's the point. Collectively they didn't start with nothing.