Re: [libesmtp-devel] Licence issues for libESMTP (and Balsa) - long (was Re: NTLM authentication)

[Carlos Morgado <chbm chbm nu>]

On 2002.01.09 23:29:14 +0000 Brian Stafford wrote:
> 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.
> 

 From what i remember of the LGPL linking libesmtp with openssl wouldn't
be a problem. The LGPL separates linking from actual code as oposed to the
GPL that focus on the final runtime image. So, a libESMTP linked against
OpenSSL image is not considered a derivate work of libESMTP.
Linking libesmtp+openssl with a gpl program *might* be a problem though.
(the original one)

> > so, yes we're stuck. what if brian goes with one of (l)gpl replacements ?
> 
> I presume you mean for the TLS libs ...
> 
gnuTLS and Mozilla's NSS. gnuTLS is GPL proper, NSS is dual license MPL/GPL.
NSS is TooBig though cause it's a chunk with all the crypto related stuff
mozilla needs.

> > 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).
> 

I think it's legal to link gpl and lgpl code. The resulting product is
governed by the GPL as it is the more restrictive license.

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

If in doubt dual license it. Release libESMTP under both LGPL and GPL, that
way the license governing the distributed binaries is defined by what you
link libesmtp against.
The LGPL is upgradable to GPL but it's a managing pain.

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

As i said, I don't think openbsd taints a lgpl binary

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

This looks like a good scenario to me :)

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

Well, you can still make libESMTP just LGPL and use gnuTLS but that will
make for some confusion as despite libESMTP is LGPL, binary kits might
be GPL. In practice the situation is the same as the dual license scenario
but less evident

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

I don't consider dlopen to be diferent from runtime linking as it yelds a
runtime image just the same. The GPL doesn't split straws on this point so
I just consider, if I make the application dump core at some point what do I
get ?
Imho this dlopen scenario is even muddier than the single license scenario
as the license governing the final product will not only depend on the license
of all the configured modules but also of something that is decided on run 
time.
pooh

[snip]
> 
> 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.
> 

True.

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

As said, the dlopen approach doesn't solve license conflicts imho. In light
of that i'm not so sure about the benefits of dlopen over compile time 
linking,
even considering the runtime functionality of choosing what crypto module to
use must be moved to ./configure

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

mutt has some NSS support but I think it's somewhat bitroted and afaik noone
even tries to make it work on balsa. From I understand from previous 
discussions on mutt-dev they are open to cleaning up nss or adding gnuTLS
support if some volunteers :)
For balsa, NSS has some advantages as I suspect most balsa users have mozilla 
:)
but NSS is so large i tend to like gnuTLS better.

[snip]

For the record, I have 0 copyright over libESMTP so what was said above are
points of view from an interested bystander :)

cheers

-- 
Carlos Morgado - chbm(at)chbm(dot)nu - http://chbm.nu/ -- gpgkey: 0x1FC57F0A
http://wwwkeys.pgp.net/ FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A
Software is like sex; it's better when it's free. - Linus Torvalds