[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Netatalk and OpenSSL licencing

On 09-08-2004 17:14, "MJ Ray" <mjr@dsl.pipex.com> wrote:

>> Netatalk is absolutely NO derivate of openssl.
>  From a quick inspection, I don't think that will be true for all of a
> netatalk binary compiled with openssl-related parts enabled. I think
> you realised this in your later message.

No. This is untrue. I just realised that Netatalk, just like most binary
distributions are *dynamically* compiled. Not statically.

For example, all the password encryption-related parts (which link against
openssl) do end up in so-called UAMS (authentication modules). For example,
the one I talked about it /usr/lib/netatalk/uams_dhx_pam.so

I did compile it manually and found:
netatalk-2.0-beta1# ldd /usr/local/lib/netatalk/uams_dhx_passwd.so
        libcrypto.so.0.9.6 => /usr/lib/i686/cmov/libcrypto.so.0.9.6
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x400d0000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x400fe000)
        libdl.so.2 => /lib/libdl.so.2 (0x40113000)
        libc.so.6 => /lib/libc.so.6 (0x40116000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

As you can see it indeed is DYNAMICALLY linked. Which means that no part of
the openssl binary code is included. I did try to verify that.

# cd source/netatalk-2.0-beta1
# grep -rsi libssl *
Only matches a few readme files
# grep -rsi libcrypto *
Matches config and some binary files.

I have the impression that no binary output file includes code which is
either (1) compiled from openssl sources or (2) include libssl.a or

I will verify this this evening.

If it is not the case, then the only thing that is included are the *header*
files in /usr/include/openssl.

However, header files result in no code (that's why they're header files)
and are neither included in the distribution.

Clearly uams_dhx_pam.so & co do include executable code which is compiled
from GPL-covered source code.

Technically, the issue boils down to this part of the OpenSSL licence:

( http://www.openssl.org/source/license.html )
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in
 *    the documentation and/or other materials provided with the
 *    distribution.
 * 3. All advertising materials mentioning features or use of this
 *    software must display the following acknowledgment:
 *    "This product includes software developed by the OpenSSL Project
 *    for use in the OpenSSL Toolkit. (http://www.openssl.org/)"

The third point, the inclusion of the line, is incompatible with the GPL.
As such, just including the line is no incompability. That's fine. The
issue is that according to #1 or #2, redistributions must contain this
licence as well, and thus place restriction #3 on further derivate works.
This is not allowed, since it also places an added restriction on
GPL-derivate code.

So if indeed netatalk contains executable code from openssl, then according
to #2, the redistributed binary must have the openssl-licence, and that is
not allowed. However, just thinking about how dynamic libraries work, I
belief there is no executable code of the library being called involved,
even though the header files are used (since they only contain definitions,
but don't lead to executable code).

Could someone confirm or deny this?

In the mean time, I'll check this assertion by examining the header files,
compiling them, and by forcefully removeing libssl.a and libcrypto.a from
/usr/lib before compiling netatalk.

Kind regards,
Freek Dijkstra

Reply to: