9 Feb
2022
9 Feb
'22
7:23 a.m.
Hello Daniel,
You are right - I should have used "parts of the core" in my earlier e-mail.
Some parts are BSD licences, some are of course GPLv2 (or later).
Cheers,
Henning
-----Original Message-----
From: Daniel-Constantin Mierla <miconda(a)gmail.com>
Sent: Wednesday, February 9, 2022 1:20 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>rg>; Henning
Westerholt <hw(a)gilawa.com>
Subject: Re: [SR-Users] SEMS license with kamailio and rtpengine
Hello,
there is some erroneous information that Kamailio core uses another, more permissive
licence than GPLv2. It is actually GPLv2 (or newer) for most of its code, as you can note
at the top of old files there.
Probably the confusion came from the fact that is required since 2008 to make
contributions to core under BSD, but because there was (and still
is) a lot of prior GPLv2 code, all together, the core still has to follow the GPLv2 rules.
One can extract parts of the core and those can be BSD, indeed.
The requirement to make core (and a few other major modules, iirc, tm, sl, tls)
contributions under BSD came practically from the issue with bundling GPL code with some
other (maybe not fully compliant) OSS licenses such as it was the case of openssl license
at that time.
If one wants to add (valuable) GPL code can add it in a module and the core can get some
hooks to call the code when needed. The rule tried to avoid future situations when some
past developers are gone and we would need their agreement for packing core and main
module with some libraries.
Cheers,
Daniel
On 09.02.22 13:02, Henning Westerholt wrote:
Hello,
This is also discussed in detail in the GPL FAQ [1]. Generally speaking - if you combine
"closely" GPL v2 and proprietary code, the result needs to be also GPLv2. So,
your example would not work from a licence point of view for proprietary licensing.
In the Kamailio case you could do the following: combine the core (which uses another,
more permissive licence) only with proprietary modules. This would be ok from a licence
point of view, but of course not really practical.
Cheers,
Henning
[1]
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggrega
tion
--
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 12:24 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] SEMS license with kamailio and rtpengine
--
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/
On Feb 9, 2022, at 2:40 AM, Olle E. Johansson
<oej(a)edvina.net> wrote:
Since you did open the topic: I thought that custom Kamailio modules can be exempt
from this, provided they are truly self-contained modules and not more invasive source
code modifications, based on the theory of the “loose-coupled” aggregate?
I know this is a vague and risky idea, since ultimately someone has to make a judgment
about whether a Kamailio module meets the standard of self-containment and loose coupling
that the GPL has in mind.
On the one hand, a custom module would be compiled into a separate ELF reloadable object
and loaded separately. On the other hand, it can hardly be said to be an outside service
communicating to the core program through strictly confined channels such as pipes or
sockets or RPC API endpoints, instead practically sharing memory and a large number of
data structures from the core program or its other [GPL-licensed] modules.
Still, a custom module is, in the Kamailio way of doing things, practically
self-contained as a matter of code. Modules under a proprietary license are, from what I
understand of the GPL, foreseen and permitted.
Regardless, I do agree strongly that this is generally the wrong way
to do things, born first and foremost of a kind of grandiose delusion
of “unique” requirements or top-secret formulas. :-)
— 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
On 9 Feb 2022, at 08:20, Juha Heinanen
<jh(a)tutpro.com> wrote:
In case of SEMS and Kamailio the added value a company can provide
on the free source code is on how it is configured (Kamailio) or
what kind of applications have been written using it (SEMS).
Exactly.
With Kamailio you can do almost anything in the configuration, especially now that we
have KEMI.
But there are still old-fashioned managers out there that think
- they’re solution is UNIQUE
- they have to modify the source and keep the changes
- they have to write a kamailio module in C for their unique business
logic
In most cases all these assumptions are wrong.
If you do modify the source or add your own module and distribute it, you are likely
going to have GPL issues. Don’t go down that rabbit hole.