17 Aug
2012
17 Aug
'12
8:39 p.m.
Hello,
On 8/17/12 6:44 PM, Hugh Waite wrote:
Hello,
The current kamailio devel supports a single P-Asserted-ID or
P-Preferred-ID header value, but the RFC allows one or two either in
one or two headers. [RFC3325 <http://tools.ietf.org/html/rfc3325>]
I am most of the way through coding a fix, but Daniel's comment about
kamailio module licensing has prompted me to wonder about why
parse_ppi/pai is in lib/kcore.
The dev-guide says new headers should be put in parser/parse_xxx.[ch],
but I wasn't going to change the location unless something forces me to.
Is there any guidance on whether I should leave the parse_pai/ppi
files in /lib/kcore or if they should be placed with other files in
/parser/?
lib/kcore hosts the code that existed in kamailio 1.5 core that didn't
met the 'new' licensing requirements: core with code GPL owned by FhG
(i.e., code from initial SER project, eventually with additions that
didn't change it) or BSD.
It is recommended that new parsing code to be added in the core, but we
don't force developers to make their code BSD. They can make it GPL and
add in a module or library.
I see parse_pai/ppi are written by Juha, maybe he considers switching
them to BSD and then the code can be moved in core parser. I moved my
code that way and also some code written by Andreas Graning, based on a
discussion with him where he agreed to make it BSD (noted in commit
message, iirc, related).
Initially kcore was intended as temporary container for the code whose
licensing couldn't be sorted out, not to lose time during the merging.
Then we were supposed to approach the developers that could be still
reachable and get to a decision, by moving to core or to a more
appropriate library. But the spare time was not that much in my side to
look at all the code there.
For information, my change extends the $ai, $pd, $pu, $pn and $pU
psuedo variables so they can be accessed with an index (e.g. $ai[0]
and $ai[1]) for the first and second instances of the header values,
whether they occur on one header (comma separated) or on two headers.
Existing usage will not be changed as $ai will continue to return the
first instance.
At the moment, you can code in kcore, not really being a new header
parser, but enhancements to existing one. Then I guess pv module needs
updates as well.
For the sake of better clarification, just few notes about licensing
rules for core and some commonly used old modules (like tm/sl):
- the developer will still be the copyright owner of the code, but
the license has to be BSD
- one of the main the reason for BSD is that GPL gives headaches
with open source distributions in some cases. For example at this moment
is with libssl linked modules (mainly enforced by Debian), which would
require an exception agreement for all developers along the time that
contributed gpl licensed code
(http://en.wikipedia.org/wiki/OpenSSL#Licensing), but some of them are
unreachable. In the future could be other cases. Core is supposed to be
just the common framework, not the business side of the development.
Hooks can be added in core as BSD and the business coded as module under
GPL (if intended to be made public and pushed to project's git repo) or
what so ever gpl-compatible license if kept inhouse
- in (few) cases during the past years popped up kind of
conflictual atmosphere regarding some patches, considered small by
initial developer not to add to copyright, but relevant by the
contributor. Since core cannot be forked like a module to a new
(alternative) one, BSD which is very libertarian should avoid such
situations
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw