Re: [sr-dev] binary packages and OpenSSL

Just some further thoughts on the problems facing binary packages with TLS support I don't know the TLS code in any detail at all, but to what extent could it be split into a standalone binary module?

Here is the possible solution: - single source package (kamailio.tar.gz) or maybe even separate source - TLS-related files in a subdirectory for building a module - TLS-related files re-licensed under BSD terms - compiling and running core doesn't require the TLS source or binary When uploading to Debian, Fedora, etc, there would be two artifacts: kamailio-core.deb (GPL license) kamailio-tls.deb (optional, BSD licensed, depends: openssl) It then becomes possible for users who want TLS support to just do # apt-get install kamailio kamailio-tls or something like that. The challenges: - ensuring that the low-level TLS support (any code that uses OpenSSL API) can be separated into a module - ensuring that any previous contributors on the affected code are happy to have it re-licensed Of course, solving the first challenge (separating the low level code) probably brings the project closer to having adaptable support for GnuTLS in future. I realise that TLS is intricately tied up in the SIP protocol (e.g. inserting proper transport parameters in Via headers, sips URI, ...), but the licensing problem really only kicks in where the OpenSSL API is used. As long as there is an abstraction layer and the high-level code doesn't use OpenSSL API directly, this may not be difficult to solve. Regards, Daniel _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev