[SR-Users] SEMS license with kamailio and rtpengine
Daniel-Constantin Mierla
miconda at gmail.com
Mon Feb 14 10:29:09 CET 2022
On 14.02.22 08:20, Olle E. Johansson wrote:
>
>
>> On 12 Feb 2022, at 09:40, Henning Westerholt <hw at gilawa.com> wrote:
>>
>> Hello,
>>
>> there is not that much the Kamailio project can do regarding the
>> licensing questions. Even if we clarify our point of view, the
>> license needs to be ultimately interpreted by lawyers or in court.
>> And it will be also specific regarding different countries, like
>> European countries, USA, China etc..
>>
>> Actually, there is a difference between interpreted languages and
>> compiled languages for the GPL. Its all explained in detail in this
>> entry:
>> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL
>>
> I do not fully agree that there’s not much we can do. We need to help
> our users and developers. We can clearly write that while it’s our
> intention that all configurations should be un-affected by the GPL, we
> believe that using LUA may be affected and add the pointers you have
> shared in email. I think that would help people making the right
> decisions.
I don't think that Lua script is affected either by GPL propagation due
to Kamailio, none of the configuration files script types are affected.
Lua script, even if it is compiled, is not linked to any Kamailio code
or object file, it is just some optimization variant of the text Lua
script. There is no difference between text and binary (compiled) Lua
script in terms of linking with kamailio code, it is only about some
different data format.
For interpreted languages, it would be the case of GPL propagation, if I
write a script where I include another GPL script. That is also the case
of kamailio.cfg native language. If I publish kamailio-antiflood.cfg
under GPL and one takes it to include its content to own kamailio.cfg,
then that kamailio.cfg falls under GPL.
Cheers,
Daniel
>
> /O
>> Cheers,
>>
>> Henning
>>
>> --
>> Henning Westerholt – https://skalatan.de/blog/
>> <https://skalatan.de/blog/>
>> Kamailio services – https://gilawa.com <https://gilawa.com/>
>>
>> *From:* sr-users <sr-users-bounces at lists.kamailio.org> *On Behalf
>> Of *Seven Du
>> *Sent:* Saturday, February 12, 2022 1:37 AM
>> *To:* Daniel-Constantin Mierla <miconda at gmail.com>; Kamailio (SER) -
>> Users Mailing List <sr-users at lists.kamailio.org>
>> *Subject:* Re: [SR-Users] SEMS license with kamailio and rtpengine
>>
>> Thanks all now I understand better.
>>
>> to @Daniel-Constantin Mierla <mailto:miconda at gmail.com> regarding to
>> the compiled lua code, I agree either it's an optimized binary or a
>> dynamic .so. it doesn't have to be GPL. But as discussed above, if
>> you load the compiled lua code into kamailio, it has to be GPL since
>> it links to the C code anyway directly, it calls kamailio functions
>> directly (e.g. t_relay()) but not via a socket, so that might applies
>> to GPL unless that explicitly clarified. even the kamailio config
>> scripts also has this problem, since kamailio config is not like
>> *pure* config files e.g. .ini or .yaml, it has it's own logic, it
>> calls functions in C, it's just another "language" like lua or js.
>> The only difference is that the native config or lua code is not
>> compiled at the same time of kamailio, it would be interpreted at run
>> time by kamailio. but GPL doesn't care about compile time, it just
>> cares if your code "calls" GPL functions.
>>
>> So if kamailio is not intended to restrict config or scripts via KEMI
>> to force GPL it might be good to explicitly clarify it?
>>
>> Also thanks @Johansson, as the discussion is long I list my
>> understanding or my question #5 here. According to the answer that
>> means when I write a module to load into kamailio, I cannot link to
>> libclosed.so as I cannot provide source code since it's by a 3-rd
>> party I cannot own the code and it's not GPL. So the only way to use
>> that libclosed.so with kamailio is to create a service and
>> communicate with kamailio via socket, evapi or http or anything else.
>>
>>
>> On Thu, Feb 10, 2022 at 11:34 PM Daniel-Constantin Mierla
>> <miconda at gmail.com> wrote:
>>
>> I think it is not easy to impose any further restriction not to
>> distribute the sources, but one can try ... in some (many)
>> countries licenses and patents are not recognized or not enforced.
>>
>> Cheers,
>> Daniel
>>
>> On 10.02.22 11:47, Alex Balashov wrote:
>>
>> Come to think of it, I imagine the license has language
>> saying that it cannot be superseded in part or in whole by
>> any contradictory agreement.
>>
>> —
>> Sent from mobile, with due apologies for brevity and errors.
>>
>>
>> On Feb 10, 2022, at 5:42 AM, Alex
>> Balashov <abalashov at evaristesys.com>
>> <mailto:abalashov at evaristesys.com> wrote:
>>
>> Is it legally possible for a customer to separately
>> contract away a right that the license otherwise affords
>> them, such as the GPL right to demand source code and
>> then turn around and distribute that source code?
>>
>> I have to wonder if it’s possible in the US. It seems
>> like it shouldn’t be, but in principle, in the prevailing
>> theme of Anglo-American jurisprudence, it’s possible to
>> contract away pretty much anything, no matter how adverse
>> to one’s interests, so long as it is done “freely”.
>>
>> —
>> Sent from mobile, with due apologies for brevity and errors.
>>
>>
>> On Feb 10, 2022, at 2:37 AM, Henning
>> Westerholt <hw at gilawa.com> <mailto:hw at gilawa.com> wrote:
>>
>>
>> Hello,
>>
>> just to add to the discussion:
>>
>> · Please have a look to the GPLv2 FAQ, many
>> topics you’ve raised are discussed
>> there https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html
>> · You should really consult a lawyer for this
>> specific questions
>>
>> Regarding the licence of the configuration (native
>> script vs. KEMI) – my understanding would be that a
>> native Kamailio cfg script would be independent of
>> GPL as its interpreted (and practically the customer
>> gets the “source code” anyway). But KEMI LUA code
>> that is pre-compiled would fall under the GPL, so the
>> customer has a right to get the source code for it.
>> Compare e.g., to
>> this: https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL
>>
>> Cheers,
>>
>> Henning
>>
>> --
>> Henning Westerholt – https://skalatan.de/blog/
>> <https://skalatan.de/blog/>
>> Kamailio services – https://gilawa.com
>> <https://gilawa.com/>
>>
>> *From:* sr-users <sr-users-bounces at lists.kamailio.org>
>> <mailto:sr-users-bounces at lists.kamailio.org> *On
>> Behalf Of *Olle E. Johansson
>> *Sent:* Thursday, February 10, 2022 8:13 AM
>> *To:* Kamailio (SER) - Users Mailing
>> List <sr-users at lists.kamailio.org>
>> <mailto:sr-users at lists.kamailio.org>
>> *Subject:* Re: [SR-Users] SEMS license with kamailio
>> and rtpengine
>>
>> Hi Seven!
>> Note that many of these questions open a legal
>> discussion that has been going on for many years. I
>> base my answers on what I know, which may not be the
>> full truth. Regardless, I have been involved in these
>> kind of discussions for almost 30 years of working in
>> open source.
>>
>> First, note that there are two kind of situations to
>> observe. One is when your application is executing in
>> a system. The other is the license of the written
>> source code files.
>>
>> Secondly, license and copyright are two different
>> things. You always have the copyright to your source
>> code.
>>
>> In Kamailio there are source code files that have a
>> different license than the rest of the files. That
>> means that if you copy that source code and create a
>> new product that license applies.
>>
>> Kamailio as a whole is released under GPL version 2.
>> When you run Kamailio in your server, that license
>> applies to it all, regardless of the license of
>> various source code files.
>>
>> Also note that I base this discussion on a delivery
>> of a system to a customer. When you run Kamailio as a
>> service you do not deliver (according to GPL v2) and
>> the customer doesn’t have the same rights to the source.
>>
>> Also note that (as other persons has pointed out)
>> that it’s the recipient of the binaries that has the
>> rights, not the world. If I am not your customer, I
>> can’t demand the source code according to the GPL.
>> The customer that receives the code has the right to
>> do whatever they want with it - like publishing the
>> source on GitHub for the world to enjoy.
>>
>>
>>
>>
>>
>> 10 feb. 2022 kl. 00:16 skrev Seven Du
>> <dujinfang at gmail.com>:
>>
>> I have some questions on this, e.g. on Kamailio:
>>
>> 1. The core and some modules is GPL. I packaged
>> that without change, and sell to a customer. and
>> when the customer asks for source, I told him to
>> download from the kamailio website, since I
>> didn't change anything. Is that correct?
>>
>> How you distribute the source code to the customer is
>> irrelevant here. Note that if you end up having to
>> provide it on a floppy disk or a USB stick, you can
>> charge for that according to the GPL :-)
>>
>>
>> 2. I can also host the source on my own website,
>> with some more helper scripts for building and
>> packaging. That should be better?
>>
>> I can’t judge if it’s better or worse, it has very
>> little relevance to with the license. Just make sure
>> that you include the signatures made by the Kamailio
>> team so the customer can trace it back to the source
>> and make sure there’s no changes.
>>
>>
>>
>>
>> 3. I write a new module, 100% code wrote from
>> scratch, just follow the module guidelines or
>> example code to expose/add hooks to core,
>> dynamically loaded into kamailio. Do I need to
>> use GPL or can it be any license or even closed
>> source? can I sell the standalone module in binary?
>>
>> Your source code has to be licensed in a license that
>> can end up being compatible with GPL. You can not
>> have a commercial license on it, since when executing
>> it as part of Kamailio, GPL applies.
>> Since your module ends up being GPL while running in
>> a system you deliver for a fee or for free to your
>> customer, your customers has a right to the source code.
>>
>>
>>
>>
>>
>> 4. my module still should be GPL since I have to
>> call GPL code in kamailio source, e.g. string
>> functions in core. or maybe it's ok if string
>> functions in kamailio core is BSD?
>>
>> When executing ALL of Kamailio is GPL, including all
>> linked modules.
>>
>>
>>
>>
>> 5. If my module link to a 3rd party lib (e.g.
>> libclosed-source.so or libclosed-source.a I think
>> there's no difference?) which is not open source
>> (but free to sell), can I sell it w/o the source
>> of libclosed-source ?
>>
>> Linking means that you execute in the same processes
>> and according to most this means that GPL applies.
>> That’s why we have a lot of protocols where most
>> people think that GPL does not apply, even though
>> some people want to discuss that. In my personal view
>> it’s ok to write commercial software that
>> communicates over RPC or by using the http_client
>> with Kamailio.
>>
>>
>> In Asterisk, the license specially permits this use
>> of the various Asterisk protocols since there was
>> discussions. Most Asterisk developers believed it
>> wasn’t necessary and that GPL did not apply when
>> using protocol based API’s. But nevertheless, just to
>> avoid discussions, this was clarified in the license.
>>
>>
>> 6. If answer to 5 is yes, I can write my own
>> libclosed-source and sell with whatever license?
>>
>> You can, but if it links to Kamailio in run-time,
>> then it will at that point become GPL licensed
>> regardless of what you have written. That’s why many
>> companies stay away from GPL, especially libraries
>> that are licensed with GPL, because it can affect
>> your own licenses.
>>
>>
>>
>>
>> 7. Regards to KEMI, if I write routing scripts
>> with Lua (compiled with luac) and sell to a
>> customer, should I open source the Lua code? The
>> Lua code calls Kamailio core functions which
>> might be GPL.
>>
>> That is an interesting question which I’m not ready
>> to answer. I think the intention of the Kamailio dev
>> team is that your code should not be affected by GPL,
>> but we may want to clarify that.
>>
>> If you write a regular configuration script I would
>> personally clearly think you have the rights to that.
>> The idea with KEMI was to introduce modern ways of
>> writing configuration scripts.
>>
>>
>>
>>
>> Thanks. I don't mean to violate the GPL, just
>> want to be clear and easier to understand the
>> license.
>>
>> Always good to start the day with a GPL discussion :-)
>>
>> Cheers,
>>
>> /O
>>
>>
>>
>> On Wed, Feb 9, 2022 at 9:05 PM Henning Westerholt
>> <hw at gilawa.com> wrote:
>>
>> Hello,
>>
>> (just to add the obvious disclaimer that this
>> is not legal advice, I am not a lawyer).
>>
>> > [Would it be ok] if it were [using] a
>> standalone service to which Kamailio
>> interfaced using very narrowly confined and
>> general-purpose communication channels?
>>
>> I do not think there is a problem regarding
>> to the GPL in this case. Interfacing over
>> SIP/HTTP/RPC/XMLRPC or other standard
>> mechanism to a dedicated process would not
>> establish a close coupling between Kamailio
>> and the other code.
>>
>>
>> I think it's correct. e.g. if you use evapi or
>> http to talk to your service you don't have to
>> open source your service code.
>>
>>
>> Cheers,
>>
>> Henning
>>
>> --
>> Henning Westerholt – https://skalatan.de/blog/
>> Kamailio services – https://gilawa.com
>>
>> -----Original Message-----
>> From: sr-users
>> <sr-users-bounces at lists.kamailio.org> On
>> Behalf Of Alex Balashov
>> Sent: Wednesday, February 9, 2022 1:50 PM
>> To: Kamailio (SER) - Users Mailing List
>> <sr-users at lists.kamailio.org>
>> Subject: Re: [SR-Users] SEMS license with
>> kamailio and rtpengine
>>
>>
>> > On Feb 9, 2022, at 7:46 AM, Henning
>> Westerholt <hw at gilawa.com> wrote:
>> >
>> >> If modules are designed to run linked
>> together in a shared address space, that
>> almost surely means combining them into one
>> program.”
>> >
>> > This is exactly what applies to Kamailio
>> due to the core and module architecture. The
>> core and modules also share common data
>> structures and memory segments.
>>
>> I see. So, practically, the only way a custom
>> module could be considered meaningfully
>> separate according to these criteria is if it
>> were a standalone service to which Kamailio
>> interfaced using very narrowly confined and
>> general-purpose communication channels?
>>
>> — Alex
>>
>> --
>> Alex Balashov | Principal | Evariste Systems LLC
>>
>> Tel: +1-706-510-6800 / +1-800-250-5920
>> (toll-free)
>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>>
>>
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non
>> Commercial Discussions
>> * sr-users at lists.kamailio.org
>> Important: keep the mailing list in the
>> recipients, do not reply only to the sender!
>> Edit mailing list options or unsubscribe:
>>
>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non
>> Commercial Discussions
>> * sr-users at lists.kamailio.org
>> Important: keep the mailing list in the
>> recipients, do not reply only to the sender!
>> Edit mailing list options or unsubscribe:
>>
>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>>
>> --
>> About: http://about.me/dujinfang
>> Blog: http://www.dujinfang.com
>> Proj: http://www.freeswitch.org.cn
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial
>> Discussions
>> * sr-users at lists.kamailio.org
>> Important: keep the mailing list in the
>> recipients, do not reply only to the sender!
>> Edit mailing list options or unsubscribe:
>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial
>> Discussions
>> * sr-users at lists.kamailio.org
>> Important: keep the mailing list in the recipients,
>> do not reply only to the sender!
>> Edit mailing list options or unsubscribe:
>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>>
>> __________________________________________________________
>>
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>
>> * sr-users at lists.kamailio.org
>>
>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>>
>> Edit mailing list options or unsubscribe:
>>
>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>> --
>>
>> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com/>
>>
>> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>>
>> Kamailio Advanced Training - Online
>>
>> Feb 21-24, 2022 (America Timezone)
>>
>> * https://www.asipto.com/sw/kamailio-advanced-training-online/
>>
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> * sr-users at lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply
>> only to the sender!
>> Edit mailing list options or unsubscribe:
>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>>
>> --
>> About: http://about.me/dujinfang
>> Blog: http://www.dujinfang.com
>> Other: http://rts.cn
>>
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> * sr-users at lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only
>> to the sender!
>> Edit mailing list options or unsubscribe:
>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
> * sr-users at lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the sender!
> Edit mailing list options or unsubscribe:
> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online
Feb 21-24, 2022 (America Timezone)
* https://www.asipto.com/sw/kamailio-advanced-training-online/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220214/372004cf/attachment.htm>
More information about the sr-users
mailing list