[sr-dev] Parsing of P-Preferred/Asserted-ID headers

[Daniel-Constantin Mierla]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20120817/75c441ab/attachment.htm>