Please test :)
David Shaw
dshaw at JABBERWOCKY.COM
Tue Aug 25 21:03:55 CEST 2009
On Aug 25, 2009, at 8:45 AM, Werner Koch wrote:
> On Mon, 24 Aug 2009 03:46, dshaw at jabberwocky.com said:
>
>> which is what is linked with the keyserver helpers. My notes say we
>> split libcompat and libutil in 2006 for licensing reasons, as the
>> keyserver helpers might be linked with OpenSSL, which is not GPL
>
> Right, I forgot about this.
>
>> Now, it would be possible to move the tilde expanding code to
>> libcompat (or even just implement things slightly differently), but I
>
> Yeah we should do that: Add the exception to gnupg14/util/fileutil.c
> and make sure that it does not need other stuff from util/ .
Alas, it does. It pulls in the memory allocation code (xmalloc and
friends). We could fairly easily make a ~ expander that doesn't use
the other code though. It's a shame we can't just use wordexp().
> Actually, I forgot about this problem while porting the keyserver code
> to GnuPG-2, or assumed that OpenSSL is not used. Those who distribute
> GnuPG-2, need to take care of the license, meaning to use gnutls,
> yaSSL
> or another GPL compatible SSL library. In particular gnutls is a good
> choice because gnutls uses libgcrypt which is a requirement for GnupG
> anyway.
I worry this might be a excessive burden in some places. It basically
means that if a distribution builds Curl with OpenSSL, that
distribution must build GnuPG without Curl. Since Curl defaults to
building with OpenSSL, and GnuPG-2 defaults to building with Curl,
that requires the distribution builder to know about this potential
license conflict and override the defaults somewhere in the GnuPG-2-
>Curl->OpenSSL chain.
I don't know how many distros fall into this category (I do know that
Fedora is okay here), but any distro that follows the defaults will.
David
More information about the Gnupg-devel
mailing list