Re: GNU TLS OpenSSL compatibility layer under GPL, not LGPL
On Thu, 2003-01-16 at 11:56, Steve Langasek wrote:
> While true, this doesn't address the fundamental complaint that the
> licensing of the OpenSSL compatibility layer renders it worthless for
> most applications. The ironic result is that those who write
> GPL-compatible software are free to use the older APIs that are
> historically associated with GPL-incompatible code; and those who write
> GPL-incompatible software, free or not, must choose between using
> libraries that are wholly GPL-incompatible, or using libraries with a
> learning curve.
This could be interpreted as a subtle promotion of the GPL (and
compatible licenses). The requirement to port, under this theory, is
like a "tax" on incompatibly licensed projects.
In my case, though, it backfired. There is no incompatibility between
CUPS and the GPL in and of itself, but upstream has a strong vested
interest in not losing the additional privileges of the LGPL on the CUPS
libraries. To them, even accepting the patch to *allow* this
configuration made too many implied statements. So, they felt obligated
to reject the patch and continue to force people to use OpenSSL for
encrypted communications. This puts GPLed projects in a quandary: write
an OpenSSL exception to their license, or forego better integration with
Fortunately, this case ends on a happy note. I got fed up with the
issues and ported CUPS to the native GNU TLS API, and upstream has
accepted the patch. It will show up in 1.1.19 (and possibly 1.1.18-3
and following in Debian).
> Sure, code can be rewritten to use gnutls natively. But I don't
> understand why anyone would consider this a useful expenditure of
> developer resources when the necessary OpenSSL compat glue could simply
> be made available under the LGPL.
I suppose it depends on whose resources are being wasted. Certainly the
GNU project's resources aren't.
FWIW, porting to the native API didn't turn out to be difficult. If the
GNU TLS project doesn't bend on the licensing issue, it might behoove us
to write a Porting HOWTO, or some such.
Jeff Licquia <email@example.com>