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

[Matthias Andree <ma+balsa dt e-technik uni-dortmund de>]

Brian, your domain is hosed: localhost.localdomain is in your
Message-ID. Please take the time to work around my duplicate filter and
avoid collisions.

On Wed, 09 Jan 2002, Brian Stafford wrote:

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

Without doing into dynamic link detail issues which are always prone to
portability issues as well and take one or another excluded platform,
one way might be to persuade the GNU people to release their stuff as
LGPL. After all, the reasoning for LGPL has always been and still is (as
per http://www.gnu.org/philosophy/why-not-lgpl.html) to license
non-exclusive material: "There are reasons that can make it better to
use the Library GPL in certain cases. The most common case is when a
free library's features are readily available for proprietary software
through other alternative libraries. In that case, the library cannot
give free software any particular advantage, so it is better to use the
Library GPL for that library." [ibidem]

Since OpenSSL is a strong competitor to GNUTLS, it may be best to talk
the copyright holders into degrading their GNUTLS license to LGPL --
that will make it an even stronger competition for OpenSSL, and in the
end, both may profit from that licensing change.

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

Your reasoning looks sound. However, dynamic linking, as written above,
is prone to portability issues, especially when it comes to dlopen.
Choose for yourself if you want to take the extra maintenance work to
get the stuff portable to every platform that Debian and NetBSD cover,
and to the commercial unices found on desktops or servers, Solaris,
IRIX, HP-UX, AIX, BSDI, to name the first ones that come to my mind.

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

When you say ETRN, you must also say ODMR (ATRN). Check RFC-2645. :^)
Just to prevent you from running out of feature requests. :-)

(sorry for not keeping flowed formatting, too lazy to reconfigure mutt
and vim ;)

-- 
Matthias Andree

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."         Benjamin Franklin