Hello from North Carolina where SIPit starts tomorrow!
Reading through the docs on the app_* modules I wonder how the GPLv2 is handled here. By default, GPL is sticky, so any module linked in to Kamailio will be GPL-licensed.
With app_mono, precompiled binaries are executed within Kamailio, but not "linked in" to the core. The question here is if we have a clear distinction here. If someone developes a Kamailio-based appliance and sells it - would the customer have the right to app_mono modules under the GPL?
What about python, java and Lua? I don't think these environments precompile, but they still execute within a GPL environment.
I think we need a clear statement about this in the README, like Asterisk has for AMI/AGI applications.
Greetings! /O
Hello Olle,
A very interesting and important question.
As maintainer and developer of app_python (and upcoming app_java), I'm a very interested in this question. I just looked for python's licenses (http://docs.python.org/3/license.html). Since app_python offers a correct work >= 2.4.3 (at least was tested a week ago), it's should be licensed under PSF license. PSF is also GPL-compatible license. ... GPL-compatible doesn’t mean that we’re distributing Python under the GPL. All Python licenses, unlike the GPL, let you distribute a modified version without making your changes open source. The GPL-compatible licenses make it possible to combine Python with other software that is released under the GPL; the others don’t. ...
2013/2/17 Olle E. Johansson oej@edvina.net
Hello from North Carolina where SIPit starts tomorrow!
Reading through the docs on the app_* modules I wonder how the GPLv2 is handled here. By default, GPL is sticky, so any module linked in to Kamailio will be GPL-licensed.
With app_mono, precompiled binaries are executed within Kamailio, but not "linked in" to the core. The question here is if we have a clear distinction here. If someone developes a Kamailio-based appliance and sells it - would the customer have the right to app_mono modules under the GPL?
What about python, java and Lua? I don't think these environments precompile, but they still execute within a GPL environment.
I think we need a clear statement about this in the README, like Asterisk has for AMI/AGI applications.
Greetings! /O _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
I think you need comments from lawyer here. My opinion is - license is applied to "end product" - doesn't matter if it is executable or library. According my understanding, if end product (executable or library) contains only headers from GPL 2 product, then end product can not be GPL 2 product. There are some restrictions - I mean non GPL product must use only structures - then it could be non GPL product. Asterisk is GPL product and it can use non GPL codecs (which are libraries).
On Sun, Feb 17, 2013 at 7:44 PM, Konstantin M. evilzluk@gmail.com wrote:
Hello Olle,
A very interesting and important question.
As maintainer and developer of app_python (and upcoming app_java), I'm a very interested in this question. I just looked for python's licenses (http://docs.python.org/3/license.html). Since app_python offers a correct work >= 2.4.3 (at least was tested a week ago), it's should be licensed under PSF license. PSF is also GPL-compatible license. ... GPL-compatible doesn’t mean that we’re distributing Python under the GPL. All Python licenses, unlike the GPL, let you distribute a modified version without making your changes open source. The GPL-compatible licenses make it possible to combine Python with other software that is released under the GPL; the others don’t. ...
2013/2/17 Olle E. Johansson oej@edvina.net
Hello from North Carolina where SIPit starts tomorrow!
Reading through the docs on the app_* modules I wonder how the GPLv2 is handled here. By default, GPL is sticky, so any module linked in to Kamailio will be GPL-licensed.
With app_mono, precompiled binaries are executed within Kamailio, but not "linked in" to the core. The question here is if we have a clear distinction here. If someone developes a Kamailio-based appliance and sells it - would the customer have the right to app_mono modules under the GPL?
What about python, java and Lua? I don't think these environments precompile, but they still execute within a GPL environment.
I think we need a clear statement about this in the README, like Asterisk has for AMI/AGI applications.
Greetings! /O _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 17.02.2013 18:30, Olle E. Johansson wrote:
Hello from North Carolina where SIPit starts tomorrow!
Reading through the docs on the app_* modules I wonder how the GPLv2 is handled here. By default, GPL is sticky, so any module linked in to Kamailio will be GPL-licensed.
Wasn't the core changed to BSD some time ago? If the core with the module API description is BSD, then I think modules could have non GPL licenses too.
With app_mono, precompiled binaries are executed within Kamailio, but not "linked in" to the core. The question here is if we have a clear distinction here. If someone developes a Kamailio-based appliance and sells it - would the customer have the right to app_mono modules under the GPL?
I think as long the the precompiled binary does not need Kamailio APIs/headers for compilation the mono app should be GPL-free.
What about python, java and Lua? I don't think these environments precompile, but they still execute within a GPL environment.
Same here. If the script does not refer to any GPL licensed API or module then it is GPL free.
I think we need a clear statement about this in the README, like Asterisk has for AMI/AGI applications.
With AMI the distinction is much more clearer and easier.
regards Klaus
Hello,
GNU GPL FAQ could give us some clues: http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html (in Combining work with code released under the GPL part)
Also to be sure we could email FSF.
On 02/18/2013 06:42 PM, Klaus Darilion wrote:
On 17.02.2013 18:30, Olle E. Johansson wrote:
Hello from North Carolina where SIPit starts tomorrow!
Reading through the docs on the app_* modules I wonder how the GPLv2 is handled here. By default, GPL is sticky, so any module linked in to Kamailio will be GPL-licensed.
Wasn't the core changed to BSD some time ago? If the core with the module API description is BSD, then I think modules could have non GPL licenses too.
If you use a module in kamailio which GPL license, then whole kamailio shares GPL license, even if core is licensed under BSD one.
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation
With app_mono, precompiled binaries are executed within Kamailio, but not "linked in" to the core. The question here is if we have a clear distinction here. If someone developes a Kamailio-based appliance and sells it - would the customer have the right to app_mono modules under the GPL?
I think as long the the precompiled binary does not need Kamailio APIs/headers for compilation the mono app should be GPL-free.
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL
Interpreting some code does not make that code needed to be licensed under GNU GPL (if you do not use any GPL bindings in your program).
If you mix some GPL code within your code, the whole code should be GPL licensed.
Regards, Vicente.
What about python, java and Lua? I don't think these environments precompile, but they still execute within a GPL environment.
Same here. If the script does not refer to any GPL licensed API or module then it is GPL free.
I think we need a clear statement about this in the README, like Asterisk has for AMI/AGI applications.
With AMI the distinction is much more clearer and easier.
regards Klaus
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev