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]
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