Licence issues for libESMTP (and Balsa) - long (was Re: NTLM authentication)

[Brian Stafford <brian stafford uklinux net>]

On 2002.01.09 18:01:40 +0000 Carlos Morgado wrote:
> 
> On 2002.01.09 17:44:13 +0000 Brian Stafford wrote:
> 
> > 
> > However, now that I know more of what's going on in NTLM, I'm also working 
> > on an implementation of NTLM auth from scratch and using OpenSSL to provide 
> > the crypto code.  This will be released under the LGPL and OpenSSL's 
> > licence which is the normal libESMTP licence.  Watch this space.
> > 
> 
> here i see a problem. the same problem balsa (and loads of others) has now,
> in short debian won't ship it.
> in long, openssl is old-bsd which is not gpl compliant which means linking
> versus openssl is a liability. the openssl people defend that indeed there
> is no problem with openssl as it's a system library in most cases, but
> fairly openssl is no glibc ...

Hmmmm... this problem has been at the back of my mind for a while, so it has set me thinking.

Currently with libESMTP the OpenSSL licence is relevant if and only if the OpenSSL dependent features are enabled.  A pure LGPL libESMTP is available if configured with the --without-openssl option.  The only feature that actually *requires* it is the STARTTLS extension.  The CRAM-MD5 authentication module uses the OpenSSL routines when possible but replacement functions are provided so that the module is always built in any case.  My reasoning here is that OpenSSL is actively maintained, therefore it is preferred if available.

> so, yes we're stuck. what if brian goes with one of (l)gpl replacements ?

I presume you mean for the TLS libs ...

> most stuff still uses openssl so you end up with a bigger mess both link
> and code wise than before.

Agreed.  OpenSSL's ubiquity is a fairly compelling reason to use it, in that SMTP's TLS support is unlikely to be the only crypto an application is using.

Lately I've been watching the GNU TLS library which seems to be undergoing rapid development just now and which looks promising.  From what I've seen of the API it is cleaner than the OpenSSL one which suits my sense of aesthetics.  The downside is that it is GPL which is problematic for use within LGPL code (as I understand things).

If I adopt the GNU TLS code in place of OpenSSL, I'd probably need to change libESMTP's licence from LGPL to GPL.  That would likely please debian bods but it might lead to a code fork.  Commercial users (honest souls of the highest probity) will continue to use the older LGPL releases + OpenSSL.  If I didn't maintain the LGPL version someone else might step into the breach.  On the other hand, for NTLM authentication, it would eliminate the problem of using GPL code from Samba within an LGPL project.


Unfortunately as things stand at present, the licence on the generated binaries varies a bit with how libESMTP is configured.

1)	./configure --without-openssl
This yields a pure LGPL libESMTP with no STARTTLS support and no NTLM authentication.  CRAM-MD5 auth is still available.

2)	./configure --with-openssl
This yields a LGPL libESMTP supplemented by the OpenSSL licence with STARTTLS support and NTLM authentication.

Assuming I dual licence with GPL and LGPL depending on how the build is configured (shudder) and incorporate the new GNU TLS library support to provide STARTTLS support:

3)	./configure --with-gnutls
This yields a pure GPL libESMTP with STARTTLS support and NTLM authentication.

I really do not like this dynamic licence situation, even with just the first two scenarios.  I want libESMTP to be unambiguously pure LGPL regardless of how it is configured during the build.

There is a possible solution to all this which comes to mind and this approach has a certain degree of appeal to me.

Abstract the STARTTLS crypto and certificate support into a module which is dlopened.  The dlopened module could be linked against OpenSSL or GNU TLS.  Licensing issues are then restricted to the module.  An application might configure which STARTTLS support it wants, selecting the one corresponding to the crypto code it already uses.  The GNU TLS based module could be accompanied by a licence restricting its use to within GPL programs linking against libESMTP (if this is ncessary for dlopened modules - I've never been clear on this point).  Commercial users of libESMTP could still use the OpenSSL based implementation.

Incidentally, the NTLM authentication code is entirely contained in a dlopened module, so perhaps the GPL code from Samba is less of a problem than I first thought - licensing issues are the same as the above case.  As above, an alternative OpenSSL based module can be made available.

An obvious way for an app to influence which module gets loaded is to set the search path for the modules before loading them.  (I'm happy to write generic code where licensing issues are addressed by a usage convention but I really don't want to start writing code to enforce licences.)

Another reason the dlopening approach appeals is that of maintainance.  The STARTTLS support and NTLM authentication can and probably should be maintained as seperate projects.  I feel this is desirable given how tricky SSL/TLS and crypto code generally seems to be in any case.  Also, I can remove #ifdefs from the code.  STARTTLS protocol support is always there and is only active if the TLS module can be loaded - a low overhead run time decision made only if and when the server offers the STARTTLS extension!  If the module is not available, TLS support is not activated!

Perhaps there is a case to have Balsa use the same module interface to provide the crypto and certificate support needed for IMAP (and POP-3).  It might not take so much effort for both Balsa and libESMTP's requirements to crystallise into a module API; after all, the SMTP and IMAP STARTTLS and POP-3 STLS extensions all derive from the same set of RFCs.  There would also be a big payback in commonality of configuring the TLS support since it would all happen within the module.  Callbacks and APIs could interface the app's UI to the underlying mechanisms as is the case with libESMTP.  Alternatively a seperate app could be written to do this.

I suspect that this approach would solve the debian dilemma for apps or libs using it.  libESMTP would be unambiguously LGPL (Balsa unambiguously GPL) regardless of how configured when built and modules with iffy licences can be safely omitted from picky distributions.  I'd really appreciate some feedback on this concept from those who know about licensing and runtime dynamic loading.

Finally it would silence all those complaints like "why do my RPMs depend on libssl.so.0.9.er..umm" and so on which are always a bit of a headache for all concerned.

> 
> and then there is the small detail that openssl api sucks, the code is ugly,
> versioning is insane and subtle silent changes happen. oh well :)

Agreed ... well how could I disagree with that sentiment?  Why do you think the certificate code in smtp-tls.c is crap? ;)

Incidentally, its the lack of closure on the TLS code - e.g. finishing off the certificate management and peripheral issues - that is the major barrier to releasing a libESMTP 1.0.  The rest of the code seems solid enough and hasn't changed so much in the last 4 months or thereabouts.  The only experimental feature is ETRN, other than that, I feel that libESMTP is pretty much feature-complete.

-- best regards
Brian Stafford