> On 10 Feb 2022, at 09:01, Daniel-Constantin Mierla <mico...@gmail.com> wrote: > > Hello, > > On 10.02.22 08:36, Henning Westerholt 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 >> <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 >> >> <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. > I suggest that we formally clarify this just to avoid any misunderstandings, much like we did in Asterisk.
/O > 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-boun...@lists.kamailio.org> >> <mailto:sr-users-boun...@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@lists.kamailio.org> >> <mailto:sr-users@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 <dujinf...@gmail.com >> <mailto:dujinf...@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 <h...@gilawa.com >> <mailto:h...@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/ <https://skalatan.de/blog/> >> Kamailio services – https://gilawa.com <https://gilawa.com/> >> >> -----Original Message----- >> From: sr-users <sr-users-boun...@lists.kamailio.org >> <mailto:sr-users-boun...@lists.kamailio.org>> On Behalf Of Alex Balashov >> Sent: Wednesday, February 9, 2022 1:50 PM >> To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org >> <mailto:sr-users@lists.kamailio.org>> >> Subject: Re: [SR-Users] SEMS license with kamailio and rtpengine >> >> >> > On Feb 9, 2022, at 7:46 AM, Henning Westerholt <h...@gilawa.com >> > <mailto:h...@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.evaristesys.com/>, >> http://www.csrpswitch.com/ <http://www.csrpswitch.com/> >> >> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> * sr-users@lists.kamailio.org <mailto:sr-users@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 >> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> * sr-users@lists.kamailio.org <mailto:sr-users@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 >> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> >> >> >> -- >> About: http://about.me/dujinfang <http://about.me/dujinfang> >> Blog: http://www.dujinfang.com <http://www.dujinfang.com/> >> Proj: http://www.freeswitch.org.cn <http://www.freeswitch.org.cn/> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> * sr-users@lists.kamailio.org <mailto:sr-users@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 >> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> >> >> >> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> * sr-users@lists.kamailio.org <mailto:sr-users@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 >> <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/ > <https://www.asipto.com/sw/kamailio-advanced-training-online/>__________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > * sr-users@lists.kamailio.org <mailto:sr-users@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 > <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@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
