| |||||||||||||
Free platformFree platformPosted Aug 17, 2010 16:34 UTC (Tue) by gmaxwell (subscriber, #30048)Parent article: A very grumpy editor's thoughts on Oracle I'm left wondering what our editor here would consider to be the criteria for freeness in a platform. For Java we have a complete implementation available from the original author under GPL(v2) in addition to multiple independent free software implementations with various levels of completeness. Even according to the FSF "the Java language as such is no longer a trap", so I think we can forgive people for not being paranoid enough if it turns out that Java was still a trap. And I don't mean this as merely a rhetorical barb at the author there are a number of platforms such as .NET/Mono which arguably have fewer assurances than Java and many others like Erlang which simply began life under a proprietary banner. I would have considered "reference implementation from the original author under the GPL" to be a gold standard. If that is inadequate what should we be demanding? Is GO a safe toolchain since it's more or less controlled by a single company? What about Javascript( Oracle)/ECMAScript? ECMA-262 itself makes _no_ mention of patents and, as far as I can tell, ECMA as a whole has no requirement that patented techniques submitted be available royalty free. So what should we have asked for and what should we be asking for? How do we convince the rest of the world that these things are important?
(Log in to post comments)
Free platform Posted Aug 17, 2010 16:51 UTC (Tue) by fandingo (subscriber, #67019) [Link]
The standard implementation of Java is free, and there's nothing that Oracle can do about that. The code is GPLv2, and there is a separate patent grant that grants impunity to users as long as they stick to the standard. Google made their own version of Java, and hence is not immune to patent suits.
Java is not a "trap" because of the GPLv2 and explicit patent grants for standard Java.
I forget where I was reading it (maybe here), but an author made a great point: Oracles open source projects are perfectly fine to use. There is nothing they can do because of the OS licenses and patent grants. However, developing for Oracle projects (or forking them for your own one) gives no such protection.
Free platform Posted Aug 17, 2010 18:13 UTC (Tue) by Aliasundercover (subscriber, #69009) [Link]
If you must adhere exactly to their standard, can not extend, modify or make a subset, then isn't much of the freedom in free software lost? Forks may often be a bad thing but if you can't fork it isn't really free.
I may be mistaken as this topic is so confusing but I am under the impression Sun's patent promise applies only to the exact unmodified feature set of a Java frozen in time.
Free platform Posted Aug 18, 2010 1:28 UTC (Wed) by coriordan (guest, #7544) [Link]
Forking won't destroy the patent protection. (I disagree with the last sentence of fandingo's comment.)
If Oracle publishes software under the GPL (v2 or v3), the recipients receive patent protection sufficient to allow the things described in the four freedoms, which includes forking.
So Google could have used OpenJDK as a starting point for Dalvik, and they wouldn't be having this patent problem. AFAICT.
Free platform Posted Aug 18, 2010 2:35 UTC (Wed) by foom (subscriber, #14868) [Link]
I don't understand where people are getting this "Releasing software under the GPLv2 gives an implicit patent grant, therefore it's safe to base software on OpenJDK" idea from. It can't be the GPLv2 license agreement itself, since Oracle (as author and copyright owner) isn't bound by that...
Free platform Posted Aug 18, 2010 6:10 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
> since Oracle (as author and copyright owner) isn't bound by that...
The GPLv2 does bound Oracle. Namely, it can not rescind the permissions it gave to others as part of a software license. This is basic legal theory, you can not tell others you can do foo, if bar then change your mind once others have expended resources reaching bar (at least, not in a legal document). Otherwise, no license would be worth the words used in it.
The only thing Oracle can do is define new conditions for new software releases, or relax conditions on old software releases. They are not allowed to add restrictions on old software releases people already licensed under specific terms (and the GPL is worded in such a way the license can be transmitted from user to user and from version to derivatives).
Oracle *is* bound by the GPL Posted Aug 18, 2010 23:55 UTC (Wed) by coriordan (guest, #7544) [Link]
I don't know the legal answer to that, but let's assume you're right and Oracle doesn't need to comply with the GPL in order to distribute. That would mean they can give you a copy of the OpenJDK source code without giving you a copy of the GPL. However, that's not what they did. What they did is, they distributed OpenJDK *with* a legal document saying.
They gave people a copy of the OpenJDK source code with a legal document which has a load of paragraphs that start with "You may...".
If you're right, then you've only proved that they didn't have to give you that legal document. That doesn't change the fact that they *did* give you that legal document, and so, Oracle is bound by that legal document.
Yes/no?
field of use restrictions Posted Aug 18, 2010 21:17 UTC (Wed) by SilverWave (guest, #55000) [Link]
I would be interested in your opinion on this comment by jilocasin:
"It's Oracle upset that Google has routed around their lucrative Java Mobile licensing by out developing them. If you were unaware, Sun's official Java test suite comes with field of use restrictions that keep it limited to the desktop space. If you certified your open source Java JVM to comply, you can't use it on servers or mobile devices (or anything else for that matter like TV set top boxes). For anything else you have to pay Oracle a license fee. It's these field of use restrictions (among other reasons) that has kept the Harmony project from certifying their project as "Official Java"."
OpenTCK Posted Aug 18, 2010 22:00 UTC (Wed) by mjw (subscriber, #16740) [Link]
Although the TCK is proprietary and you only get access to it under NDA, it doesn't come with such restrictions. See e.g the OpenJDK JCK http://openjdk.java.net/legal/openjdk-tck-license.pdf
Note that Google actually has access to this: http://openjdk.java.net/groups/conformance/JckAccess/jck-...
That said, it is still a big problem if you care about freedom, java and the JCK and it is a long and somewhat sad story: http://gnu.wildebeest.org/blog/mjw/2007/04/21/openjck/
Google created their own VM (Dalvik) they don't use the JVM! Posted Aug 17, 2010 18:23 UTC (Tue) by SilverWave (guest, #55000) [Link]
Classpath Exception not included in the mobile edition Posted Aug 17, 2010 18:13 UTC (Tue) by SilverWave (guest, #55000) [Link]
See Update 4 here:
http://www.groklaw.net/article.php?story=20100813112425821
"Update 4: A reader comment should be noted:
You seem to be missing the point of why Google didn't just use the GPL'd JavaME. Sun deliberately removed the Classpath exception on JavaME specifically because they saw that most of their licensing opportunities were on mobile platforms. This meant that any *application* developers targeting a GPL'd JavaME platform would be forced to GPL their applications. Not surprisingly Google saw this would be undesirable when trying to attract developers to the platform."
This is interesting:
http://sites.google.com/site/io/dalvik-vm-internals
Good Overview here:
Classpath Exception not included in the mobile edition Posted Aug 17, 2010 20:04 UTC (Tue) by nim-nim (subscriber, #34454) [Link]
Except that Dalvik is not JavaME. If it's close to something, that's JavaSE. Even Oracle wrote it before buying SUN
http://www.oracle.com/technetwork/database/berkeleydb/bdb...
(This, BTW, is one reason Android has rolled over JavaME phones: SUN let the JavaME cash cow rot at Java 1.3 level, while phone hardware improved, making the improvements of later Java versions interesting for mobile, and digging the competitive advantage trench Google would use later)
The *only* reason Android used Harmony as a base for Dalvik is the fundamental distrust of the Android team for anything GPL-ish. Remember that the core Android team came from Danger, which was quite happy to let itself acquire by Microsoft.
The fact that Android runs a Linux kernel despite this deep GPL distrust is quite a testament for the technical quality of the modern Linux kernel. Android certainly didn't swallow this GPL code pile with pleasure.
Classpath Exception not included in the mobile edition Posted Aug 18, 2010 8:07 UTC (Wed) by dgm (subscriber, #49227) [Link]
I had the idea that the main reason behind chosing Harmony was that Google wanted to allow propietary development on Android, and that was not possible using OpenJDK class library, as it is GPL's (not LGPL'd).
Also, a pair of notes: Isn't JavaME in version 6, just like JavaSE?
Classpath Exception not included in the mobile edition Posted Aug 18, 2010 10:46 UTC (Wed) by paulj (subscriber, #341) [Link] That's not true, OpenJDK is under a GPLv2 + "ClassPath Exception" licence. Here's the text of that exception:
"CLASSPATH" EXCEPTION TO THE GPL That exception makes it explicit that the ClassPath libraries so marked can be linked with other applications without affecting the licensing of the application. The JavaME edition has some additional libraries, specific to mobiles obviously, which do NOT offer this exception - they're GPL only. Hence why many users of JavaME chose to get a proprietary licence from Sun. Google do not use those APIs anyway, AFAIK. I.e. it does seem that there were no licensing obstacles to Google using the OpenJDK, at least in terms of wanting to avoid applications having to be GPLed (Google might have started its Dalvik work while Sun were still in the process of GPLing the JDK - anyone remember the exact timeline?). Given that Google generally went out of its way to avoid having any GPL code in Android, it seems that their motivation was simply to avoid being restricted in any way by copyleft. I wonder if that choice was made on a rational basis, or out of less rational, base GPL hatred/fear.
Classpath Exception not included in the mobile edition Posted Aug 20, 2010 10:08 UTC (Fri) by dgm (subscriber, #49227) [Link]
But again, JavaME is NOT covered by that exception. Thus the only way for Google to stay in the clear would have been to use the _full_ JavaSE, not a subset.
With the emphasis put on leanness as shown in Dalvik design, I can guess this was just ruled out?
Classpath Exception not included in the mobile edition Posted Aug 20, 2010 10:39 UTC (Fri) by nim-nim (subscriber, #34454) [Link]
Again, your argument is defeated by the fact that what Google finally produced is a lot closer to JavaSE than JavaME (Harmony is a JavaSE not ME clone)
JavaME was written for the kind of phones the iPhone and Android stormed over: clunky, limited hardware where the software was an afterthought because the phone industry worried more about ringtones and MMS than about the user experience
It takes more than a ME moniker to define what's needed on a smartphone.
Classpath Exception not included in the mobile edition Posted Aug 26, 2010 12:42 UTC (Thu) by willjcroz (guest, #62784) [Link]
AFAICT the use of JavaSE/Harmony libraries is complicated by the field of use restrictions issued by Sun for the OpenJDK JCK compliance test framework (required to 'comply' and get patent license). It's use on anything other than a standard computer on a desk is prohibited from what I have read.
See the open letter to Sun from Apache Harmony team:
http://www.apache.org/jcp/sunopenletter.html
and its related FAQ:
http://www.apache.org/jcp/sunopenletterfaq.html
From what I can find, Apache Harmony project's concerns have not been addressed. Unless you know otherwise, in which case please post details of how Sun addressed this.
Classpath Exception not included in the mobile edition Posted Aug 27, 2010 11:41 UTC (Fri) by mjw (subscriber, #16740) [Link]
> AFAICT the use of JavaSE/Harmony libraries is complicated by the field of use restrictions issued by Sun for the OpenJDK JCK compliance test framework (required to 'comply' and get patent license). It's use on anything other than a standard computer on a desk is prohibited from what I have read.
There are no such field of use restrictions in the OpenJDK JCK:
> From what I can find, Apache Harmony project's concerns have not been addressed.
The problem with their concerns is that they are unverifiable because they did the "negotiations" in secrecy without involving the bigger libre java community. They probably really got a bad deal, but it is hard to help out if they keep the details hidden: http://gnu.wildebeest.org/blog/mjw/2007/04/21/openjck/
Classpath Exception not included in the mobile edition Posted Aug 20, 2010 11:32 UTC (Fri) by mjw (subscriber, #16740) [Link]
> But again, JavaME is NOT covered by that exception. Thus the only way for Google to stay in the clear would have been to use the _full_ JavaSE, not a subset.
You seem to be confusing the "specification" with the "implementation" and what Android/Dalvik actually supports.
The full GPL implementation that Oracle/Sun distributes is called PhoneME: https://phoneme.dev.java.net/ https://phoneme.dev.java.net/source/browse/phoneme/legal/
The OpenJDK implementation under GPL (+ exception) that they distribute is an implementation of JavaSE.
Some of the specified libraries overlap (although there are some subtle differences in behaviour) but neither is a full subset or superset of the other.
An example of usage of both PhoneME, OpenJDK and GNU Classpath, JamVM or Cacao derived implementations on embedded devices is the Bug: http://community.buglabs.net/kgilmer/posts/45-BUG-OpenJDK
Another example that blurs the lines between SE and ME (and happily combines code from various free implementations, PhoneME, OpenJDK, GNU Classpath, Cacao, etc.) is MIDPath http://midpath.thenesis.org/bin/view/Main/
Android/Dalvik resembles the Java SE variant the most. It doesn't reall resemble any java variant directly. But it doesn't include anything in ME that is not in SE. It can be seen as a subset of the SE libraries, with specific Android libraries added. The implementation is designed to run well on small devices, but isn't JavaME like.
Classpath Exception not included in the mobile edition Posted Aug 22, 2010 5:00 UTC (Sun) by paulj (subscriber, #341) [Link]
It doesn't matter. Google are NOT using JavaME - they're using a subset of SE. So the OpenJDK GPL+CE implementation is there for their taking and should be acceptable - modulo the fact that Google don't seem to like the GPL much.
Classpath Exception not included in the mobile edition Posted Aug 18, 2010 11:42 UTC (Wed) by nim-nim (subscriber, #34454) [Link]
> Java ME started out as an effort to bring Java back to its original
> roots: as a language and environment for writing embedded applications. > The baseline ME profiles are pretty bare; I did some CLDC development > years ago and had to implement my own buffered streams and various data > structures just to get by. Even the biggest profiles are still fairly > restricted, and I don't believe any of them have ever graduated beyond > Java 1.3-level featuresets. So Sun did a great job of getting Java ME on > devices, back when people cared about Sun...and then they let mobile Java > stagnate to a terrible degree while they spent all resources trying to > get people to use Java EE and trying to get Java EE to suck less.
http://blog.headius.com/2010/08/my-thoughts-on-oracle-v-g...
> Android breaks new ground in the device category because it is a Java 2
http://www.oracle.com/technetwork/database/berkeleydb/bdb...
> As of 2008, all Java ME platforms are currently restricted to JRE 1.3
https://secure.wikimedia.org/wikipedia/en/wiki/Java_Platf...
|
|||||||||||||