xmlvm-users

[xmlvm-users] status and (L)GPL

[Thorsten S. <co...@pa...>]

Hello,
I have a question about the projects license. From an earlier mail to 
this list I understand that Xmlvm switched to the LGPL. The SF project 
page indicates that, too.

The SVN sources and a site on xmlvm.org is still mentioning the GPL. 
Maybe that should be removed at some point:
http://xmlvm.org/download/
http://xmlvm.svn.sourceforge.net/viewvc/xmlvm/trunk/xmlvm/


Assuming the LGPL is correct: I was wondering if you have any tips on 
how an Xmlvm user can properly follow that license, given the 
requirement for an application user to be able to exchange the library 
part with his own version. I find this hard to achieve on the various 
mobile platforms that Xmlvm (especially with the upcoming C backend) is 
going to be able to reach. Wouldn't the Classpath Exception be more 
suitable?


Also, would you be so kind to provide a rough estimation on when the new 
C backend will be available? I read that there were dependency problems 
if one attempted to translate parts of the OpenJDK resulting in a large 
executable.

Tank you very much for your great work,
Best regards,
Thorsten.

Re: [xmlvm-users] status and (L)GPL

[Arno P. <ar...@pu...>]

we did change the license to L-GPL. I haven't come around to change the 
files in the main directory of the code repository. I just did that. At 
some point we also need to change all the headers of the source files 
that still mention GPL.

I'm not sure I understand your question. The "L" in L-GPL is similar in 
nature to the Classpath Exception. You can write your own application 
with XMLVM without having to license your application under the GPL (and 
therefore keeping your application proprietary). If you make 
modifications to XMLVM, you have to contribute those back to the community.

Arno


On 12/1/10 6:36 AM, Thorsten Schemm wrote:
> Hello,
> I have a question about the projects license. From an earlier mail to
> this list I understand that Xmlvm switched to the LGPL. The SF project
> page indicates that, too.
>
> The SVN sources and a site on xmlvm.org is still mentioning the GPL.
> Maybe that should be removed at some point:
> http://xmlvm.org/download/
> http://xmlvm.svn.sourceforge.net/viewvc/xmlvm/trunk/xmlvm/
>
>
> Assuming the LGPL is correct: I was wondering if you have any tips on
> how an Xmlvm user can properly follow that license, given the
> requirement for an application user to be able to exchange the library
> part with his own version. I find this hard to achieve on the various
> mobile platforms that Xmlvm (especially with the upcoming C backend) is
> going to be able to reach. Wouldn't the Classpath Exception be more
> suitable?
>
>
> Also, would you be so kind to provide a rough estimation on when the new
> C backend will be available? I read that there were dependency problems
> if one attempted to translate parts of the OpenJDK resulting in a large
> executable.
>
> Tank you very much for your great work,
> Best regards,
> Thorsten.
>
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App&  Earn a Chance To Win $500!
> Tap into the largest installed PC base&  get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] status and (L)GPL

[Thorsten S. <co...@pa...>]

> I'm not sure I understand your question. The "L" in L-GPL is similar in
> nature to the Classpath Exception. You can write your own application
> with XMLVM without having to license your application under the GPL (and
> therefore keeping your application proprietary). If you make
> modifications to XMLVM, you have to contribute those back to the community.

Thanks for your response. Yes, I figured that was the intention. But 
what worries me is that the LGPL talks about allowing the user to modify 
the app by replacing the LGPL library part with his or her customized 
version. Or something like that, the text is not exactly easy to read 
for me. Please have a look:
http://www.gnu.org/licenses/lgpl.html
Section 4d

If my rough interpretation above is correct, then I do not see how any 
user, even with developer knowledge, would be able to modify a 
distributed iPhone app (as one example) and be able to continue to use it.

Best regards,
Thorsten.

Re: [xmlvm-users] status and (L)GPL

[Hansi R. <su...@su...>]

> Please have a look:
> http://www.gnu.org/licenses/lgpl.html
> Section 4d
>
> If my rough interpretation above is correct, then I do not see how any
> user, even with developer knowledge, would be able to modify a
> distributed iPhone app (as one example) and be able to continue to use it.

my feeling kinda agrees with thorsten,
i'm not sure lgpl is "lose" enough because the resulting files contain
a mix of "your" translated code that is stuffed into pre-written
(lgpl) skeletons.
this is neither inheritance nor linking, the two ways i know of in
which the lgpl doesn't force the main application to be lgpl as well.

i would say that most code-generating programs will have a problem like this.
for example, look at the bison (parser generator) exception for the
generated code:
http://www.gnu.org/software/bison/manual/html_node/Conditions.html
(really worth the read, too long to quote)

imho this is mostly the same situation. adding a similar exception or
providing the
skeleton files with a more liberal license (e.g. bsd) would be a safe path.


more to this can found on the gpl-faq, which answers to "can i force
the output of a gpl-program to be gpl as well"?
http://www.gnu.org/licenses/gpl-faq.html#GPLOutput
it says generally no; this is impossible because the output belongs to
the user, however, it also says explicitly
"For instance, part of the output of Bison (see above) would be
covered by the GNU GPL, if we had not made an exception in this
specific case."
this is exactly what i think the problem with xmlvm output is (at this point).



best, hansi.

