WolfSSL and Netatalk

[Bernd Zeimetz]

Hi,

A few days ago, we released Netatalk 3.2.0 which comes bundled with a
customized subset of WolfSSL as SSL provider.
However, when I spoke to a Debian developer last year about this very
topic, they told me that using WolfSSL for packaged software in
Debian required some kind of special exemption and approval.

wolfssl is packaged in Debian, did you try to build netatalk with the
packaged version?

Debian doesn't like code copies in sources, so if it builds fine with
the packaged version, removing it from the source that ends up in
Debian will fix all issues.

(I didn't check for licence compabilites and such things, guess you've
done that already).


Hope that helps,

Bernd

[Daniel Markstedt]

Post by Bernd Zeimetz
Hi,

A few days ago, we released Netatalk 3.2.0 which comes bundled with a
customized subset of WolfSSL as SSL provider.
However, when I spoke to a Debian developer last year about this very
topic, they told me that using WolfSSL for packaged software in
Debian required some kind of special exemption and approval.

Hi Bernd,

Post by Bernd Zeimetz
wolfssl is packaged in Debian, did you try to build netatalk with the
packaged version?
Debian doesn't like code copies in sources, so if it builds fine with
the packaged version, removing it from the source that ends up in
Debian will fix all issues.

This is a reasonable request. I did try to build with Debian's WolfSSL libraries last year.
At the time (September 2023) I concluded that the DES compatibility headers (des.h etc.) were missing altogether from Debian's WolfSSL package, and therefore could not be used for this purpose with Netatalk.

Some discussion in https://github.com/Netatalk/netatalk/issues/358

Post by Bernd Zeimetz
(I didn't check for licence compabilites and such things, guess you've
done that already).

All of the original WolfSSL codebase is GPLv2 licensed, which is the same license that Netatalk uses.
However, a handful of source files (five of them to exact) are licensed under the traditional SSLeay license.
They constitute key parts of the OpenSSL compatibility layer...

Post by Bernd Zeimetz
Hope that helps,
Bernd

It helps very much, thank you!

Sincerely,
Daniel

[Andrey Rakhmatullin]

Post by Daniel Markstedt

Post by Bernd Zeimetz
wolfssl is packaged in Debian, did you try to build netatalk with the
packaged version?
Debian doesn't like code copies in sources, so if it builds fine with
the packaged version, removing it from the source that ends up in
Debian will fix all issues.

This is a reasonable request. I did try to build with Debian's WolfSSL libraries last year.
At the time (September 2023) I concluded that the DES compatibility headers (des.h etc.) were missing altogether from Debian's WolfSSL package, and therefore could not be used for this purpose with Netatalk.

libwolfssl-dev: /usr/include/wolfssl/openssl/des.h

[Daniel Markstedt]

Post by Andrey Rakhmatullin

Post by Daniel Markstedt

Post by Bernd Zeimetz
wolfssl is packaged in Debian, did you try to build netatalk with the
packaged version?
Debian doesn't like code copies in sources, so if it builds fine with
the packaged version, removing it from the source that ends up in
Debian will fix all issues.

This is a reasonable request. I did try to build with Debian's WolfSSL libraries last year.
At the time (September 2023) I concluded that the DES compatibility headers (des.h etc.) were missing altogether from Debian's WolfSSL package, and therefore could not be used for this purpose with Netatalk.

libwolfssl-dev: /usr/include/wolfssl/openssl/des.h
--
WBR, wRAR

Hm, I wonder why I couldn't find it at the time.
Let me give it another go and see how far we get with building with the Debian WolfSSL package.

Cheers,
Daniel

[Jonas Smedegaard]

Quoting Daniel Markstedt (2024-06-23 07:58:54)

Post by Daniel Markstedt

Post by Bernd Zeimetz

A few days ago, we released Netatalk 3.2.0 which comes bundled
with a customized subset of WolfSSL as SSL provider.
However, when I spoke to a Debian developer last year about this
very topic, they told me that using WolfSSL for packaged software
in Debian required some kind of special exemption and approval.

[...]

Post by Daniel Markstedt

