Hacker News Reader

If the Federal Circuit decision stands, software might have finally encountered the lump it can't digest as it eats the world.

† In the United States.

The apparent legal position following this result seems crazy to me. Even in the world of intellectual property law, there has been some recognition that the interests of interoperability and ability to communicate may outweigh the benefits of monopoly protection as an incentive to create and share. The US, for example, takes this view in declining copyright protection on the design of typefaces (as distinct from font files that contain software describing those designs in one specific way). And in Europe, good luck getting a software patent that blocks anyone from using your file format or communications protocol.

Given that programming to an interface is essentially the way we enable interoperability between different software products, allowing the protection of such interfaces to stand seems absurdly counter-productive. This is particularly true if the protection holds retrospectively for APIs that were previously believed not to be protected in that way by those who chose to write code against them, which would presumably be the case here.

If the US allows this position to remain, it could cripple the US software development industry very quickly if the lawyers start throwing their weight around. In practice, as often happens under the US legal system, I expect it would be particularly damaging to the little guy, while the big players would all cross-license their respective portfolios somehow to make the issue go away.

> Microsoft's Project Islandwood re-implements iOS APIs. But Xamarin, Cordova and other projects all ingest APIs and reconfigure them to make them accessible on multiple platforms. Are they contaminated by copyright now?

Which is funny, because Microsoft played a big role in helping Oracle win this one:

http://arstechnica.com/tech-policy/2013/02/microsoft-foresee...

Additionally, there are the APIs that no one thought too much about the copyright of. Who owns the Javascript API, for example? The W3C, or the first browser vendor to implement each component on a component-by-component basis?

AOL, perhaps? They own whatever parts of Netscape haven't been sold or transferred, and since API copyright is an intellectual property that no one knew existed then the rights to the original JS API would fall to them.

It makes me wonder why moving away from Java is not an higher priority for the Android Team. According to the AOSP tracker, their current efforts at the language level seem to center on the integration of Java 8.

Sure, as far as languages go, I there are many tasks more beneficial to the platform than changing its language, but the legal issues they are encountering sound like another good motivation.

No way Google can move Android completely away from Java until long after the legal situation is resolved one way or another. There's just too much third-party code.

The AOSP tracker only discloses their public efforts. I wouldn't be surprised if Google has been working on a parallel Android project to replace their use of Java with another language - perhaps one that they developed. In fact, I believe it would be irresponsible of them not to have a Plan B in place should the situation become any more untenable.

Huh? They haven't even delivered Java 7 yet.

IIRC they have both java 6 7 & 8 configurations in the new jack & jill toolchain. I don't know if it necessarily means that the integrality of Java 7 & 8 features will be ported.

Android supports Java 7 since October 2013.

Really? The last time I checked invokedynamic, java.lang.invoke, java.nio.file.* and many more were still missing.

It supports java 7 syntax. Invoke dynamic you mentioned is a jvm feature, which dalvic isn't one. I think the lack of nio is an annoyance that can be fixed tho.

> It supports java 7 syntax. Invoke dynamic you mentioned is a jvm feature, which dalvic isn't one.

invokedynamic is a bytecode. Not supporting it means Dalvik / ART can't accept valid bytecode.

> I think the lack of nio is an annoyance that can be fixed tho.

Apparently not. A quick check also suggests that ClassLoader#registerAsParallelCapable is missing.

I'd be interested in hearing about the process of returning to the District Court (or really any previous court) to defend on a fair use argument. Was that case not closed? Was it left pending until the question of copyright itself was addressed by the appeals court?

Google's defense for the copyright phase was that the APIs couldn't be copyrighted and that even if we entertained the idea that they could be, Google's use would be fair use. The District Court, having agreed with Google on the copyrightability aspect, came to no conclusion on the fair use issue. (Fair use is an affirmative defense to copyright infringement, which means it acknowledges infringement but requires no penalty/reward.)

When the Federal Circuit court overturned District Court's decision on the copyrightability of SSO, they remanded the issue of fair use back to the lower courts. After all, both Google and Oracle's goal through all this is not an academic exercise in establishing the general boundaries of copyright; their question is, "Are we/they going to have to pay in this case?".

For libc at least, the API is actually an ISO standard. Same with the C++ standard library. Therefore, you should not expect issues like this.

Now, using a language which is owned by one company, Google's lawyers really dropped the ball in terms of risk.

Does the ISO standardization process include a copyright license or assignment? Copyright had pretty specific rules over who owns a work. Assigning your copyright to someone else requires certain explicit steps.

I've been trying to find the answer to this to no avail. I did find it interesting that the ISO does enforce copyright for their own works.

It looks like you have to buy a copy of the standard to get a license to use it. That's just from reading their website, but I too cannot find a definite answer.

Did they though? At the time wasn't Java supposed to be "open source"? By that logic many companies who used (and use) Java have made the same mistake.

I would say it's Google's executives and engineers who have dropped the ball if the moment Oracle won the case the last time, they didn't start planning and working on stripping Java out of Android. If they still have a "let's wait and see" attitude about it for another 2-3 years or how long these Court battles will take to settle, then THAT would be a major fail on their part. Because by then they would have to pay who knows how many billions of dollars and it would take yet a few more years (5+?) to do the whole transition.

The problem is precisely that Google didn't use Java under its free software license.

Sun did not allow anyone to use GPL Java (SE) on mobile devices ('field of use' restrictions). For that, you had to license J2ME from Sun under different conditions. If you ever had the misfortune of targeting J2ME, you'd know why it was a no-brainer for Google. I shudder to imagine writing Android apps using J2ME.

It is prudent to note that Google didn't write its own implementation from scratch: they took advantage of Apache Harmony (by erstwhile Sun frenemy: IBM). This is the same Apache Harmony that Sun repeatedly refused to provide the TCK for

No, because glibc is LGPL.

Can't GPL 3.1 or w/e waive this, and it remains a non-issue?

Why would the FSF modify the GPL to allow things that would otherwise be GPL'd to escape?

For the same reason it supports choosing permissive licenses like BSD in some instances. I.e., it advances the ideals of free software better than if you were to take the opposite stance.