[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Mark Brand
Subject: Re: [Mingw-cross-env-list] License issue / dependencies on OpenSSL
Date: Thu, 24 Feb 2011 02:50:55 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101206 SUSE/3.1.7 Thunderbird/3.1.7

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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]