From andrew at mcdonald.org.uk Thu May 16 21:56:01 2002 From: andrew at mcdonald.org.uk (Andrew McDonald) Date: Thu May 16 21:56:01 2002 Subject: [gnutls-dev]GPL/LGPL license changes Message-ID: <20020516195636.GB680@mcdonald.org.uk> Hi, I notice that gnutls (and libgcrypt) have (very) recently changed licenses from GPL to LGPL. I've a few queries about the new gnutls license. As I understand it libgnutls is now LGPL, unless it is built with SRP or OpenPGP support, in which case it is GPL. I guess that one consequence of this is that any application can use gnutls (where they might have used OpenSSL before), but only get the 'extra features' of gnutls when they are GPL licensed (and opencdk is still GPL licensed anyway). However, it seems to me that if a user has the GPL version installed then they can only run GPL'ed applications that link with gnutls. (Whereas if the LGPL version is installed then any applications under any license linking to gnutls can be installed). It means that you can't have a GPL'ed application using OpenPGP keys at the same time as another application (using basic TLS) under a GPL-incompatible license. Was this intended? If no, one solution would be to have different SONAMES for the GPL and LGPL versions, but that seems undesirable. Alternatively, I'm wondering if the GPL bits could be moved to an auxilary library. A GPL'ed app could then link with libgnutls and libgnutls-extra to be able to use SRP and OpenPGP. Any thoughts? I guess an application can detect OpenPGP support at run time through by calling one of the _openpgp_ functions and SRP through one of the _srp_ functions. However, would it be useful to have a more formalised way of doing this? Also, is there a way to detect at compile time whether SRP or OpenPGP support is available? Sorry it's such a long e-mail. Regards, Andrew -- Andrew McDonald E-mail: andrew at mcdonald.org.uk http://www.mcdonald.org.uk/andrew/ From wk at gnupg.org Fri May 17 08:49:01 2002 From: wk at gnupg.org (Werner Koch) Date: Fri May 17 08:49:01 2002 Subject: [gnutls-dev]GPL/LGPL license changes In-Reply-To: <20020516195636.GB680@mcdonald.org.uk> (Andrew McDonald's message of "Thu, 16 May 2002 20:56:36 +0100") References: <20020516195636.GB680@mcdonald.org.uk> Message-ID: <87elgbb72f.fsf@alberti.gnupg.de> On Thu, 16 May 2002 20:56:36 +0100, Andrew McDonald said: > if the GPL bits could be moved to an auxilary library. A GPL'ed app > could then link with libgnutls and libgnutls-extra to be able to use > SRP and OpenPGP. Any thoughts? That is the cleanest approach. > I guess an application can detect OpenPGP support at run time through > by calling one of the _openpgp_ functions and SRP through one of the On ELF systems weak linking can be used to replace the standard initialization function in the gnutls-extra lib. One can also do autoconf magic to call the right initialization function. Same goes for a function to learn about the supported extensions. > way of doing this? Also, is there a way to detect at compile time > whether SRP or OpenPGP support is available? gnutls-config should be able to provide this. Werner From nmav at gnutls.org Fri May 17 11:35:02 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Fri May 17 11:35:02 2002 Subject: [gnutls-dev]GPL/LGPL license changes In-Reply-To: <20020516195636.GB680@mcdonald.org.uk> References: <20020516195636.GB680@mcdonald.org.uk> Message-ID: <20020517093516.GA9456@gnutls.org> On Thu, May 16, 2002 at 08:56:36PM +0100, Andrew McDonald wrote: > Hi, > As I understand it libgnutls is now LGPL, unless it is built with SRP > or OpenPGP support, in which case it is GPL. I guess that one > consequence of this is that any application can use gnutls (where they > might have used OpenSSL before), but only get the 'extra features' of > gnutls when they are GPL licensed (and opencdk is still GPL licensed > anyway). yes, this is the intention. > However, it seems to me that if a user has the GPL version installed > then they can only run GPL'ed applications that link with gnutls. > (Whereas if the LGPL version is installed then any applications under > any license linking to gnutls can be installed). It means that you > can't have a GPL'ed application using OpenPGP keys at the same time as > another application (using basic TLS) under a GPL-incompatible license. > Was this intended? No. I'm still working on it. > If no, one solution would be to have different SONAMES for the GPL and > LGPL versions, but that seems undesirable. Alternatively, I'm wondering > if the GPL bits could be moved to an auxilary library. A GPL'ed app > could then link with libgnutls and libgnutls-extra to be able to use > SRP and OpenPGP. Any thoughts? Looks like a nice solution. > I guess an application can detect OpenPGP support at run time through > by calling one of the _openpgp_ functions and SRP through one of the > _srp_ functions. However, would it be useful to have a more formalised > way of doing this? Also, is there a way to detect at compile time > whether SRP or OpenPGP support is available? I've just added the --modules option to libgnutls-config which now prints the enabled modules. I may remove this, if I finally split the library. > Regards, > Andrew > -- > Andrew McDonald > E-mail: andrew at mcdonald.org.uk > http://www.mcdonald.org.uk/andrew/ -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From nmav at gnutls.org Mon May 20 13:19:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Mon May 20 13:19:01 2002 Subject: [gnutls-dev]gnutls split Message-ID: <20020520111826.GA11745@gnutls.org> Having considered the license issues, I've finally decided to split the library in two parts. The LGPL part (gnutls) and the GPL part (gnutls-extra). The split is almost complete and lies in the CVS. Please test the cvs, and notify me in case something wicked happened. -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From simon+gnutls-dev at josefsson.org Mon May 20 13:48:01 2002 From: simon+gnutls-dev at josefsson.org (Simon Josefsson) Date: Mon May 20 13:48:01 2002 Subject: [gnutls-dev]Re: gnutls split In-Reply-To: <20020520111826.GA11745@gnutls.org> (Nikos Mavroyanopoulos's message of "Mon, 20 May 2002 14:18:26 +0300") References: <20020520111826.GA11745@gnutls.org> Message-ID: Nikos Mavroyanopoulos writes: > Having considered the license issues, I've finally decided to split the > library in two parts. The LGPL part (gnutls) and the GPL part (gnutls-extra). > The split is almost complete and lies in the CVS. > > Please test the cvs, and notify me in case something wicked happened. Seems to work here. What was the reasons for the license change? From nmav at gnutls.org Tue May 21 14:20:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue May 21 14:20:01 2002 Subject: [gnutls-dev]gnutls 0.4.2 Message-ID: <20020521121949.GA8508@gnutls.org> I've just released the 0.4.2 version of gnutls. The news in this release are: - Relicensed the library under the GNU Lesser General Public License - Added gnutls-extra library which contains the GPL covered code of gnutls. - Separated ASN.1 structures parser documentation and TLS library documentation. - Added gnutls_handshake_set_rsa_pms() function, which disables the version check in RSA premaster secret. - Added gnutls_session_is_resumed() function, which reports if a session is a resumed one. - Added gnutls_state_set_ptr() and gnutls_state_get_ptr() functions, to assist in callback functions. - Replaced the included 1024 bit prime for Diffie Hellman, with a new random one. -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From nmav at gnutls.org Wed May 22 21:36:01 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Wed May 22 21:36:01 2002 Subject: [gnutls-dev]memory allocation Message-ID: <20020522193616.GC15507@gnutls.org> I've just noticed that in benchmarks using the libc's allocation functions, instead of the included gnutls_malloc() made gnutls about 20% faster. Due to this, and due to the fact that the included allocation functions did not much except for overwriting memory pointers (which is not really reliable), I've removed these functions, and used the libc's ones. I've also added the gnutls_global_set_mem_func() which is to set other memory allocation functions. Thus if one needs to rely on the memory allocation functions to delete sensitive data, then he may just use the ones included in libgcrypt, which are considered to be secure (but slower). -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org From nmav at gnutls.org Thu May 23 21:35:02 2002 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Thu May 23 21:35:02 2002 Subject: [gnutls-dev]gnutls 0.4.3 Message-ID: <20020523193400.GA7693@gnutls.org> I've just released gnutls 0.4.3. This version corrects a compilation bug, and some other bug fixes. Also the memory handling has changed. - The gnutls-extra library now compiles fine, if the opencdk library is not present. - Several bug fixes. - Added gnutls_global_set_mem_func() function, to set the memory allocation functions, if other than the defaults are to be used. - The default memory allocation functions are now the ones in libc. -- Nikos Mavroyanopoulos mailto:nmav at gnutls.org