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,
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
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.
On Sun, Jun 23, 2024 at 05:58:54AM +0000, Daniel Markstedt wrote:
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
On Sunday, June 23rd, 2024 at 6:35 AM, Bernd Zeimetz <bernd@bzed.de>
wrote:
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.
(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...
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.]
Quoting Daniel Markstedt (2024-06-23 07:58:54)
On Sunday, June 23rd, 2024 at 6:35 AM, Bernd Zeimetz bernd@bzed.de
wrote:
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.
[...]
(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 arguably part of) the SSLeay license text:
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.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 360 |
Nodes: | 16 (2 / 14) |
Uptime: | 128:36:03 |
Calls: | 7,686 |
Files: | 12,828 |
Messages: | 5,711,088 |