| |||||||||||||
libc and javalibc and javaPosted Jun 6, 2011 21:43 UTC (Mon) by rfunk (subscriber, #4054)Parent article: Android, forking, and control
My understanding was that the rewrite of libc and the Java (->Dalvik) runtime was partly for GPL reasons, but also partly for technical reasons of performance on systems that are beefier than what the embedded community normally aims for, but not quite up to modern desktop or server systems. (The first Android flagship phone was 528MHz/192MB.)
In addition, I seem to recall legal issues relating to Java Mobile Edition (which was more likely than Standard Edition to perform well on the hardware originally being targeted). And for all the talk of Android fragmentation, one of the things Android has freed us from was the crazy fragmentation in the JME world.
Now, of course, we're getting phones whose hardware is approaching my laptop that's only a couple years old, so many of those technical concerns are moot now.
(Log in to post comments)
libc and java Posted Jun 6, 2011 22:35 UTC (Mon) by jonabbey (subscriber, #2736) [Link]
Yes, my understanding was that Java Standard Edition was available via GPL only via an attached 'field of use' rider which prohibited the GPL from applying to mobile phone usage.
Sun was attempting to derive a lot of cash money from Java Mobile Edition, and their standard edition licensing was apparently designed to help drive that.
libc and java Posted Jun 6, 2011 22:37 UTC (Mon) by jonabbey (subscriber, #2736) [Link]
Actually, if I remember correctly, in order to use 'Java' under GPL, you had to agree not to subset the API set. You could tweak and distribute, you could add and distribute, but you could not remove any portions of the Java platform that comprised the standard edition.
If you wanted to subset, you had to pay for Java Mobile Edition, and agree to carry all APIs that Sun wanted carried.
By going the Dalvik route, Google was going for the ability to control their API destiny, in the same way Microsoft attempted with their release of 'Java' in the 90's. It wasn't about copyleft concerns.
libc and java Posted Jun 6, 2011 23:41 UTC (Mon) by mjw (subscriber, #16740) [Link]
Neither is true for either the Java SE reference implementation (OpenJDK) or the Java ME reference implementation (PhoneME). Both are available under the GPL, without any sub-or-super-setting restrictions. Such restrictions wouldn't be GPL-compatible in the first place.
libc and java Posted Jun 6, 2011 23:56 UTC (Mon) by jonabbey (subscriber, #2736) [Link]
Ah, okay. The issue was not one of the GPL applying "except for.." but rather that Sun was using the power to interpret what code would be considered "derived" and thus being under copyleft. If you wanted to use certain of the mobile edition classes, you had to have some other license if you weren't willing to make your code GPL.
The language in Oracle's license declaration is:
--
"CLASSPATH" EXCEPTION TO THE GPL
Certain source files distributed by Oracle America and/or its affiliates are subject to the following clarification and special exception to the GPL, but only where Oracle has expressly included in the particular source file's header the words "Oracle designates this particular file as subject to the "Classpath" exception as provided by Oracle in the LICENSE file that accompanied this code."
Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.
As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module,
--
Which would, indeed, make it a copyleft issue for the non-covered classes.
With Google using a differently licensed reimplementation of the class libraries, they are able to avoid having any mandatory copyleft requirement apply to Android developers, but patents are separate.
Thanks for the clarification and pointer.
libc and java Posted Jun 7, 2011 4:09 UTC (Tue) by smurf (subscriber, #17840) [Link]
Cute.
The FSF's stance on this is that dynamic linking does not create derived works, period.
libc and java Posted Jun 7, 2011 4:22 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
I wish it was that clear.
if it was, then what is the difference between the GPL and the LGPL, the only difference between them is about linking.
libc and java Posted Jun 7, 2011 6:54 UTC (Tue) by paulj (subscriber, #341) [Link]
[citation needed] for that extra-ordinary claim. Everything points to the opposite (e.g. the existence of the LGPL as per other commentator).
libc and java Posted Jun 7, 2011 7:02 UTC (Tue) by smurf (subscriber, #17840) [Link]
You're right. My bad.
libc and java Posted Jun 7, 2011 10:58 UTC (Tue) by mjw (subscriber, #16740) [Link]
> The language in Oracle's license declaration is:
> [...] the GNU Classpath class library exception text [...] > Which would, indeed, make it a copyleft issue for the non-covered classes.
Indeed. But in practice for SE all classes are covered. In OpenJDK all sources for the core library classes carry this exception text. This was just like how GNU Classpath used to handle this case, by having that exact same exception to cover the whole core class library.
libc and java Posted Jun 7, 2011 22:56 UTC (Tue) by paulj (subscriber, #341) [Link]
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:
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.
libc and java Posted Jun 9, 2011 7:49 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
Please stop beating this dead horse. The Dalvik+Harmony environment is an almost complete JAVA SE-like environment, not a JME one, so the "JME was not available" argument is contradicted by reality (and in fact, before Oracle started suing, many entities acknowledged this and praised Android for not being bound by JME limitations)
JME was out of the scope from the beginning, it is too limited to create a successful Android-like smartphone platform.
libc and java Posted Jun 9, 2011 12:32 UTC (Thu) by rfunk (subscriber, #4054) [Link]
You seem to be responding only to my "in addition" paragraph, and ignoring what preceded. I tried to say (but apparently only implied) that JME was too small. But I was also saying that JSE was too big and slow on the target hardware, compared to what they were able to do with Dalvik.
|
|||||||||||||