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

Charles Lepple
2018-08-29T13:15:15Z

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