Re: [xmlvm-users] status and (L)GPL

[Panayotis K. <pan...@pa...>]

> 
> i would say that most code-generating programs will have a problem like this.
> for example, look at the bison (parser generator) exception for the
> generated code:
> http://www.gnu.org/software/bison/manual/html_node/Conditions.html
> (really worth the read, too long to quote)
> 

...

> more to this can found on the gpl-faq, which answers to "can i force
> the output of a gpl-program to be gpl as well"?
> http://www.gnu.org/licenses/gpl-faq.html#GPLOutput
> it says generally no; this is impossible because the output belongs to
> the user, however, it also says explicitly
> "For instance, part of the output of Bison (see above) would be
> covered by the GNU GPL, if we had not made an exception in this
> specific case."
> this is exactly what i think the problem with xmlvm output is (at this point).
> 


Actually these thoughts have been discussed a lot in the past, and thus the XMLVM project changed license from GPL to LGPL.
Not surprisingly, these were the actual arguments at that time.

From my point of view, still I can't see what the problem is with LGPL (which form my understanding is less restrictive than GPL (even with classpath exeption).
Btw, everybody knows why GNU.org and friends doesn't like LGPL and prefer the more restrictive GPL
http://www.gnu.org/licenses/why-not-lgpl.html

Re: [xmlvm-users] status and (L)GPL

[Arno P. <ar...@pu...>]

ok, guys, the generated code of gcc, bison, xmlvm do not fall under GPL 
or L-GPL. The clarification for bison is that since there is a bit of 
library portion that needs to be linked against the generated code 
automatically makes the whole application GPL (note that bison is GPL, 
not L-GPL). Since xmlvm is licensed under L-GPL, this problem does not 
occur.

IMHO, the idea of L-GPL is to allow commercial usage. Let me be clear 
about our intentions: we (the xmlvm core team) want developers to be 
able to use xmlvm for their commercial products. My understanding of the 
L-GPL is that is like the GPL with a Classpath Linking Exception.

Arno


On 12/1/10 10:13 AM, Hansi Raber wrote:
>> Please have a look:
>> http://www.gnu.org/licenses/lgpl.html
>> Section 4d
>>
>> If my rough interpretation above is correct, then I do not see how any
>> user, even with developer knowledge, would be able to modify a
>> distributed iPhone app (as one example) and be able to continue to use it.
>
> my feeling kinda agrees with thorsten,
> i'm not sure lgpl is "lose" enough because the resulting files contain
> a mix of "your" translated code that is stuffed into pre-written
> (lgpl) skeletons.
> this is neither inheritance nor linking, the two ways i know of in
> which the lgpl doesn't force the main application to be lgpl as well.
>
> i would say that most code-generating programs will have a problem like this.
> for example, look at the bison (parser generator) exception for the
> generated code:
> http://www.gnu.org/software/bison/manual/html_node/Conditions.html
> (really worth the read, too long to quote)
>
> imho this is mostly the same situation. adding a similar exception or
> providing the
> skeleton files with a more liberal license (e.g. bsd) would be a safe path.
>
>
> more to this can found on the gpl-faq, which answers to "can i force
> the output of a gpl-program to be gpl as well"?
> http://www.gnu.org/licenses/gpl-faq.html#GPLOutput
> it says generally no; this is impossible because the output belongs to
> the user, however, it also says explicitly
> "For instance, part of the output of Bison (see above) would be
> covered by the GNU GPL, if we had not made an exception in this
> specific case."
> this is exactly what i think the problem with xmlvm output is (at this point).
>
>
>
> best, hansi.
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App&  Earn a Chance To Win $500!
> Tap into the largest installed PC base&  get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] status and (L)GPL

[Hansi R. <su...@su...>]

hey!

> ok, guys, the generated code of gcc, bison, xmlvm do not fall under GPL
> or L-GPL. The clarification for bison is that since there is a bit of
> library portion that needs to be linked against the generated code
> automatically makes the whole application GPL (note that bison is GPL,
> not L-GPL). Since xmlvm is licensed under L-GPL, this problem does not
> occur.
i agree to 99%. the 1% i don't agree on is for instance the file
"Application.js.template"
that is part of xmlvm (thus lgpl):

to make my point clear let me quote the file here:


/* ************************************************************************
#asset(temp_qx_app/*)
************************************************************************ */
/**
 * This is the main application class of your custom application "temp_qx_app"
 */
qx.Class.define("{{XMLVM_TEMP_PROJECT_NAME}}.Application",
{
  extend : qx.application.Standalone,
  members :
  {
    main : function()
    {
      // Call super class
      this.base(arguments);

      // Enable logging in debug variant
      if (qx.core.Variant.isSet("qx.debug", "on"))
      {
        // support native logging capabilities, e.g. Firebug for Firefox
        qx.log.appender.Native;
        // support additional cross-browser console. Press F7 to
toggle visibility
        qx.log.appender.Console;
      }
      {{XMLVM_MAIN_METHOD_CALL}}
    }
  }
});



this is lgpl code and the transformed code is copied into it,
which imho is a modification (not inheritance or linking) of the
original code, and should thus
be made available under the lgpl as well.

i might be wrong about this and as long as the intentions of the
project are clear
this is not going to be a problem at all.


best, hansi.