| |||||||||||||
libc and javalibc and javaPosted Jun 7, 2011 22:56 UTC (Tue) by paulj (subscriber, #341)In reply to: libc and java by jonabbey Parent article: Android, forking, and control
If Sun had attached a "field of use" rider to the GPLed Java there would have been unroar. It wouldn't have been GPL compatible either. It would not have been free software. However, OpenJDK was not released with any such rider. The only thing it had was an additional permission, granting proprietary Java apps explicit permission to link to the OpenJDK libraries.
Much of the JavaME specific libraries were similarly licenced as GPL, but *without* the explicit linking permission. Thus, any JavaME distributors who wished to ship proprietary apps and be *sure* to avoid the GPL, had to still get a proprietary licence from Sun. Similarly if they wished to make proprietary modifications.
So your understanding is slightly off I think. Further, the JavaME thing wouldn't have affected Google had they chosen to use OpenJDK cause I don't believe Google had or have any interest in supporting the JavaME specific APIs.
There's a good blog post here on it:
(Log in to post comments)
libc and java Posted Jun 7, 2011 23:03 UTC (Tue) by jonabbey (subscriber, #2736) [Link]
Ah, yes. That post is where I got the notion of a 'field of use' restriction in the first place.
libc and java Posted Jun 7, 2011 23:08 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
I suspect that part of the issue was that they didn't want to be required to support _everything_ java an Android.
if they had used Java directly, they would have been required to support everything (with a court case to back them up, see the microsoft shenanigans), but by using a subset of the Java syntax, but a non-Java back-end they gained the ability to only implement the part of Java that they wanted.
Also, Sun had shown that it was reluctant to allow any other implementation of Java to be tested to get the Java name.
add to this the fact that they wanted to be able to tweak the implementation as needed (which, if "Java" would require re-certification), and you have pretty good case for not trying to use a true "Java" back-end.
libc and java Posted Jun 7, 2011 23:11 UTC (Tue) by jonabbey (subscriber, #2736) [Link]
Only so long as the adopter cared about the 'Java' name, though? Otherwise, trademark wouldn't be an issue.
libc and java Posted Jun 7, 2011 23:28 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
the thing is that Google _does_ want to use the name "Java" when talking about the programming syntax (as it implies that all the Java programmers out there will come up to speed quickly, and can probably use the tools that they are currently using)
it would get even more dicy to use the term Java for the syntax while you are using a subset of Java on the back end than what they did where they clearly state that the java syntax is converted to something else before being executed.
libc and java Posted Jun 7, 2011 23:30 UTC (Tue) by jonabbey (subscriber, #2736) [Link]
True enough, but I haven't heard that Oracle is going after Google on trademark violation grounds. Trademark violations are pretty to easy to remedy, unlike patent or copyright issues.
libc and java Posted Jun 8, 2011 12:38 UTC (Wed) by cate (subscriber, #1359) [Link]
Microsoft was suited for trademark violation with J++, so not including the "Java" keyword is not enough as long you tell user that it is like java.
libc and java Posted Jun 8, 2011 17:46 UTC (Wed) by paulj (subscriber, #341) [Link]
Sun v Microsoft came about because Microsoft licenced Java from Sun and had a contractual obligation to implement Java faithfully, as well as trademark infringement because Microsoft *were* calling their broken version Java.
libc and java Posted Jun 9, 2011 4:39 UTC (Thu) by tzafrir (subscriber, #11501) [Link]
So, Google did not want to re-implement parts of JavaME, so it went ahead and re-implemented the whole VM.
|
|||||||||||||