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

[Brian Stafford <brian stafford uklinux net>]

On Thu, 10 January 11:53 Carlos Morgado wrote:

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

Seems reasonable

> Linking libesmtp+openssl with a gpl program *might* be a problem though.
> (the original one)

Yep!  This is the scenario that I am uncertain about.  As I understand it, the 
GPL allows for programs to be linked against the proprietary system libraries 
distributed with unixes.  Would the openssl libs fall into the proprietary 
system libraries category?

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

OK

> NSS is TooBig though cause it's a chunk with all the crypto related stuff
> mozilla needs.

Odd, I know about NSS yet I never for a moment considered using it!  I guess I 
must instinctively expect Netscape code to be bloatware :)

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

That's what I think too :)

[snip]

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

Noted.

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

This might be a useful way to think about the situation.

> 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

Noted.  I guess a similar situation crops up for some of the authors over on 
the linux-audio-dev list.  There, they are faced with a problem of a GPL app 
and whether it should support loading commercial plugins such as Cubase VST 
effects.  Maybe I should ask over there.

[snip]

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

Thanks for the commentary Carlos, its all very helpful insight.

--
Brian