Post by Bernd Zeimetz
(I didn't check for licence compabilites and such things, guess
you've done that already).

All of the original WolfSSL codebase is GPLv2 licensed, which is the
same license that Netatalk uses.
However, a handful of source files (five of them to exact) are
licensed under the traditional SSLeay license.
They constitute key parts of the OpenSSL compatibility layer...

Problem *is* licensing, not of WolfSSL but of the "handful of source
files" recently added to Netatalk:

I looked at one of those files you recently introduced,
include/atalk/cast.h, and it contains the following note just below (or

Post by Daniel Markstedt
The licence and distribution terms for any publically available
version or derivative of this code cannot be changed. i.e. this code
cannot simply be copied and put under another distribution licence
[including the GNU Public Licence.]

Since Netatalk is licensed under GPL-2+, it is perfectly legal¹ for the
Netatalk project to include the above file as part of its source, and
for the Debian project to provide prebuilt shared libraries involving
such source files as input as long as it does not link with code
licensed under GPL licenses, but anyone (other than the Netatalk project
itself, who is not bound by its own license²) violates the GPL-2+
licensing terms if linking with that file, so effectively your project
is not Free software when making use of those files, and Debian cannot
distribute (in main) a build of Netatalk making use of that code.

I have reported this upstream to the Netatalk project as well:
https://github.com/Netatalk/netatalk/issues/1185

- Jonas


¹ I am not a lawyer. Take my words here only as inspiration.

² But beware: It is everyone holding copyright in the Netatalk project
that needs to agree on distributing binaries under different terms, not
only its current developers.

[Daniel Markstedt]

Post by Jonas Smedegaard
Quoting Daniel Markstedt (2024-06-23 07:58:54)

Post by Daniel Markstedt

Post by Bernd Zeimetz

A few days ago, we released Netatalk 3.2.0 which comes bundled
with a customized subset of WolfSSL as SSL provider.
However, when I spoke to a Debian developer last year about this
very topic, they told me that using WolfSSL for packaged software
in Debian required some kind of special exemption and approval.

[...]

Post by Daniel Markstedt

Post by Bernd Zeimetz
(I didn't check for licence compabilites and such things, guess
you've done that already).

All of the original WolfSSL codebase is GPLv2 licensed, which is the
same license that Netatalk uses.
However, a handful of source files (five of them to exact) are
licensed under the traditional SSLeay license.
They constitute key parts of the OpenSSL compatibility layer...

Problem is licensing, not of WolfSSL but of the "handful of source
I looked at one of those files you recently introduced,
include/atalk/cast.h, and it contains the following note just below (or

Post by Daniel Markstedt
The licence and distribution terms for any publically available
version or derivative of this code cannot be changed. i.e. this code
cannot simply be copied and put under another distribution licence
[including the GNU Public Licence.]

Since Netatalk is licensed under GPL-2+, it is perfectly legal¹ for the
Netatalk project to include the above file as part of its source, and
for the Debian project to provide prebuilt shared libraries involving
such source files as input as long as it does not link with code
licensed under GPL licenses, but anyone (other than the Netatalk project
itself, who is not bound by its own license²) violates the GPL-2+
licensing terms if linking with that file, so effectively your project
is not Free software when making use of those files, and Debian cannot
distribute (in main) a build of Netatalk making use of that code.
https://github.com/Netatalk/netatalk/issues/1185
- Jonas
¹ I am not a lawyer. Take my words here only as inspiration.
² But beware: It is everyone holding copyright in the Netatalk project
that needs to agree on distributing binaries under different terms, not
only its current developers.

Jonas,

First off: The good news is that we were able to successfully link with Debian's WolfSSL library the other day.
The next upstream release version of Netatalk will come with build system support out of the box.

On the licensing situation, so my understanding now is that *some* permissive licenses can coexist with GPLv2 licensed code, such as BSD-*, MIT, LGPL* etc.
However, SSLeay explicitly forbids redistribution under GPL, while GPL explicitly says the entire software package has be distributed under the GPL.
Does this sound about right?

FWIW, I naively thought it was sufficient to retain the original licensing blurb for each source file, and independently adhere to the licensing terms for each.
But I see now how one license can impose its terms on other source files in the same distribution...

Anyhow, let's work towards a broader solution in the upstream issue ticket that you raised.

Cheers,
Daniel

[Jonas Smedegaard]

Quoting Daniel Markstedt (2024-07-01 12:04:03)

Post by Daniel Markstedt
On the licensing situation, so my understanding now is that *some*
permissive licenses can coexist with GPLv2 licensed code, such as
BSD-*, MIT, LGPL* etc.
However, SSLeay explicitly forbids redistribution under GPL, while GPL
explicitly says the entire software package has be distributed under
the GPL.
Does this sound about right?

Almost: It is GPL that forbids anti-freedoms in the SSLeay license.

Free software licensing is all about freeing software from the slavery
the monopoly-minded laws called "copyright". GPL contains wording to
ensure that its promised freedoms are not hampered e.g. by additional
licensing terms introducing through linked code: GPL will terminate,
if combined with lesser free terms.
Some perceive GPL as being a "viral" license due to this mechanism: GPL
cannot be "watered down"; The combinatorial result of mixing licensing
terms must be at least as free as GPL.

Confusingly, OpenSSL v3 do not use the OpenSSL license, so reusing
SSLeay-licensed code is legally different from linking with OpenSSL:
https://www.gnu.org/licenses/license-list.en.html#OpenSSL

Post by Daniel Markstedt
FWIW, I naively thought it was sufficient to retain the original licensing blurb for each source file, and independently adhere to the licensing terms for each.
But I see now how one license can impose its terms on other source files in the same distribution...
Anyhow, let's work towards a broader solution in the upstream issue ticket that you raised.

Yes, let's discuss those details upstream :-)


- Jonas