Re: TODO: GNU TLS

On Thu, Dec 28, 2006 at 03:56:48PM -0500, Stephen Frost wrote:
> * mark@mark.mielke.cc (mark@mark.mielke.cc) 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).

I don't see the problem. If I redistribute PostgreSQL with GPL software
that I author, I am supposed to keep a copy of the PostgreSQL license
with the derived works. Respecting the license for every component of
software is regular business.

By the words you describe above, the GPL doesn't require that you
include a copy of the PostgreSQL license either. Are you saying that
this makes GPL incompatible with PostgreSQL?

It's silliness. If you redistribute OpenSSL, you honour the OpenSSL
requirements. That's the *only* requirement by copyright law. It doesn't
matter if it is GPL on top, or not. You always honour each license.

The *only* thing GPL-with-GPL does is reduce complexity.

> *That's* the issue here, not whatever it is you were arguing against.

I think you might only be listening to one side.

> 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...).

1) Adding GNUTLS support to PostgreSQL does not eliminate any PostgreSQL  obligation to honour the OpenSSL distribution
license.Any PostgreSQL  distribution that includes OpenSSL must honour the OpenSSL distribution  license, just as any
PostgreSQLdistribution that includes GNUTLS must  honour either the GPL or LGPL license. Nothing changes. It's about
distribution.If PostgreSQL includes OpenSSL support, it is a derived  works when distributed with OpenSSL. It is a
misunderstandingto believe  that support for many interfaces allows you to avoid any licensing  issues. It is a popular
misunderstanding.

2) Explicitly stating an OpenSSL "exception" is not a legal requirement.  It is not possible for any derived product to
"except"conditions  for OpenSSL. OpenSSL defines its *own* license. You cannot modify it,  which means that the GPL
cannotreduce its significance, nor can an  explicit exception claus increase its significance. OpenSSL  distribution
rightsare defined by the OpenSSL license. Full stop.
 
  If you wish to explicitly point out that you don't mind if your  product is linked against OpenSSL (which should be
obviousby the  fact that you included support for it in your program), you are  free to do so. Maybe it'll keep the
lawyersa little hungrier.  It's not necessary, and it *cannot* have legal effect.
 
  Exception clause or not, every author of a derived works that makes  use of it, should understand their *obligation*
tohonour any and  all licenses for any derived software. GPL, LGPL, OpenSSL, Apache,  whatever. The exception clause is
makingthis obvious. It has no  legal weight.
 

> 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.

No. The GPL is allowed to do whatever it wants. What it wants, is to
achieve Richard Stallman's vision of software communism. What the GPL
cannot do is say whether you can, or cannot use OpenSSL. Only OpenSSL
can say whether you can or cannot use OpenSSL.

> 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.

They're entirely different discussions. One is about politics. One is
about practical application.

With regard to practical application, I agree with you.

With regard to giving in to legal FUD, I feel it is my duty to stand up
to it as best as I can, to prevent it from becoming widely accepted.
Nothing personal, and we're both entitled to our own opinions on the matter.
You expressed yours. I've expressed mine. Hopefully truth is found from
the reading of both.

Cheers,
mark

-- 
mark@mielke.cc / markm@ncf.ca / markm@nortel.com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada
 One ring to rule them all, one ring to find them, one ring to bring them all                      and in the darkness
bindthem...
 
                          http://mark.mielke.cc/