Bug#952399: OpenSSL linking without license exception
A side note: The OpenSSL related kmod feature was implemented by Yauheni Kaliuta. Yauheni also posted a version based on GnuTLS (LGPL): https://patchwork.kernel.org/patch/10688685/ Having this available as a variant and using it instead would solve this problem.
Bug#952399: OpenSSL linking without license exception
Marco... On Tue, Feb 25, 2020 at 11:38:53PM +0100, Marco d'Itri wrote: > >For these reasons I have no interest and no plans to do anything about >this, and I am quite annoyed that I had to spend my time researching >these details and then explaining them to you. Regardless of the technical details of the bug report here, what on earth makes you think this text is reasonable when responding? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast." Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
Bug#952399: OpenSSL linking without license exception
On Feb 26, Michael Biebl wrote: > Doesn't really help to add such a license exception as you also need to > consider users of libkmod and check the rdep tree recursively. > > Imho the only sane way to deal with this is to treat OpenSSL as a system > library and apparently other distros with actual legal counsel handle it > that way. Which Red Hat did, and nobody ever complained about in an actual court. This is relevant, because Red Hat is a target for litigation and Debian is not. Or at least to decide that the criteria is "being a derivative work" and not "being listed as DT_NEEDED", which would solve a lot of cases. -- ciao, Marco signature.asc Description: PGP signature
Bug#952399: OpenSSL linking without license exception
On Sun, 23 Feb 2020 20:35:40 +0100 Bastian Germann wrote: > Package: kmod > Version: 26-1 > Severity: serious > > All of the GPL-2+ licensed executables contained in the kmod binary > package link to libcrypto even though they do not have any OpenSSL > license exception. ftp-master considers this a serious issue. So please > remove this optional dependency or ask upstream for a license exception. Doesn't really help to add such a license exception as you also need to consider users of libkmod and check the rdep tree recursively. Imho the only sane way to deal with this is to treat OpenSSL as a system library and apparently other distros with actual legal counsel handle it that way. Regards, Michael signature.asc Description: OpenPGP digital signature
Bug#952399: OpenSSL linking without license exception
Am 25.02.20 um 23:38 schrieb Marco d'Itri: > Control: found 26+20191223-1 > > On Feb 23, Bastian Germann wrote: > >> All of the GPL-2+ licensed executables contained in the kmod >> binary package link to libcrypto even though they do not have any >> OpenSSL license exception. ftp-master considers this a serious >> issue. So please remove this optional dependency or ask upstream >> for a license exception. > The large number of contributors to kmod obviously makes impossible > getting a license exception, also considering that only Debian > cares about linking GPL'ed software with OpenSSL. > > Since only libkmod (which is LGPL'ed), and not the actual commands, > is linked with OpenSSL, and the libkmod symbols do not change > depending if OpenSSL support is enabled or not, and the patches > which introduced OpenSSL support did not touch the commands, then I > think that the commands are obviously not a derivative work of > OpenSSL. You can also easily verify that the commands are not > linked with OpenSSL by looking at the build logs of the package. $ ldd /bin/*mod /sbin/*mod* /bin/kmod: libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /bin/lsmod: libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /sbin/depmod libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /sbin/insmod: libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1/sbin/lsmod: libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1/sbin/modinfo: libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /sbin/modprobe: libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /sbin/rmmod: libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 buster's amd64 binaries are actually directly linked with libcrypto; readelf says "(NEEDED) Shared library: [libcrypto.so.1.1]" Even if they were linked with libcrypto via libkmod it would not make any difference. > Also, the next major release of OpenSSL will be relicensed with the > ASLv2 anyway, which is compatible with the GPLv3. That will help for bullseye+ but not for buster. > For these reasons I have no interest and no plans to do anything > about this, and I am quite annoyed that I had to spend my time > researching these details and then explaining them to you. You don't care and I am fine with that since I am not the maintainer of the package. But I wanted to report the issue anyway since the legal team's comments on that matter are unanimous.
Bug#952399: OpenSSL linking without license exception
Control: found 26+20191223-1 On Feb 23, Bastian Germann wrote: > All of the GPL-2+ licensed executables contained in the kmod binary > package link to libcrypto even though they do not have any OpenSSL > license exception. ftp-master considers this a serious issue. So please > remove this optional dependency or ask upstream for a license exception. The large number of contributors to kmod obviously makes impossible getting a license exception, also considering that only Debian cares about linking GPL'ed software with OpenSSL. Since only libkmod (which is LGPL'ed), and not the actual commands, is linked with OpenSSL, and the libkmod symbols do not change depending if OpenSSL support is enabled or not, and the patches which introduced OpenSSL support did not touch the commands, then I think that the commands are obviously not a derivative work of OpenSSL. You can also easily verify that the commands are not linked with OpenSSL by looking at the build logs of the package. Also, the next major release of OpenSSL will be relicensed with the ASLv2 anyway, which is compatible with the GPLv3. For these reasons I have no interest and no plans to do anything about this, and I am quite annoyed that I had to spend my time researching these details and then explaining them to you. -- ciao, Marco signature.asc Description: PGP signature
Bug#952399: OpenSSL linking without license exception
Package: kmod Version: 26-1 Severity: serious All of the GPL-2+ licensed executables contained in the kmod binary package link to libcrypto even though they do not have any OpenSSL license exception. ftp-master considers this a serious issue. So please remove this optional dependency or ask upstream for a license exception.
