[Pkg-clamav-devel] clamav 0.98.3 released

[Andreas Cadhalpun]

Hi Scott,

On 10.05.2014 17:57, Scott Kitterman wrote:
> On May 10, 2014 6:23:30 AM EDT, Andreas Cadhalpun <andreas.cadhalpun at googlemail.com> wrote:
>> 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.

OK, I trust your judgment here.

>> 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.

Yes, we should probably just open a ticket upstream asking to add 
license exceptions. Best would be if libclamav/conv.c and shared/cdiff.c 
(that also directly uses OpenSSL constructs) wouldn't do so.

> In my work as a Debian FTP Assistant I see far worse.

I can imagine that.

> 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.

Yes, so we can use OpenSSL now and switch to GnuTLS, once support for 
that is upstream.

Best regards,
Andreas