wolfSSL’s licence is now incompatible with VDE’s

[emilazy]

They switched from GPL-2.0-or-later to GPL-3.0-or-later in a patch release that contained CVE fixes: wolfSSL/wolfssl@629c5b4.

Some files in VDE have licensing headers allowing GPLv3 and later versions, but many only specify GPLv2. Therefore linking VDE to non‐vulnerable versions of wolfSSL is unfortunately a copyright violation, and Mbed TLS support is not present in the released version, which puts distributions in an awkward position.

I would recommend dropping the wolfSSL support in favour of Mbed TLS. If you could also cut a stable release with that change, that would definitely help distributions out :) In Nixpkgs we will probably backport the Mbed TLS support for now.

[emilazy]

They do have an odd list of “exceptions” for which certain projects are allowed to use the newer versions under GPLv2: https://github.com/wolfSSL/wolfssl/blob/master/LICENSING. But, uh, that’s a very strange licensing situation (is it valid to take the GPLv2‐licensed wolfSSL from RPCS3 and then use it to link to VDE or whatever else you want?) and frankly makes me more concerned about the upstream than if they didn’t have it in the first place. So I would definitely recommend just switching to Mbed TLS.

[danielinux]

Hey @emilazy Thanks for reporting this, I'll have the exception added asap. I'll leave this open until fixed.

I don't think we're interested in distributing with mbedTLS. We'd rather support only one crypto.

Thanks,

--
Daniele (@wolfSSL)

[emilazy]

Could you clarify the intent behind the GPLv2 exceptions? The GPLv2 grants everyone who receives software under that licence to redistribute it under the GPLv2, and requires the libraries used by a program to also be offered under GPLv2‐compatible terms. Therefore, it seems to me that the permission provided in the exception:

When this wolfSSL Software is combined with the software listed below (“Exception Software”), licensee may elect to license this wolfSSL Software under the GNU General Public License version 2 (“GPLv2”) instead of GPLv3.

…means that anyone receiving a copy of these projects with wolfSSL included will be in possession of a copy of wolfSSL under the GPLv2, which they can then freely separate from the combined software and use and redistribute under the GPLv2 for any purpose, per the permissions granted by the licence. Therefore, this permission grant is equivalent to wolfSSL being offered to the whole world under the GPLv2 for any purpose, not just in combination with the software in the list of exceptions.

I assume this cannot be the intent, as it means that the relicensing to GPLv3 was completely ineffective. Unfortunately, I don’t see how else this could work – GPLv2 and GPLv3 are simply not compatible, and the GPLv2 requires that libraries used in a GPLv2 program be available under GPLv2‐compatible terms to anyone who receives a copy of that program: either wolfSSL is GPLv2 for everyone, or combining a GPLv3 wolfSSL with a GPLv2 program is a licence violation.

The former is presumably not wolfSSL’s intention, and the latter is a legal minefield. So this is a difficult position for downstream distributors to be in: this change caught us by surprise and means we uncertain of the licensing situation of the QEMU builds we have been distributing for months, and the proposed remedy seems like it either negates the intent of the original relicensing or else fails to address the legal risk this situation has created.

Re “rather support only one crypto”, I see you worked on #51 and #56 – is the support for Mbed TLS is not considered first‐class/supported in some way? From a distribution point of view I don’t feel comfortable with the licensing situation here, so I think we are much more likely to switch to Mbed TLS or disable CryptCab entirely than to compile VDE against wolfSSL.

[danielinux]

@emilazy

• IANAL, so I lost you. (For anything legalese please -> facts@wolfssl.com). On the VDE side we are already considering to move to GPL2+ or GPL3, if possible, but the process can take some time, so we are asking wolfSSL for an exception as per the LICENSING file in your original post.

• You can choose to integrate with mbedTLS integration, but I think we are going to provide updates and packaging support for wolfSSL only. I'm not going to facilitate the integration of mbedTLS more than I already did.

[danielinux]

disable CryptCab entirely than to compile VDE against wolfSSL.

I think this is also an easier option if the exception in LICENSING is not clear enough for you.

In any case, I would like to thank you again for reporting this, it will be surely valuable also for other distro maintainers that run into the same issue.

[emilazy]

IANAL, so I lost you. (For anything legalese please -> facts@wolfssl.com).

Thanks; I’ve forwarded my concerns there.

I think this is also an easier option if the exception in LICENSING is not clear enough for you.

I wasn’t sure how widely‐used CryptCab might be, so I erred on the side of keeping the functionality with the alternate library – QEMU already pulls in Mbed TLS, so that’s an easy decision for us. But perhaps disabling it will be sufficient and simpler, if it is expected that Mbed TLS support in VDE will prove problematic in future.

I do want to point out that the fact that even a project with a wolfSSL employee involved in development has been in a position of licence violation for months as a result of this change underlines that making an incompatible licence change in a patch release that fixes high‐severity CVEs is not very friendly… I see that we are not the only distribution who managed to completely miss the licence change, and I expect others will also have concerns about the whether they can rely on the GPLv2 exceptions.

I understand that wolfSSL likely wants to encourage the purchase of commercial licences by closing GPLv2 loopholes, but from the point of view of FOSS citizenship and adoption in distributions, doing it without sufficient notice and a period of security support for the version under the old licence is a very unfortunate move and will likely reduce wolfSSL adoption and packaging.

I expect that wasn’t your decision to make anyway, though, so thank you for responding to my questions here and pointing me in the right direction :)

[danielinux]

Thanks for understanding :)
To be honest I'm not sure myself on the popularity of vde_cryptcab v. the whole switch + plugs library etc, so I think this is a safe choice and does not impact on any key functionality, and for sure not related to qemu integration itself.

Alternatives exist to create secure tunnels between switches on two remote machines, e.g. dpipe vde_plug = ssh remotehost vde_plug, given some mtu tuning and the penalty of running TCP-in-TCP over lossy links.

I do want to point out that the fact that even a project with a wolfSSL employee involved in development has been in a position of licence violation for months as a result of this change underlines that making an incompatible licence change

My bad for not checking this before. Alas, being vde2 not always in my radar I tend to not be constant with my contributions.

To be honest I remember talking with the team about migrating to GPLv2+ not so recently, so I had to double check with prof. Davoli when this happened today.