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


--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, June 23rd, 2024 at 6:35 AM, Bernd Zeimetz <[email protected]> wrote:

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,

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

(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...

Hope that helps,

Bernd

It helps very much, thank you!

Sincerely,
Daniel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmZ31QotFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh Q4EP/3vOlodKDk+tPgQqfb6icwbPDs38Gv2C/dEDSvMvJIVn+R64wgXyFstKwvO9 BWcsW2n5YJfeJX5LOb4IIVKoWnD5x2x2+j8Slco2NX7+LYCUuwmmVYMJaEQqM080 FwTGVoTyhh9BxzfGT4ts9ugLLGsTD2GsLM4ye1J8xvibNOaMWF0JQI9sOibEzJzu nr3tZ0Pihnbn1k8gyOLH6BTvenol5YJrJ0jFVGvONVs5niTsylNAhYdhMfEz/QUW hcUNi5vXCdTLFUjM2rU63A6f6mp930AeQCmGvLuJvtQNzppQhSRnl+N9UkITUjpi u9r793YR3st7+ZGnLQ9lOT1+pOlg/mF5FRqfs2fMVJtk3GloiQBv5P2bnR5b1qLy K3/pbt8mWVuTzUydldJes30YM1I19k8X5+EAC5+RtkPOLRrxaVwVcZFiDRzjbNHD AQ1+SmuUwdqR2pdAhGiiZh+1mb7rnmV6Sd4qiC2CyHwfUII9gmLj7zUgAKOGLU0u 1udaCSFzyWymmq63gnLXKakslLkivZT4lHAe+ganIjSs0SS8oyWk7kbtsFeQFd1h U+37btLBeZgtOvsD145aAzmnen7Wa2vO1tZUm36qy2+n2R4NyPm/Dss+Dwy8MMXf iGzoM9ulfKtH9ujxLztZx9+F+zgWPB7oqCYIC1yBcjGwOr0D
=3owM
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, June 23rd, 2024 at 4:55 PM, Andrey Rakhmatullin <[email protected]> wrote:

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

On Sunday, June 23rd, 2024 at 6:35 AM, Bernd Zeimetz <[email protected]>
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.

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============U94341010747631272=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmaCauwACgkQLHwxRsGg ASFBkA//VJVSPbvtW0gSKopAOp8FIYridW6ff9EWYYeO2Qjvs01wrCrmvuQF2utF Cw5XNbdEJ/Yrqx1W54zo0rjRBy34+rtIXcwxAUrTLlNHCkDikBI8G8+AMA1EynLA iMzqQnSWvBqB9mIP01UTUC+OcOEAmieDWHPka6zNj2f7dJTvgv337e4Y9q9fSCAS 86z0LDLMDUAudxqGDcqdMzWSKsWrwdiW6HI3A/OGdL+EeVJqAmaMbSB8sUbRiXJq UN+WmZuu+s/o+YPPNxVPPfcrU1PQkYlEEro6QJU504WdYesVo3/zbbN4Q4vrLdmJ WbAnmjAVn+RS7gnUvT/tytkzxyt1l2oUlKsjZadGfjywam59ykJa5U/AV2emB37o 41GE4EbdNX8HYd/WnGq1dQoMFOZXGAFh7U40ykuC6Bg8ghi1TyHS6HPBKwsyda34 p7fYWYwolke2GxrV+AWi0OeRxvyFoGKTM95Ch9lx

On Monday, July 1st, 2024 at 5:38 PM, Jonas Smedegaard <[email protected]> wrote:

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

On Sunday, June 23rd, 2024 at 6:35 AM, Bernd Zeimetz [email protected]
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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

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

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

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============194314573283165427=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmaCij8ACgkQLHwxRsGg ASELFg//S50Adj4E1MdOlBLIqUBU8IZ25Me16qYV4aDsBIUvEZGoEHnSVodWQVhI Zm7/qevIMIisfQe5cNpJx0hg1VL7eO5PH5KjBB8BLaBd89JH286Aoskgf/eXaxyS kc+M5ueKglUZUn2vM1xj0MWlaGPhpH8lKhE0Psn7uJG0mHebg5QasU7YfxBdVj0A z0LXOVylAg2ezygpPWrwivb3Ak9K6WHJfCtR24YLbRunzmFoNvWDy2cPHjMj58/S V04sdfz94R90UYRxUBglHPSzYDLrASvMcPywSHkWED81dPD7pg1N/Kr9Yt8tEVE5 5rmFhsWsztxE9IKQr9/+Fx2//TRKAvPFWJY5aN44ap+etkU2BwnApuRKNpG85hMY dvkyc5Jte28G4XSte7/9M/d+YUG2SkuwwtVL7kRbx7Tc+1rnulNpPd+43RNMCsDo A8wtKDA/zvZf5Z9jOYC78ccQX1JLLL7UHRhPnRtI