mingw-cross-env-list
[Top][All Lists]
Advanced

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

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


From: Tony Theodore
Subject: Re: [Mingw-cross-env-list] License issue / dependencies on OpenSSL
Date: Tue, 22 Feb 2011 04:13:16 +1100

Hi Lothar,

On 21 February 2011 22:30, Lothar May <address@hidden> wrote:
> Hi,
>
> 2011/2/21 Mark Brand <address@hidden>:
> [...]
>> Where would one stop, given the variety of
>> licenses and interpretations that would have to be considered?
> [...]
>
> If I may add:
> Things are not that complicated. If you follow the "GNU way" as in the
> first link in http://mingw-cross-env.nongnu.org/#creating-packages
> then there is a list of licenses there:
>
> http://www.gnu.org/licenses/license-list.html
>
> separated in a list of GPL compatible and incompatible licenses. All
> you need to do is grep through that list.

I too wish to avoid a licensing thread, mostly because it is
complicated. We come to our first license on the list [1], which tells
us - "Please note that GPLv3 is not compatible with GPLv2 by itself"
(and vice-versa). Luckily, there is handy matrix to clarify things
[2].

All we need to do is expand the matrix to include Apache and BSD style
licences and we're done. The Apache project gives us some guidance [3]
and the OpenSSL project state on their homepage [4] that they have an
Apache style licence. The header of the licence [5] states that it's
actually dual BSD style licences. Unfortunately, they're still using
the old style BSD licence, which was rescinded by UCB [6]. Grrrrr.

In the case of OpenSSL, it's clear that the advertising clause
violates the GPL (if you are distributing a derivative work), but why
doesn't it also violate the LGPL? I didn't get around to reading the
Qt licence yet (in my mind it's LGPL), but it may have an exception,
but how does that relate to static linking? Then what happens if
someone uses it in a GPL product, a proprietary product, an internal
project?

I'm sure there's a way to expand the matrix, normalise it, classify
all packages, then implement the compile time options. I'd actually
love to do this, mostly for my own sanity since I change my mind [7]
every time I think about it ;)

In the mean time, my current thinking is that compile time options are
no substitute for diligence on the part of developers. We can't
pre-empt all use cases or shield people from licence violations.

Qt, in particular, seems very good about only linking the libraries
that are actually used. If you look at a minimal test program, qt is
~11mb, gtk ~ 31mb, and gtkmm ~74mb. I'd be interested to know what the
difference is, but I think it indicates that not everything is being
dragged in. If someone is using openssl instead of tls, then we can
only assume that they've checked the licensing terms.

I'd opt to add some windows/static linking licence caveats to the
docs, and maybe a build-time warning at the end.

Cheers,

Tony


[1] http://www.gnu.org/licenses/license-list.html#GNUGPL
[2] http://www.gnu.org/licenses/gpl-faq.html#gpl-compat-matrix
[3] http://www.apache.org/licenses/GPL-compatibility.html
[4] http://www.openssl.org/
[5] http://www.openssl.org/source/license.html
[6] ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change
[7] 
http://lists.nongnu.org/archive/html/mingw-cross-env-list/2010-12/msg00025.html



reply via email to

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