On Sun, Mar 13, 2016 at 03:55:54PM +0100, Mikkel Krautz wrote: > 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:
We are considering a GPLv2 exception, but I really have no details about that yet. > 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. :-) I have no idea if the patent grant in the CLA is good enough, that would only cover people that contribute code. > ...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. I don't think the 1.1 version will already be under the new license. We still have many people to contact for this to happen. Kurt
