|
Replies:
12
-
Last Post:
Nov 28, 2006 11:12 PM
by: brunos
|
|
|
|
|
|
|
Java ME and GPL and no linking exception
Posted:
Nov 14, 2006 5:38 AM
|
|
|
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 <http://.
Thanks...
enrique
Source::
http://www.cenriqueortiz.com/weblog/JavaME%2C+J2ME/2006/11/14/Interpreting-Java-under-GPL-does-it-forces-applications-to-be-GPL-as-well.html
===========================================================================
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]
|
|
|
|
|
|
|
Re: Java ME and GPL and no linking exception
Posted:
Nov 14, 2006 5:44 AM
in response to: C. Enrique Ortiz
|
|
|
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".
|
|
|
|
|
|
|
|
|
Re: Java ME and GPL and no linking exception
Posted:
Nov 14, 2006 6:19 AM
in response to: Elliotte Harold
|
|
|
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".
|
|
|
|
|
|
|
|
|
Re: Java ME and GPL and no linking exception
Posted:
Nov 14, 2006 5:52 AM
in response to: C. Enrique Ortiz
|
|
|
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,
<http:// "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".
|
|
|
|
|
|
|
|
|
Re: Java ME and GPL and no linking exception
Posted:
Nov 14, 2006 7:16 AM
in response to: C. Enrique Ortiz
|
|
|
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
|
|
|
|
|
|
|
|
|
Re: Java ME and GPL and no linking exception
Posted:
Nov 15, 2006 1:28 AM
in response to: terrencebarr
|
|
|
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. 
|
|
|
|
|
|
|
|
|
Re: Java ME and GPL and no linking exception
Posted:
Nov 17, 2006 9:44 AM
in response to: chris_gray
|
|
|
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
|
|
|
|
|
|
|
|
|
Re: Java ME and GPL and no linking exception
Posted:
Nov 14, 2006 7:49 AM
in response to: 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 <elharo@METALAB.UNC.EDU>
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,
<http:// "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".
|
|
|
|
|
|
|
|
|
Re: Java ME and GPL and no linking exception
Posted:
Nov 15, 2006 12:24 AM
in response to: C. Enrique Ortiz
|
|
|
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 <Insert company
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 <elharo@METALAB.UNC.EDU>
> 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,
> <http:// "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".
|
|
|
|
|
|
|
|
|
Re: Java ME and GPL and no linking exception
Posted:
Nov 17, 2006 3:55 AM
in response to: C. Enrique Ortiz
|
|
|
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
|
|
|
|
|
|
|
|
|
Re: Java ME and GPL and no linking exception
Posted:
Nov 17, 2006 3:58 AM
in response to: C. Enrique Ortiz
|
|
|
Typo: Sorry for the *slow* reply
|
|
|
|
|
|
|
|
|
Clarification: Java ME and GPL and no linking exception
Posted:
Nov 17, 2006 10:17 AM
in response to: C. Enrique Ortiz
|
|
|
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
|
|
|
|
|
|
|
|
|
Re: Clarification: Java ME and GPL and no linking exception
Posted:
Nov 28, 2006 11:12 PM
in response to: terrencebarr
|
|
|
> 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.
|
|
|
|
|
java.net RSS
