* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> In conclusion - I'll restate. The only license that can restrict the
> distribution of OpenSSL, is the OpenSSL license. The GPL is not relevant
> in determining where OpenSSL may be distributed to.

The issue is not the distribution of OpenSSL but rather the distribution
of GPL applications which link against OpenSSL.
Because of the GPL the resulting application can not have any
*additional* restrictions on it (meaning it can be linked against libpq
without any problem because libpq's license doesn't add any restrictions,
but can't be against OpenSSL because the OpenSSL license adds the
advertising clause which isn't in the GPL).

*That's* the issue here, not whatever it is you were arguing against.
There are a few ways to resolve this- add GNUTLS support to PostgreSQL
(GNUTLS is LGPL and so won't cause a problem with GPL or other licenses
in general) or get every GPL application author which ends up using 
OpenSSL to provide an exception (which Debian's been working on, 
actually, with some success), or get GPLv3 to allow advertising clauses
and get everyone to switch to it (not exactly likely to happen...), or
get OpenSSL to drop the advertising clause (I've been told they would if
they could but that much of the code is authored by an individual who
now works for a competitor and now has very little interest in helping
out the OpenSSL project in any way...).

If you feel the advertising clause is fine, then it's the GPL that's at
fault here for not allowing it.  If you disagree with the advertising
clause then it's the fault of the OpenSSL license.  Personally, I don't
really care which way you want to look at it.

On another note, personally I feel it's a good thing to support multiple
libraries when the cost of doing so is reasonably low.  I had kind of
half-expected people would agree with that sentiment and so the
licenseing issue it would resolve (for at least Debian) is that much
more reason.  I didn't really expect a reaction of "there isn't a
licenseing issue so we shouldn't add support for another library".  I
could understand if people don't care about the licensing aspect but
I don't really get this one-size-fits-all mentality when it comes to an
SSL library.  We don't seem to feel that way about authentication
mechanisms, operating systems, or even client libraries.

        Thanks,

                Stephen

Attachment: signature.asc
Description: Digital signature

Reply via email to