[SR-Users] SEMS license with kamailio and rtpengine
Daniel-Constantin Mierla
miconda at gmail.com
Thu Feb 10 16:13:17 CET 2022
Hello,
On 10.02.22 10:51, Henning Westerholt wrote:
>
> Hello,
>
> Just to add - your general statement “From this perspective, none of
> the config files (no matter they are native scripting, lua, python,
> javascript, etc...) are forced to be GPL, it is the decision of the
> config author what's its license.”
>
> This seems to be pretty clear to me as well, the previous discussion
> was more a question of this pre-compiled Lua files.
>
I also referred to the pre-compiled lua files (listed the other types of
configs for sake of completion). In this particular case Lua (and luac)
are anyhow distributed under MIT (iirc) and compiling a kamailio.lua
file is like:
luac kamailio.lua
There is no directly linking against any .c/.h/.o/.so file from
kamailio. Maybe it is a little stretched to say compiled in this case,
imo, I think it is more like parsing and create a binary-optimized file
that lua interpreter (or liblua functions) can load and execute faster,
it does not generate machine code, as I understand.
Further more, even if luac would be GPL, I don't think that compiling
file.lua would mean that file.lua nor the resulting file.bin will be
forced to be GPL, in that way everything compiled with GCC would be
forced to be GPL.
I found that Perl has some statement on their web page, but not sure how
much legal binding is behind it, it is stated as a personal opinion from
Larry:
* https://dev.perl.org/licenses/
If I would try to make a rule regarding compiled/binary apps/components,
maybe I would say it like: if there is a single binary component that is
shipped and it was build from different source components of which at
least one is GPL, then sources of all these components must be
distributed under GPL due to its virality.
In Kamailio case, we have kamailio app binary and kamailio.cfg (or
kamailio.lua) shipped as separate files/components.
Obviously, ultimately a judge can have the final world, and can be from
case to case, country to county, judge to judge, ...
Cheers,
Daniel
> Cheers,
>
>
>
> Henning
>
>
>
>
>
> *From:* Henning Westerholt
> *Sent:* Thursday, February 10, 2022 10:46 AM
> *To:* 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
>
>
>
> Hello,
>
>
>
> for me it’s seems to be not that clear, its open to interpretation.
> But this is more a theoretical discussion, it should be clarified from
> a lawyer.
>
> To quote from the GPL FAQ:
>
>
>
> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL
>
> “Another similar and very common case is to provide libraries with the
> interpreter which are themselves interpreted. For instance, Perl comes
> with many Perl modules[..]. These libraries and the programs that call
> them are always dynamically linked together.
>
> A consequence is that if you choose to use GPL'd Perl modules [..] in
> your program, you must release the program in a GPL-compatible way,
> regardless of the license used in the Perl [..] interpreter that the
> combined Perl [..] program will run on. “
>
> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation
>
> “Combining two modules means connecting them together so that they
> form a single larger program. If either part is covered by the GPL,
> the whole combination must also be released under the GPL—if you
> can't, or won't, do that, you may not combine them.
>
> [..] if the semantics of the communication are intimate enough,
> exchanging complex internal data structures, that too could be a basis
> to consider the two parts as combined into a larger program.”
>
> This seems to apply to the KEMI Lua. You execute the Kamailio (GPL)
> function in your KEMI script by some library mechanism.
>
> The Lua script and Kamailio are not using a standardized interface to
> interact together like e.g., SIP messages, it’s a custom specific one.
>
>
>
> But if its specific enough to fall under this license restriction is
> the main point, we can probably not answer fully from our side.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> *From:*Daniel-Constantin Mierla <miconda at gmail.com>
> *Sent:* Thursday, February 10, 2022 9:01 AM
> *To:* Kamailio (SER) - Users Mailing List
> <sr-users at lists.kamailio.org>; Henning Westerholt <hw at gilawa.com>
> *Subject:* Re: [SR-Users] SEMS license with kamailio and rtpengine
>
>
>
> Hello,
>
> On 10.02.22 08:36, Henning Westerholt wrote:
>
> Hello,
>
>
>
> just to add to the discussion:
>
>
>
> 1. 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
>
> 2. 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
>
>
>
> I guess that the pre-compile is done by the luac, because Kamailio
> does not have such feature. Kamailio can only load a lua script (plain
> or pre-compiled) and push it as a parameter to liblua functions. In my
> opinion this is only file/data loading from kamailio point of view,
> definitely does not seem a linking/compile operation. It can be seen
> as something similar to reading SIP messages from the socket
> (everything is a file descriptor in unix/linux philosophy) and I
> assume nobody considers that received/sent SIP messages have to be GPL.
>
> From this perspective, none of the config files (no matter they are
> native scripting, lua, python, javascript, etc...) are forced to be
> GPL, it is the decision of the config author what's its license.
>
> Cheers,
> Daniel
>
>
>
> 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
>
> --
> 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/
--
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/20220210/9b0d85bb/attachment.htm>
More information about the sr-users
mailing list