On Monday, July 1st, 2024 at 5:38 PM, Jonas Smedegaard <jo...@jones.dk> wrote:
> > > Quoting Daniel Markstedt (2024-06-23 07:58:54) > > > On Sunday, June 23rd, 2024 at 6:35 AM, Bernd Zeimetz be...@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. > 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
