<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
<br>
<div class="moz-cite-prefix">On 8/17/12 6:44 PM, Hugh Waite wrote:<br>
</div>
<blockquote cite="mid:502E74F2.9000500@crocodile-rcs.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Hello,<br>
<br>
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. [<a moz-do-not-send="true"
href="http://tools.ietf.org/html/rfc3325">RFC3325</a>]<br>
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.<br>
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.<br>
<br>
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/?<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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). <br>
<br>
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.<br>
<br>
<blockquote cite="mid:502E74F2.9000500@crocodile-rcs.com"
type="cite"> <br>
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.<br>
</blockquote>
<br>
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.<br>
<br>
For the sake of better clarification, just few notes about licensing
rules for core and some commonly used old modules (like tm/sl):<br>
- the developer will still be the copyright owner of the code,
but the license has to be BSD<br>
- 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
(<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/OpenSSL#Licensing">http://en.wikipedia.org/wiki/OpenSSL#Licensing</a>), 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<br>
- 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<br>
<br>
Cheers,<br>
Daniel<br>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - <a class="moz-txt-link-freetext" href="http://asipto.com/u/katu">http://asipto.com/u/katu</a>
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - <a class="moz-txt-link-freetext" href="http://asipto.com/u/kpw">http://asipto.com/u/kpw</a></pre>
</body>
</html>