Skip to main content

Java ME and GPL and no linking exception

14 replies [Last post]
Anonymous

There is a /very important/ issue that needs clarification... It seems
the GPL linking exception was not applied to Java ME -- is that the case?

The concern has to do with the effects of GPL on applications. By _not
using LGPL_ -or- _not applying the GPL linking exception_ to Java ME, as
was done for Java SE, we might be exposed to the following concern:

Would it be true that when writing a |MIDlet| (or |Xlet|), since we are
"extending" the platform, that our app-level code (MIDlets, Xlets) must
follow GPL?

At first, my interpretation was this would apply if changing or
extending /the platform/-itself (as in the runtime)...

This can be interpreted both ways; extending a Java platform class
*/is/* a form of extending the platform.

We really need a clarification on this as soon as possible... Read the
official FAQ .

Thanks...

enrique

Source::
http://www.cenriqueortiz.com/weblog/JavaME%2C+J2ME/2006/11/14/Interpreti...

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mstempin
Offline
Joined: 2010-06-02
Points: 0

Let me reactivate this thread with a real-world example.

I manufacture an embedded Linux device featuring a Linux kernel, libraries and executables.

My customer is asking me to provide a JRE with foundation classes, CDC and a few JSRs. PhoneME Advanced MR2 seems to be a perfect match for this need.

Now, my customer had a Java application developed by a third party. The application is only making use of public Java APIs, defined by the JSRs, maybe implementing interfaces that are part of the platform specification and/or accessing and extending classes which are part of this specification, but do not extend it or modify it in a general way. As you stated it, this is thus not being considered as a derivative or combined work.

However, all this (Java application, JVM with classes, libraries, executables, kernel, bootloader, etc.) need to be integrated into the device's Flash memory at manufacturing time, for obvious production constraints.

IIUYC, for this last reason, the Java application code should be placed under GPL, am I right?

I would have several objections to this:

> Sun chose GPLv2 without classpath exception for Java ME because the method
> of bundling and distributing applications together with platform implementation
> code (which is practiced in the Java SE space) does not apply to Java ME.

Indeed, I think the situation is even worse for embedded systems using Java ME: because of manufacturing, the application can /only/ be distributed along with the JVM.

> Note that integrating your code into the Java ME platform implementation or
> installing your code into the device together with the platform implementation at
> the time of manufacturing of the device may trigger the copyleft properties of
> the GPL. In such cases it is recommended to contact Sun directly for more
> information.

Where does this statement come from? The Linux kernel itself is distributed under GPLv2, but it does not trigger anything that may require to publish my applications under GPLv2 too, is it?

In this case, the third-party Java application is not intended to run on the PhoneME Advanced Java implementation /only/ and may well run on another JVM using a different license as is (in bytecode form). I don't see how the GPL can change the license of an existing program.

> In such cases it is recommended to contact Sun directly for more information.

I understand that now PhoneME Advanced MR2 is partly based on community's work, along with original Sun's (now Oracle) work. This would now require to contact each and every contributor, unless an organization is relevant to manage all the contributor rights.

Please understand that I am not against GPL or FOSS at all: I gladly contribute every time I can. But I need to make this point clear regarding my customer.

Thanks,

Michel

terrencebarr
Offline
Joined: 2004-03-04
Points: 0

Michel,

Let me try and address some of your questions. Keep in mind that I am not
a lawyer and this is my personal opinion and not an official Sun or Oracle
position. Furthermore, I am simplifying some things here for brevity.
Finally, changes in policies and interpretation of licenses may occur going
forward.

> However, all this (Java application, JVM with classes, libraries, executables, kernel, bootloader, etc.) need to be integrated into the device's Flash memory at manufacturing time, for obvious production constraints.
>
> IIUYC, for this last reason, the Java application code should be placed under GPL, am I right?

Yes, this form of distribution would create a combined works and would likely
trigger the requirement of placing the application code under GPLv2 as well.

> Indeed, I think the situation is even worse for embedded systems using Java ME: because of manufacturing, the application can /only/ be distributed along with the JVM.

The original use case was focused on systems where applications are installed
independently from the Java runtime. For embedded situations like the one
you describe Sun offered a commercial license for the Java ME runtime. For
systems with more advanced requirements there is also a commercial
Java SE Embedded product.

> Where does this statement come from? The Linux kernel itself is distributed under GPLv2, but it does not trigger anything that may require to publish my applications under GPLv2 too, is it?

There is no uniform understanding in the industry and legal field regarding
the exact implications and requirements of the GPL terms. In the early days of
Linux Linus Torvalds posted several messages on the Linux kernel lists
regarding his interpretation. Also keep in mind that most Linux user-land applications link to libc and are subject to the LGPL, not the GPL.

> In this case, the third-party Java application is not intended to run on the PhoneME Advanced Java implementation /only/ and may well run on another JVM using a different license as is (in bytecode form). I don't see how the GPL can change the license of an existing program.

This is not a function of phoneME but a function the GPL terms and the
interaction of different licenses. It's a complicated field and I would
encourage you to read up on the various topics on the web related to this.

> I understand that now PhoneME Advanced MR2 is partly based on community's work, along with original Sun's (now Oracle) work. This would now require to contact each and every contributor, unless an organization is relevant to manage all the contributor rights.

All third party code that is integrated with phoneME must be submitted under
the Sun Contributor Agreement (SCA) and therefore Sun/Oracle is a joint
copyright holder. You can refer to the phoneME Community Participation Handbook
for more info.

Hope this helps,
-- Terrence

terrencebarr
Offline
Joined: 2004-03-04
Points: 0

Enrique,

OK, so let me try and clarify this:

Sun chose GPLv2 without classpath exception for Java ME because the method of
bundling and distributing applications together with platform implementation
code (which is practiced in the Java SE space) does not apply to Java ME.

We would like to make it absoutely clear that it is our intent to encourage
Java ME developers to freely innovate within the application space. However, we
understand that because of the different possible interpretations of the copyleft
properties of GPL it is important for Java ME developers to know where Sun stands
in this particular respect.

We believe that any Java ME code which is independent of the Java ME platform
implementation and is distributed separately from the Java ME platform implementation
and merely uses the functionality of the platform but does not extend or modify
the platform should not be considered a derivative or combined work of the platform
and as such is not impacted by the platform license.

In particular, you should be able to do the following without your code being
considered a derivative or combined work of the platform implementation:

1. calling of public APIs in the platform
2. implementing interfaces which are part of a public specification of the platform
3. accessing and extending classes which are part of a public specification of the
platform as long as your code does not extend or modify the Java ME platform in
a general way

Note that integrating your code into the Java ME platform implementation or
installing your code into the device together with the platform implementation at
the time of manufacturing of the device may trigger the copyleft properties of
the GPL. In such cases it is recommended to contact Sun directly for more information.

Please let me know if this answers your concerns.

Thanks,

-- Terrence

Terrence Barr
Evangelist, Java Mobile & Embedded Community
Sun Microsystems, Germany
www.mobileandembedded.org

brunos
Offline
Joined: 2003-06-10
Points: 0

> the method of
> bundling and distributing applications together with
> platform implementation
> code (which is practiced in the Java SE space) does
> not apply to Java ME.
>

What that means is:

- the GPL applies when you distribute the code, not when you run the code.

- Developers of JME applications generally do _NOT_ distribute the VM, the VM is already installed in the device.

- The end user of the GPL ME VM can run application with any license on top of that VM, he is not distributing the VM.

- A developer that distributes only the application does not need to care what is the licensing of the VM the code will run on, he is not distributing the VM.

- If a developer creates a new version of the ME VM and distribute it, the GPL copyleft applies to the modified ME VM.

- If a developer for any reason distributes the GPL ME VM with pre-installed applications, the GPL copyleft properties will also be triggered, and will affect the applications. That means that phone manufacturers and also cell phone operators will need to discuss licensing terms with Sun (what they would probably do anyway) or they will need to distribute their bundled applications under the GPL.

Note that in the case of the SE implementation, developers in a huge amount of situations _do_ distribute the VM with their application, this is why the classpath exception is needed.

Bruno.

terrencebarr
Offline
Joined: 2004-03-04
Points: 0

Typo: Sorry for the *slow* reply

terrencebarr
Offline
Joined: 2004-03-04
Points: 0

Enrico,
All,

Sorry for the reply. We want to make sure to give you a complete and useful answer so we're doing a final review at this point ... I'll post it by this evening (MET).

Thanks,

Terrence Barr
Evangelist, Java Mobile & Embedded Community
Sun Microsystems, Germany
www.mobileandembedded.org

C. Enrique Ortiz

Elliot hi. I'm sure and I've no doubts Sun is trying to do the right thing... That is not what I'm debating here. Your feedback is great, thanks. But note that is your interpretation... I've an interpretation as well... What matters is Sun's intent and interpretation of the licensing terms... Right now is a bit fuzzy and seems it needs clarification. Your quote below is not sufficient in my opinion - all Java platforms need some level of H/W integration. In addition in the impl there is H/W aware code and higher-level code. If I extend the MIDlet class by physically adding new behavior to the class, must I GPL? Prob yes. But if I extend by inheritance or composition do I have to GPL? What if I wrote from scratch the low level integration but obviously use or expose the high level MIDP, CLDC etc APIs? Do I need to GPL? What if someone else builds on top of my impl do they need to GPL? All standard questions. There is a very thin line. All I need is clarification. Guessing
I can't
----
ceo
(sent from my mobile)

-----Original Message-----

From: Elliotte Harold
Subj: Re: Java ME and GPL and no linking exception
Date: Tue Nov 14, 2006 8:29 am
Size: 1K
To: KVM-INTEREST@JAVA.SUN.COM

C. Enrique Ortiz wrote:
> There is a /very important/ issue that needs clarification... It seems
> the GPL linking exception was not applied to Java ME -- is that the case?
>

It is the case. According to Sun,
"With Java ME,
there is no way to install and integrate implementations. Instead,
implementations are integrated with the hardware. As such, the problem
the Classpath exception is solving with the Java SE implementation isn't
present with Java ME."

I believe Sun really intends to do the right thing here, and has no
intention of infecting your code merely by the act of it running on
their VM.

--
Elliotte Rusty Harold elharo@metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

--------------------------------
Spam/Virus scanning by CanIt Pro

For more information see
http://www.kgbinternet.com/SpamFilter.htm

To control your spam filter, log in at
http://filter.kgbinternet.com

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Adrian Valentin Dan

There is a fine yet noticable difference between "work based on the
platform" and "work linked against the platform". Providing a new MIDlet
implementation with specific behaviour is not considered extending the
platform anymore than implementing a J2ME virtual machine from scratch.

I think there is a great deal of confusion regarding this GPL license,
especially for dinamicly linked systems. So i will try to be as clear
and interpretation free in my explanations as i can.

The MIDP CLDC, CDC as well as any other standard API's are not subject
to the license (only its binary and code implementations which SUN has
provided), which means that anyone can write a virtual J2ME stack
implementation from scratch without having to care SUN's license choice.

Developing something that can run against SUN's KVM implementation is
not subject to the license, as long as it does not contain within any
affected code (linking is not the same thing as containing code, which i
will explain in the following paragraph).

Running your MIDlet extension against SUN's KVM virtual machine
implementation is not considered subject to the GPL license, because,
and here is the big breakthrough ..... (drums rolling)
You can run your code linked against any other J2ME stack
implementation, for example, i can run my MIDlet in the name here> Virtual machine implementation, which is subject to a
different license than GPL.

So to conclude this, as long as your bytecode does not actually contain
GPL licensed code you are free from it.

So. I bet you are now asking yourself ....
What is considered under the influence of the GPL then ?
What is this work based thing this whole thread is about ?

Lets assume you are extending the KVM to provide your own emulators, or
maybe implementing some nifty feature, that they currently not support,
then you have to distribute your code, (the one that extends the KVM)
under the GPL license.

* Replace all occurances of KVM with JavaME, it will still take me a
while to get used to it.

Cheers.
Adrian.

C. Enrique Ortiz wrote:
> Elliot hi. I'm sure and I've no doubts Sun is trying to do the right thing... That is not what I'm debating here. Your feedback is great, thanks. But note that is your interpretation... I've an interpretation as well... What matters is Sun's intent and interpretation of the licensing terms... Right now is a bit fuzzy and seems it needs clarification. Your quote below is not sufficient in my opinion - all Java platforms need some level of H/W integration. In addition in the impl there is H/W aware code and higher-level code. If I extend the MIDlet class by physically adding new behavior to the class, must I GPL? Prob yes. But if I extend by inheritance or composition do I have to GPL? What if I wrote from scratch the low level integration but obviously use or expose the high level MIDP, CLDC etc APIs? Do I need to GPL? What if someone else builds on top of my impl do they need to GPL? All standard questions. There is a very thin line. All I need is clarification. Guessing
> I can't
> ----
> ceo
> (sent from my mobile)
>
> -----Original Message-----
>
> From: Elliotte Harold
> Subj: Re: Java ME and GPL and no linking exception
> Date: Tue Nov 14, 2006 8:29 am
> Size: 1K
> To: KVM-INTEREST@JAVA.SUN.COM
>
> C. Enrique Ortiz wrote:
>
>> There is a /very important/ issue that needs clarification... It seems
>> the GPL linking exception was not applied to Java ME -- is that the case?
>>
>>
>
> It is the case. According to Sun,
> "With Java ME,
> there is no way to install and integrate implementations. Instead,
> implementations are integrated with the hardware. As such, the problem
> the Classpath exception is solving with the Java SE implementation isn't
> present with Java ME."
>
> I believe Sun really intends to do the right thing here, and has no
> intention of infecting your code merely by the act of it running on
> their VM.
>
> --
> Elliotte Rusty Harold elharo@metalab.unc.edu
> Java I/O 2nd Edition Just Published!
> http://www.cafeaulait.org/books/javaio2/
> http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
> --------------------------------
> Spam/Virus scanning by CanIt Pro
>
> For more information see
> http://www.kgbinternet.com/SpamFilter.htm
>
> To control your spam filter, log in at
> http://filter.kgbinternet.com
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

terrencebarr
Offline
Joined: 2004-03-04
Points: 0

Sorry for the late reply on this thread. I've been experiencing problems with my subscription setup.

Anyway, I agree with you that this needs clarification, especially in light of freely programmable phones like OpenMoko. I'll take this AI and get back to you.

Terrence Barr
Envangelist, Mobile & Embedded Community
Sun Microsystems

chris_gray
Offline
Joined: 2005-11-08
Points: 0

Yes, this is crucial.A typical Java device contains a number of components (hardware interfaces, proprietary algorithms) which the device maker cannot or does not wish to make public. One customer even asked us to create a custom VM which runs encrypted bytecode,so no one can disassemble their JAR files ...

I have great respect for Dalibor, but I don't go with him all the way on this. For me, the relationship between a Java application and the core APIs is less like the relation application-OS than the relation application-libC. In the latter case the GPL certainly seems to imply that an application linked with a GPLed library must be GPL-compatible, which is why the Lesser GPL was created; the Classpath exception fulfils a similar perceived need. If Sun apply the Classpath exception to some parts of their code and not to others, the natural conclusion is that Sun do think the exception does permit certain uses which would otherwise be prohibited, and that they want to permit these uses in some cases and not others. So: clarification, please!

The FAQ statement is just upside-down and back-to-front. Embedded Java needs linking exceptions (or clarifications) more than desktop or server Java, precisely because the JRE, platform libraries and applications are often shipped as a physical whole.

Let's hope we can nip FUD in the bud. :-)

robilad
Offline
Joined: 2004-05-05
Points: 0

Indeed.

In particular, people should understand that it's Sun's source, and the lines Sun draws are the way to go, rather than what I, or someone else not working for Sun publishes as their own non-lawyerish opinion on some forum.

That being said, my understanding is that Sun is trying hard to do all the good things they're doing now the right way, and removing potential confusion around the licensing choices made. Sun's Simon Phipps has addressed this question in another forum, I believe, so I think we'll see the confusion vanish quickly ... in the right way. ;)

cheers,
dalibor topic

Elliotte Harold

C. Enrique Ortiz wrote:
> There is a /very important/ issue that needs clarification... It seems
> the GPL linking exception was not applied to Java ME -- is that the case?
>

It is the case. According to Sun,
"With Java ME,
there is no way to install and integrate implementations. Instead,
implementations are integrated with the hardware. As such, the problem
the Classpath exception is solving with the Java SE implementation isn't
present with Java ME."

I believe Sun really intends to do the right thing here, and has no
intention of infecting your code merely by the act of it running on
their VM.

--
Elliotte Rusty Harold elharo@metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Elliotte Harold

C. Enrique Ortiz wrote:
> There is a /very important/ issue that needs clarification... It seems
> the GPL linking exception was not applied to Java ME -- is that the case?
>
> The concern has to do with the effects of GPL on applications. By _not
> using LGPL_ -or- _not applying the GPL linking exception_ to Java ME, as
> was done for Java SE, we might be exposed to the following concern:
>

IMO (and IANAL) even sans the classpath exception, merely using a GPL VM
to run or compile your code does not infect your application.

This is more like an operating system such as Linux and the mere act of
writing, compiling, and running code on the platform does not infect it.
However, IANAL; and I have not yet heard Sun or the Free Software
Foundation comment on this. Dalibor Topic from the Kaffe project has
looked into this and he says:

This is more like an operating system such as Linux and the mere act of
writing, compiling, and running code on the platform does not infect it.
Dalibor Topic from the Kaffe project has looked into this and he says:

I know a fair bit about the usage of GPL, and its effect in
this scenario, since I had to deal with licensing FUD earlier,
and had ample opportunities to discuss it with David Turner
and others from the FSF.

The GPL doesn't require that bytecode classes using a GPLd
java.lang.Object be licensed under the GPL as well. That's
because neither the bytecode nor the source code using it are
derivative works of java.lang.Object, as all that ever ends up
in them are interface names and constants, and those remain
the same, regardless of the license of the java.lang.Object
class. Those symbols are standardised through the JCP, and
published as specifications. They are necessary for
interoperability.

Therefore, the symbol names and constant values can not be
claimed as original works by a GPLd java.lang.Object, and
accordingly don't meet the bar for copyrightability.

The GPL can only work through copyrightable elements of a
work, and in a normal bytecode class file using
java.lang.Object, there is no such thing stemming from
java.lang.Object in it.

Per design of the bytecode format, I might add.

The main purpose of the classpath exception is just to make an explicit
statement that this is so.

--
Elliotte Rusty Harold elharo@metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

C. Enrique Ortiz

Since interpretation (and prev interpretations) can be a good or
dangerous thing, I am hoping this can be clarified by Sun and included
in the FAQ or similar. I would prefer this is very explicitly defined,
to avoid the wrong interpretation. Thanks.

enrique

Elliotte Harold wrote:
> C. Enrique Ortiz wrote:
>> There is a /very important/ issue that needs clarification... It seems
>> the GPL linking exception was not applied to Java ME -- is that the
>> case?
>>
>> The concern has to do with the effects of GPL on applications. By _not
>> using LGPL_ -or- _not applying the GPL linking exception_ to Java ME, as
>> was done for Java SE, we might be exposed to the following concern:
>>
>
> IMO (and IANAL) even sans the classpath exception, merely using a GPL VM
> to run or compile your code does not infect your application.
>
> This is more like an operating system such as Linux and the mere act of
> writing, compiling, and running code on the platform does not infect it.
> However, IANAL; and I have not yet heard Sun or the Free Software
> Foundation comment on this. Dalibor Topic from the Kaffe project has
> looked into this and he says:
>
> This is more like an operating system such as Linux and the mere act of
> writing, compiling, and running code on the platform does not infect it.
> Dalibor Topic from the Kaffe project has looked into this and he says:
>
>
> I know a fair bit about the usage of GPL, and its effect in
> this scenario, since I had to deal with licensing FUD earlier,
> and had ample opportunities to discuss it with David Turner
> and others from the FSF.
>
> The GPL doesn't require that bytecode classes using a GPLd
> java.lang.Object be licensed under the GPL as well. That's
> because neither the bytecode nor the source code using it are
> derivative works of java.lang.Object, as all that ever ends up
> in them are interface names and constants, and those remain
> the same, regardless of the license of the java.lang.Object
> class. Those symbols are standardised through the JCP, and
> published as specifications. They are necessary for
> interoperability.
>
> Therefore, the symbol names and constant values can not be
> claimed as original works by a GPLd java.lang.Object, and
> accordingly don't meet the bar for copyrightability.
>
> The GPL can only work through copyrightable elements of a
> work, and in a normal bytecode class file using
> java.lang.Object, there is no such thing stemming from
> java.lang.Object in it.
>
> Per design of the bytecode format, I might add.
>
>
> The main purpose of the classpath exception is just to make an explicit
> statement that this is so.
>
>
> --
> Elliotte Rusty Harold elharo@metalab.unc.edu
> Java I/O 2nd Edition Just Published!
> http://www.cafeaulait.org/books/javaio2/
> http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
>
> ===========================================================================
>
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
> --------------------------------
> Spam/Virus scanning by CanIt Pro
>
> For more information see
> http://www.kgbinternet.com/SpamFilter.htm
>
> To control your spam filter, log in at
> http://filter.kgbinternet.com
>

--
C. Enrique Ortiz
----------------
Website: http://www.CEnriqueOrtiz.com
Weblog: http://www.CEnriqueOrtiz.com/weblog
Mobile Monday Austin: http://www.MobileMondayAustin.com
Austin Wireless Alliance: http://www.AustinWirelessAlliance.org

"Soylent Green is People!"

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".