On Sun, Mar 13, 2016 at 3:36 PM, Kurt Roeckx <k...@roeckx.be> wrote: > On Sun, Mar 13, 2016 at 03:28:30PM +0100, Mikkel Krautz wrote: >> A tiny bit of follow-up to my suggestion of using "-openssl-linked" for Qt: >> >> In the earlier Debian bug that was linked by Chris, it was brought up >> that an application may use QtNetwork without using SSL, and therefore >> might not be able to link against OpenSSL due to license >> incompatibilities: >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623596#94 > > OpenSSL will be changing it's license, so hopefully this won't be > a problem in the future.
While I applaud the license change (I love it!), I don't think it comes without problems of its own. Last I heard, the chosen license was Apache 2 (per the blog post), so I obviously don't know if things have changed. The FSF considers the Apache 2 license incompatible with GPLv2, so there are still going to be issues, since it's inevitable that some software will stick to GPLv2 (like Linux). But the incompatibility seems to only apply to some situations: <http://www.apache.org/licenses/GPL-compatibility.html>: [...] This licensing incompatibility applies only when some Apache project software becomes a derivative work of some GPLv3 software, because then the Apache software would have to be distributed under GPLv3. This would be incompatible with ASF's requirement that all Apache software must be distributed under the Apache License 2.0. [...] I think it would have been better to align with BoringSSL and LibreSSL's ISC license instead to facilitate code sharing (patent grant is already explicitly spelled out in the CLAs). But perhaps there are good news coming on that front. :-) ...Anyway, my point is, that from my perspective, with the information I am privy to, it seems to me there are -- sadly -- still cases where it might be necessary to dynamically load OpenSSL in Qt, even with OpensSSL 1.1.