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

[Carlos Morgado <chbm chbm nu>]

On 2002.01.10 13:11:04 +0000 Matthias Andree wrote:
> On Thu, 10 Jan 2002, 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.
> > Linking libesmtp+openssl with a gpl program *might* be a problem though.
> > (the original one)
> 
> Which would then originate from the OpenSSL's license advertising
> clause.
> 

Indeed. old style bsd license is not gpl compatible.

> > As i said, I don't think openbsd taints a lgpl binary
> 
> OpenSSL has an advertising clause which may later become a problem.
> Effectively, you'd probably not be able to link GPLed stuff against
> OpenSSL.
> 

Yes. This would not be a problem for libESMTP as it is LGPL and old-bsd
is LGPL compatible (well, LPGL is compatible with mostly anything)
The catch here is you have loads of GPL code linking against OpenSSL.
This might be considered a legacy problem from the days when there were
no alternatives to openssl. There are currently 3 ways around this:
. having the copyright holders of the GPL app add a clause permiting
  this
. considering OpenSSL a 'system library' (the point used by the OpenSSL
  authors)
. not shipping binaries linked against openssl

Some time ago Debian noted mutt uses openssl. After some discussion the
first aproach was considered impractical and as it stands Debian doesn't
give openssl the status of 'system library'. I share this opinion as
openssl is neither irreplacable or fulcral.
The system lib exception on GPL is there to allow GPL programs on non open
OSs, not non open apps on open OSs. Imho the OpenSSL authors are abusing
the GPL in order to promote their product. Conclusion, Debian opted for not 
distributing mutt binaries linked against
OpenSSL. This decision goes for any GPL app that uses OpenSSL.

The point here is not 'using' but distributing binary kits. You may use
OpenSSL on a GPL app, write code hooks for it etc. The user may link
that app against openssl. You just can't distribute images of that program
that link against openssl at runtime.

> > 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.
> 
> May I refer you to discussions on the Linux-Kernel mailing list
> when it comes to binary-only modules, some insight may be drawn from
> there.

LK is a special case as Linus decided on an 'exception' for binary modules.
Note the new MODULE_LICENSE system that hides symbols from non gpl modules.
Also, please note that if you distributed a dump of the image of a running
kernel with non free modules inserted you're violating the GPL. This is
was the primary reason for Linus oking binary modules - providers of non
free modules will provide binary images of the modules alone, not prelinked.

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