Comment 13 for bug 26452

Package: netatalk
Version: 1.6.4-1
Followup-For: Bug #191790

After a long and heated discussion on debian-legal, I concluded that
indeed it is not possible to combine OpenSSL and netatalk. In short: if
netatalk is linked against OpenSSL, the combination of the two is
considered a combined program, which must be under the same licence. The
OpenSSL and GPL are unfortunately incompatible (GPL does not allow the
additional restriction that you MUST add the acknowledgement "This
product includes software developed by the OpenSSL Project for use in
the OpenSSL Toolkit"). I still think it is odd, since both are open
source and the binary of netatalk does NOT include any OpenSSL code (it
is dynamically linked). However, after 48 mails, even *I* got the point
;-)

I got an interesting suggestion though: link netatalk with GnuTLS
instead of OpenSSL. GnuTLS is OpenSSL-redone-from-scratch (also open
source, but now GPL-compatible), just to avoid this small
incompatibility thing (whoever said Open Source would eliminate needless
rewrites of software, please reconsider -- I got angry because of it).

I decided that instead of making the changes here, I will attempt to
make them upstream. However, I'm not so experienced, so help is
appreciated. For now I will only look to the 2.0 version of netatalk,
and ignore the 1.6 branch (these changes will not make it into sarge
anyway, and I think in a couple of months 2.0 will becomes stable
upstream).

As for the code, a quick glance showed that:
* netatalk does specifically link against OpenSSL, since the
  configure scripts looks for the file "include/openssl/cast.h".
* <a href="http://www.gnu.org/software/gnutls/">GnuTLS</a>
  does not come with the cast.h header file (mainly openssl.h)
* An other, public domain package, <a href="http://
  cryptopp.com/">crypto++</a>, does come with the cast.h
  headers.

I haven't looked into things, but this may be promosing. My next
goal is to adjust the configure file to (a) recognize the path of the
GnuTLS and Crypto++ header files, and thus the library; (b) add a
switch to the configure script to allow selection of either OpenSSL
(default) or GnuTLS/Crypto++ for linking; and (c) link against
these libraries instead of OpenSSL.

However, I am not very familiar with make scripts (I only use
them, never created them). So I'd appreciate help on dealing with
the the configure.in and aclocal.m4 files, and the autoconf tool (I
currently don't even know if I need automake as well)

If you like to help (I would very much appreciate it!), please refer to
feature request #10355455 at Sourceforge:
http://sourceforge.net/tracker/index.php?func=detail&aid=1035455&group_id=8642&atid=358642