On May 10, 2014 6:23:30 AM EDT, Andreas Cadhalpun <[email protected]> wrote: >Hi, > >On 10.05.2014 09:16, Sebastian Andrzej Siewior wrote: >> On Fri, May 09, 2014 at 08:13:27PM -0400, Scott Kitterman wrote: >>>> GnuTLS has a compatibility layer for OpenSSL [1]. Using this, it >might >>>> be possible to simply switch the headers. >>>> (We might get problems though: "Error handling is not thread >safe.") >>> >>> Since clamav is only using openssl functions internally, packages >that use libclamav >>> don't need the openssl exception. What they have is adequate for >being in Debian. >>> If they miss the exception in files where it should be, we should >file bugs upstream. >>> Given what is in the README, their intent is clear. >> >> Okay. So it is not a show stopper, good. I am only concerned because >a) the >> other deps on libclamav link against openssl and the crypto functions >are >> exported by libclamav. > >I'm a bit puzzled why it should be enough, if only clamav and not also >it's reverse-dependencies have an OpenSSL exception. > >In a recent thread on debian-devel [1] I found: >"[...] that this [linking with OpenSSL] induces a problem (for >Debian) for all GPL-without-OpenSSL-exception programs linked against >libcups2. As far as I understand our current stance on that problem, >GPL-licensed programs without an OpenSSL exception are absolutely >forbidden to link with it, even indirectly." > >And therefore cups switched back from OpenSSL to GnuTLS. >Am I missing something?
As I recall that discussion, cups was pretty directly exporting openssl functions in its own API. The clamav case is different because it's used internally only. You can't write a thin wrapper around a library and mask licensing issues, but equally, license issues don't inevitably propagate up the stack. I agree it's a tricky situation, but I think in this case it's fine. >>> I'd rather stick with what upstream is using and not switch to >GNUtls. >> >> No problem. I got from Shawn: >> |23:28 < lattera> bigeasy: mainly availability, openssl is >everywhere, also has API functions for planned enhancements to >freshclam >> |23:29 < lattera> but, we've wrapped all the functions we currently >use and the functions we plan to use later in libclamav/crypto.c, so if >> | you wanna switch it out for another crypto lib, you >just have to provide the same functions in your own crypto.c >> >> so it looks like he isn't against another library. Once we have the >release >> out I will try look at gnutls support and push it upstream. > >I fear we have to do that for this release, but, as said, I'm no expert > >in legal matters. > >About missing exceptions in many files, most of them have: >#include <openssl/ssl.h> >#include <openssl/err.h> >#include "libclamav/crypto.h" > >From my point of view, it would have made more sense to put the OpenSSL > >includes in crypto.h, because one can't use it without also including >these OpenSSL headers, as some function parameters have types defined >in >the OpenSSL headers. > >As it is, I'm not sure if these files need an OpenSSL exception. > >But there is also libclamav/conv.c, which has no OpenSSL exception, but >has: >#include <openssl/bio.h> >#include <openssl/evp.h> > >This one definitely needs an OpenSSL exception (at least I think so). Because the exception is included in the README, I think it's reasonable to believe they meant the exception to apply globally. On that basis, I would treat any missing declarations as bugs to be fixed, not licensing incompatibilities that make the result undistributable. In my work as a Debian FTP Assistant I see far worse. I believe what they did is alright, although not ideal. Fortunately, they are open to patches to integrate with GNUtls, so this can be a temporary concern. Scott K _______________________________________________ Pkg-clamav-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-clamav-devel
