Re: GNU TLS OpenSSL compatibility layer under GPL, not LGPL
Sean 'Shaleh' Perry [EMAIL PROTECTED] writes: According to the FSF, linking a GPL library is the equivalent of preparing a derived work. According to not just the FSF, linking a GPL library to something else *IS* the preparation of a derived work.
Re: GNU TLS OpenSSL compatibility layer under GPL, not LGPL
On Fri, Jan 17, 2003 at 03:05:04PM -0500, Jeff Licquia wrote: 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. Perhaps not directly. Who knows how many people who would otherwise be spending time on GPL software will instead be stuck porting free-but-GPL-incompatible software to use GNU TLS? I find that hard to justify. 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. I would appreciate seeing such a document. It seems GPL-compatibilty with SSL-enabled postgres libs will be an issue soon for me because of freeradius. -- Steve Langasek postmodern programmer pgprYESBtZkK6.pgp Description: PGP signature
Re: GNU TLS OpenSSL compatibility layer under GPL, not LGPL
On Sat, 2003-01-18 at 11:52, Steve Langasek wrote: On Fri, Jan 17, 2003 at 03:05:04PM -0500, Jeff Licquia wrote: I suppose it depends on whose resources are being wasted. Certainly the GNU project's resources aren't. Perhaps not directly. Who knows how many people who would otherwise be spending time on GPL software will instead be stuck porting free-but-GPL-incompatible software to use GNU TLS? I find that hard to justify. Well, this is the GNU project we're talking about. How much GPL-incompatible software do they distribute? 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. I would appreciate seeing such a document. It seems GPL-compatibilty with SSL-enabled postgres libs will be an issue soon for me because of freeradius. Once things settle down with CUPS, I might just start writing such a document. Of course, I won't mind if someone beats me to it. :-) Here's what I've learned so far: - SSL_library_init() and friends - gnutls_global_init(). - You have to create a credentials object to hold your credential info (we use X.509, these are our CAs, this is our cert, etc.). This is kind of like a SSL_CTX in OpenSSL, except that it's more loosely coupled. SSL objects are created from SSL_CTX objects, but gnutls_session objects are independent from credentials objects and can, in theory, communicate without them. - SSL_new() - gnutls_init() - SSL_connect() - gnutls_handshake() - SSL_read() - gnutls_record_recv() and SSL_write() - gnutls_record_send(). - SSL_shutdown() - gnutls_bye() - Errors are nicer. gnutls_perror() and gnutls_strerror() do pretty much what you think they'd do. The documentation on the GNU TLS page seem pretty good. They even include examples of both clients and servers at various sophistication levels.
Re: GNU TLS OpenSSL compatibility layer under GPL, not LGPL
On Saturday 18 January 2003 10:00, Steve Langasek wrote: On Sat, Jan 18, 2003 at 12:32:34PM -0500, Jeff Licquia wrote: Perhaps not directly. Who knows how many people who would otherwise be spending time on GPL software will instead be stuck porting free-but-GPL-incompatible software to use GNU TLS? I find that hard to justify. Well, this is the GNU project we're talking about. How much GPL-incompatible software do they distribute? None that I know of. Are you ascribing to the GNU project the position that if you're not one of us, we don't care what hoops you have to jump through, even if those hoops eat up time you would have spent working on GNU software? yes, see libreadline. *LOTS* of software would use it if it was not GPL.
Re: GNU TLS OpenSSL compatibility layer under GPL, not LGPL
On Sat, 2003-01-18 at 13:00, Steve Langasek wrote: On Sat, Jan 18, 2003 at 12:32:34PM -0500, Jeff Licquia wrote: Well, this is the GNU project we're talking about. How much GPL-incompatible software do they distribute? None that I know of. Are you ascribing to the GNU project the position that if you're not one of us, we don't care what hoops you have to jump through, even if those hoops eat up time you would have spent working on GNU software? Not as a general stereotype. But certain elements within it do feel this way, or at least put off that impression. Myopia is also possible. Anyone involved in a cohesive project can start to get tunnel vision; it happens to the best of us.
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 CUPS printing? 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 PROTECTED]
Re: GNU TLS OpenSSL compatibility layer under GPL, not LGPL
On Thursday 16 January 2003 02:50, Shaul Karl wrote: Can someone explain what is the problem with the following situation? In particular, why it is important here to have the OpenSSL layer relicense under the LGPL? According to the FSF, linking a GPL library is the equivalent of preparing a derived work. Thus if you link a GPL library your entire application becomes GPL. This means a GPL library is useless to many, many applications both free and proprietary.
Re: GNU TLS OpenSSL compatibility layer under GPL, not LGPL
Steve Langasek [EMAIL PROTECTED] writes: Hi Shaul, On Thu, Jan 16, 2003 at 12:50:57PM +0200, Shaul Karl wrote: Can someone explain what is the problem with the following situation? In particular, why it is important here to have the OpenSSL layer relicense under the LGPL? Think of the case of an LGPL library that wants to include SSL functionality. If it links against the GPLed GNU TLS layer, it cannot be used by GPL-incompatible apps, because the GPL requires the application to be distributed under the terms of the GPL; if it links against the OpenSSL libs, it cannot be used by GPL apps, which require the same thing of the libraries. There is a third option: Make the library use GNU TLS natively, without the OpenSSL compatibility layer. GNU TLS core is LGPL.
Re: GNU TLS OpenSSL compatibility layer under GPL, not LGPL
On Thu, Jan 16, 2003 at 05:40:47PM +0100, Simon Josefsson wrote: Steve Langasek [EMAIL PROTECTED] writes: Think of the case of an LGPL library that wants to include SSL functionality. If it links against the GPLed GNU TLS layer, it cannot be used by GPL-incompatible apps, because the GPL requires the application to be distributed under the terms of the GPL; if it links against the OpenSSL libs, it cannot be used by GPL apps, which require the same thing of the libraries. There is a third option: Make the library use GNU TLS natively, without the OpenSSL compatibility layer. GNU TLS core is LGPL. 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. And Debian is stuck in the middle. 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. -- Steve Langasek postmodern programmer pgpM1HYhgH7E5.pgp Description: PGP signature
Re: GNU TLS OpenSSL compatibility layer under GPL, not LGPL
On Thu, Jan 16, 2003 at 05:40:47PM +0100, Simon Josefsson wrote: There is a third option: Make the library use GNU TLS natively, without the OpenSSL compatibility layer. GNU TLS core is LGPL. This is just an argument that the compat layer doesn't need to exist at all, which is basically true; it exists to make switching from OpenSSL easier, not to make it possible. But it doesn't seem to be related to which license it should use. If it's useful for GPL apps, it'd be just as useful for (as Steve mentioned) LGPL libraries. -- Glenn Maynard
