On Fri, Jan 23, 2009 at 7:25 PM, Sylvain Beucler <[email protected]> wrote: > Anyway, my aim though was essentially pointing at 'libcurl3-gnutls' or > 'libneon27-gnutls' which means GPL projects can use libcurl or libneon > *with* SSL enabled without problem. I probably should have looked at > the projects homepages to see if this was an upstream (development) or > downstream (linking) improvement :) > Well, for the GiVMI project would python-gnutls suffice? http://pypi.python.org/pypi/python-gnutls/1.0.2 > > >> but there should be no reason to reject a project on the >> basis that it links against OpenSSL (provided that the exception is in >> place, and is valid taking into account other runtime dependencies, of >> course). IMVHO. > > Note that it's still preventing the project from using GPL'd > libraries, hence enticing submitters to request LGPL'd or BSD'd > replacements. So I think GnuTLS needs to be recommended in all > situations. > Well what about the claimed dependencies on Qemu and KVM? I have no idea where the pygtkvnc library is.
If the maintainer does go with the openssl, should there be a exception in the license notice? Would the exception that openssl.org FAQ suggests be good enough? "This program is released under the GPL with the additional exemption that compiling, linking, and/or using OpenSSL is allowed." -- Nicodemo Alvaro
