Hi Scott,
On 10.05.2014 17:57, Scott Kitterman wrote:
On May 10, 2014 6:23:30 AM EDT, Andreas Cadhalpun
<[email protected]> 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
_______________________________________________
Pkg-clamav-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-clamav-devel
