[Nut-upsdev] Compatibility of GPL 2.0 licensed SSL library

[Charles Lepple]

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 at gmail