On Aug 29, 2018, at 4:15 AM, Daniel F. Dickinson wrote: > > Hi all, > > I'm wondering if the GPL-2.0 licensed mbedTLS (that's the version in > OpenWrt) is 'compatible' with NUT binaries (not including the Python or > Perl binaries which aren't used in OpenWrt) which is GPL 2.1+ AIUI.
(I am not a lawyer; do not interpret this as legal advice, opinions are my own and do not represent the views of my employer, etc.) NUT is in a similar situation as cURL, in that NUT uses the GPL "version 2 or (at your option) any later version" text. (I would nitpick and call that GPL 2+ or 2.0+; I don't think there is a version 2.1 aside from the LGPL, which is a different animal.) There is no OpenSSL exception clause for NUT, and I don't think it would be practical to relicense all of NUT just for the SSL code. https://curl.haxx.se/legal/licmix.html > Because mbedTLS is the default library for OpenWrt and NSS is not yet in > OpenWrt, and because OpenSSL is considered incompatible (I seem to > recall reading that in the NUT documentation) I'd like to make building > against mbedTLS (formerly polarssl) an option, but don't want to go that > route unless it'd be possible to distribute an SSL-enabled binary in > OpenWrt. A quick read of https://tls.mbed.org/openssl-alternative seems to indicate that while the GPL version of mbedTLS solves the license incompatibility with NUT, it does not address API compatibility. To be honest, if I were setting up NUT in an environment where I needed TLS/SSL, I would probably want to put a bit more distance between the TLS code and NUT. An external TLS proxy (like stunnel) or a VPN should accomplish this. Because it is a network connection and not internal program linkage, that opens up far more license possibilities for the TLS code. -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
