Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

libc and java

Posted Jun 6, 2011 23:41 UTC (Mon) by mjw (subscriber, #16740)
In reply to: libc and java by jonabbey
Parent article: Android, forking, and control

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.

(Log in to post comments)

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,
the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of
the library, but you are not obligated to do so. If you do not wish to do
so, delete this exception statement from your version.

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.