Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The lawsuit has (mostly) nothing to do with the license the implementation is under.

Oracle's argument is that an API is copyrightable, and cloning an API is illegal.

The only known way to obtain a license to use those APIs is to use the GPLed Java implementation of those APIs.



>use the GPLed Java implementation of those APIs

Google did a clean-room implementation. But what about derivatives? Obviously you have to redistribute your source. Does using your patched version magically become legal iff your changes are merged into the upstream? This seems to defeat the GPL entirely, since it doesn't matter that you have a license to modify the source code if doing so means you are violating copyright on the APIs.


OpenJDK being licensed under the GPL means that the APIs are under the GPL as well. You can legally create your own implementation of the APIs, as long as you don't violate the GPL. Your project would be considered a "derived work" of the APIs, meaning you need to keep the same GPL license.


So why didn't Google do that? Is their Java implementation closed-source?


Apache Harmony is Apache Licensed, and that license is only comaptible with GPL3+. OpenJDK is GPL2 + classpath exception, so no, Harmony is not a valid derivative work of OpenJDK.

Since the only free software Oracle still maintains is the stuff they couldn't relicense from Sun, and the acquisition was before the GPL3 was finalized and even then Sun would not have been able to relicense all their stuff before being bought out, there is no chance of any Oracle products being Apache compatible in the future.


OpenJDk's initial release was May 8th, 2007. Android was already far along in development by that point.


> since it doesn't matter that you have a license to modify the source code if doing so means you are violating copyright on the APIs

I don't understand your argument, wouldn't using the license (GPL) imply a license to use and modify the API's? And that would mean you can create your own modified API, provided it is also under GPL.

This doesn't apply to Google's clean-room implementation since that wasn't using the GPL license.


So, can they take OpenJDK, through a series of commits revert it back to what they have now, release that under the GPL, and be legally in the clear, as long as they don't call it OpenJDK or something that might be confused with it (the license for the name is stricter)?


They don't even have to go through those motions, they could just release what they have under the same license as OpenJDK and grab some of the interface definitions they need from OpenJDK

And they wouldn't necessarily be "legally in the clear"... when this is all said and done they may be found to have infringed copyright illegally and will have to pay a price for breaking the law. Complying with the OpenJDK license would only protect them going forward, not for past transgressions.

Interesting move on Oracle's part would be to try to prove that Google infringed on OpenJDK's copyright (i.e., violated the GPL)... then under GPLv2 Google could lose their rights to redistribute OpenJDK

https://www.softwarefreedom.org/resources/2008/compliance-gu...


I don't see why not; as long as it's derived from GPL licensed code, and they respect the license, they have the right to change it to whatever they want.


This seems to defeat the GPL entirely, since it doesn't matter that you have a license to modify the source code if doing so means you are violating copyright on the APIs.

Indeed.

IANAL, but that is one (of many) problems with this legal outcome.

Although it's possible that the explicit permission to change the code in the GPL would be interpreted as a license the the API as well.


Although it's possible that the explicit permission to change the code in the GPL would be interpreted as a license the the API as well.

I don't see how it can be any other way; since the infringement was based on the copyright of the API, by having a legal license to the copyright of the code that implements the API, I don't see how can one lack a license to the API. It'd be different if the API was somehow patented, but copyright explicitly covers the actual implementation.


Google did a clean-room implementation of copied APIs. Those APIs are licensed under two licenses, and Google chose neither. All you need to do is choose one and comply with it.

All the ruling means is that if you copy an API you should either comply with the license (Google didn't comply with either possible licenses) or don't, but have a good fair-use defense, such as non-profit use and/or interoperability (neither applies to Android, but that hasn't been ruled yet).

Now let me say this again: It has been in Google's best interest to keep people's confused about the ramifications of this court case, because Oracle's legal's department is fierce, and if you believe that they might come after you, too, you'll support Google's position. The reality is that whichever side you're on and regardless of the outcome, the ruling in this court case will not apply to the rest of the industry (because Google's use of Java's API was very unusual).


Google's use of Java's API was very unusual

How is it different from any other reimplementation of an existing API?


Because usually reimplementations are done in a way that would allow programs/libraries written for the original platform run on your platform, i.e. reimplementations are usually done in a way that makes them drop-in replacements to the original as much as possible. That is not the case with Android. Running existing Java programs is a non-goal, and reusing libraries is only a goal as long as it helps Android's separate ecosystem (Java libraries -- for any Java standard -- work on Android only if they happen to use the subset of APIs implemented by Android; this is not due to any real limitations or lack of developer resources, but simply because being a drop-in or near-drop-in replacement for Java is not a goal for Android).

I will note again that Google is free to use OpenJDK however they like -- they don't need to be compatible or anything -- as long as they comply with the GPL license.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: