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(a)lists.kamailio.org> *On Behalf
Of *Seven Du
*Sent:* Saturday, February 12, 2022 1:37 AM
*To:* Daniel-Constantin Mierla <miconda(a)gmail.com>om>; Kamailio (SER) -
Users Mailing List <sr-users(a)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@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>
<mailto:abalashov@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> <mailto:hw@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/
<https://skalatan.de/blog/>
Kamailio services –
https://gilawa.com
<https://gilawa.com/>
*From:* sr-users <sr-users-bounces(a)lists.kamailio.org>
<mailto:sr-users-bounces@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>
<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
<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.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(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
Other:
http://rts.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:
*