[sr-dev] binary packages and OpenSSL

[Daniel Pocock]

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