Re: [Mingw-cross-env-list] License issue / dependencies on OpenSSL

[Mark Brand]

On 02/23/2011 01:57 PM, Volker Grabsch wrote:
>  Hello Lothar, Tony,
>
>  Sorry for joining the discussion so lately. I also hope that Mark
>  Brand will join this discussion.

Actually, I made the second post in this thread but since then have just 
been lurking.

>  The OpenSSL issue is a very important point. We already disabled some
>  compiling options for other projects (e.g. ffmpeg) because of
>  licensing issues, and I think we should do that in this case, too.

I'm still keen on avoiding a license thread, but it's probably a good 
idea to try to summarize the issue:

As I understand it, the openssl license imposes some "advertising" 
requirements on distribution that make it incompatible with GPL. There 
may be a "system library" exception to this incompatibility, but openssl 
is not considered a system library on Windows. Furthermore, static 
linking to openssl means that the library is packaged with the 
application, precluding the "system library" exception.

A clearly problematic scenario would be where software is distributed in 
compiled form linked to both GPL software and openssl. GPL requires GPL 
compatibility of the distributed software, but this is impossible 
because of openssl. The concern motivating this thread is that someone 
might accidentally do this.

GPL imposes no requirements on non-distributed software linking to GPL 
software, so non-distributed use poses no problem.

It might also be permissible to distribute software linked to both 
openssl and LGPL software. This depends in part on one's view on LGPL 
and static linking.

>  While I fully agree with Tony that it is the developers'
>  responsibility (i.e. not our responsibility) to be aware of and to
>  solve the licensing issues of their projects, I also think that
>  mingw-cross-env should always provide sensible defaults.
>
>  With "sensible defaults" I'm thinking of two points, in that order:
>
>  1) don't make the developer run into unexpected licensing issues
>  2) make the packages as feature complete as possible

If "unexpected licensing issues" are mostly likely to be caused by 
accidentally mixing openssl and GPL, then the ranking here may be 
assuming that mingw-cross-env is used primarily (or most importantly) 
for producing GPLed distributables. This is not obvious, given the use 
cases of non-distribution and license-more-liberal-than-GPL. Of course 
Volker is entitled to define the mission of mingw-cross-env to be to 
buld GPL distributables, but I don't know if that is his intention.

>  Having clarified those general points, let's come to the concrete
>  case of Qt + OpenSSL:

Qt is not unique in this respect. Other packages depending on openssl 
include postgresql and gsoap.

>  I've always been wondering why so many projects are using OpenSSL.
>  There's the excellent GnuTLS library which provides the same
>  functionality and has a plain LGPL license (LGPL 2.1 or later).
>
>  I see why BSD-licensed projects are prefering OpenSSL over GnuTLS.
>  But I don't see why any GPL/LGPL-licensed project would want to use
>  OpenSSL. In particular, I don't see why Qt is using OpenSSL.

I imagine the explanation is history and lack of motivation to change 
course. Openssl is tried and tested. Openssl + GPL is probably not a 
great worry, since Qt can be used under LGPL or commercial license. Even 
if one uses Qt under GPL, openssl is a system library on most targeted 
platforms.

Qt would probably be open to a contributed alternative gnutls backend 
for QSqlSocket, but it's not on their own roadmap.

>  It would be great if our Qt expert, Mark Brand, could elaborate this
>  issues. Mark, do you think it is a good idea to disable Qt's OpenSSL
>  support in mingw-cross-env by default?

As you already pointed out, it's desirable to make packages as 
feature-complete as possible. The question is how to rank this with GPL 
compatibility. If GPL compatibility is ranked higher, then openssl 
features should probably be disabled by default for all packages, since 
any package could conceivably be combined with GPL software.

A compromise could be to continue to enable openssl where sensible, but 
also maintain a "GPL safe" branch of mingw-cross-env where openssl is 
completely purged. Would the slight effort for this be worth the benefits?

regards,

Mark