[thesausageking]

Google's argument is that it falls under fair use to do a clean room implementation of the APIs. District Judge Alsup agreed with this legal idea:

"So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical."

[tenebrisalietum]

The whole PC industry was deeply affected, in a positive manner for consumers, in a negative manner for IBM, by Compaq's reverse engineering of IBM's BIOS ROM API. Imagine if users of BIOS/UEFI API had to pay royalties to IBM (which derived it from CP/M).

[hollerith]

>Imagine if users of BIOS/UEFI API had to pay royalties

I always thought that every PC maker did have to pay royalties to Phoenix or one of the other BIOS vendors.

I know that open-source BIOSes, e.g., coreboot (formerly known as LinuxBIOS), exist, but I got the impression that even at this late stage in the BIOS game, only a minority of machines ship with them.

I always thought that Compaq created its clean-room implementation because IBM outright refused to license their BIOS (to Compaq or anyone else).

[pgeorgi]

> I know that open-source BIOSes, e.g., coreboot (formerly known as LinuxBIOS), exist, but I got the impression that even at this late stage in the BIOS game, only a minority of machines ship with them.

coreboot is not an open source BIOS, it's open source firmware. It can be combined with SeaBIOS, which is an actual PCBIOS implementation (that may or may not be in violation of IBM's APIs given this case) to provide a PCBIOS-alike boot environment.

It can also be combined with Tianocore, Intel's open sourced implementation of the high level APIs of UEFI, so that this approach would be less affected by the court case (since that's using code verbatim that was specifically published for that purpose). But who knows if the Oracle case wouldn't affect this approach as well?

coreboot can also be combined with other code for customized boot concepts, like on Chromebooks, which are probably the largest consumer deployment of coreboot, at ~6% of laptops and desktop in the US, apparently (The numbers on https://en.wikipedia.org/wiki/Usage_share_of_operating_syste... vary wildly depending on the detail each is covering)

> I always thought that Compaq created its clean-room implementation because IBM outright refused to license their BIOS (to Compaq or anyone else).

Apparently Google (or Android before they were bought? not sure) also tried to license Java for Android and that fell through. They didn't clean-room because there was the Harmony stuff to work from that nobody seemed to have a problem with. These days Android's Java is based on OpenJDK which gives it a whole new twist (it being licensed by Oracle under GPL terms).

[jpollock]

Let's rephrase...

Imagine a world where Compaq was unable to create a cleanroom implementation of IBM's BIOS because that involved re-implementing the copyrighted APIs.

[all2]

Where I work we have a line item for every computer we make for a BIOS royalty. So this happens at least sometimes.

[monocasa]

On the copyright of the actual software by Phoenix or Award or whoever, not an API licensing fee.

[simcop2387]

that's the difference though, theyrr free to make one or use any of the existing ones with the conditions of the authors. they're not forbidden to make their own or use a competitor's like the oracle ruling could otherwise mean.

[kiba]

I am told that this is a deliberate choice by IBM.

[flomo]

Antitrust decree. IBM also did come back and collect royalties from the PC industry.

[gpm]

Google has several arguments, I find most of them persuasive. The fair use one is sort of a fallback.

The more immediate argument is that APIs aren't copyrightable material, since there isn't more than one way to write them. You can't write the API differently and still let existing java programs run with your standard library.

[glofish]

They could design their own API and provide an "invisible shim" that transforms the calls to the original API into theirs.

[gpm]

To implement such an "invisible shim" you would still need to write the exact same API that oracle is claiming is copyrighted to let other programs build against it.

It's not the internals of the functions that this case is about, it's literally about "class ArrayList { void clear() { [this part excluded from case] } ... }"

[glofish]

not exactly.

there is a big difference between an API exposed to all other programmers in the world - versus one that is there for say compatibility.

Their entire API works the same way as Java system and you program it as Java - it would be very different if say Android was programmed in Go and they had a way to translate Java programs into Go.

[gpm]

I assume your first post was in response to my "you can't write the API differently" paragraph. If not we are talking past eachother, sorry. If so, your followup is that focusing on Google's actions is missing the point. If there is only one (or a small number) of ways to write it then it isn't copyrighted, so Google can do literally whatever it wants. If there are many ways to write it, the argument fails, and Google taking a more minimal approach to copying it wouldn't change that (it might change the fair use analysis, but that's a separate discussion).

It's more of a nitpick, but your reply also exaggerates the scope of the case. No one is arguing in this case that Google was not free to implement Android or an API in Java, they are arguing about re-implementing Java's standard library APIs. As far as this case goes I don't think there is any salient distinction between implementing android in Go, and implementing android in Java with a different standard library api.

[saghm]

That was only after the appeals court stuck down Alsup's previous ruling that APIs couldn't be copyrighted and sent the issue back down to him to determine whether it was fair use.