Thanks all now I understand better.
to @Daniel-Constantin Mierla <miconda(a)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(a)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(a)evaristesys.com>
<abalashov(a)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(a)gilawa.com>
<hw(a)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#IfInterpreterIsG…
Cheers,
Henning
--
Henning Westerholt –
https://skalatan.de/blog/
Kamailio services –
https://gilawa.com
*From:* sr-users <sr-users-bounces(a)lists.kamailio.org>
<sr-users-bounces(a)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(a)lists.kamailio.org>
<sr-users(a)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(a)gmail.com>om>:
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(a)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(a)lists.kamailio.org> On Behalf Of Alex
Balashov
Sent: Wednesday, February 9, 2022 1:50 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] SEMS license with kamailio and rtpengine
On Feb 9, 2022, at 7:46 AM, Henning Westerholt
<hw(a)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(a)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(a)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(a)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(a)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(a)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.comwww.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/
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)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