Re: TODO: GNU TLS

* mark(at)mark(dot)mielke(dot)cc (mark(at)mark(dot)mielke(dot)cc) wrote:
> 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?

What in the world are you talking about...? I truely can't follow your
train of thought in the least.

> 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 GPL says you can't combine GPL code with code which has additional
requirements and then distribute the result.

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

I don't seem to be able to explain it to you, even what the issue is,
ignoring the question about if it's actually an issue or not.

> > *That's* the issue here, not whatever it is you were arguing against.
>
> I think you might only be listening to one side.

I'm honestly not sure *what* you're listening to, it doesn't seem to be
me...

> > 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 PostgreSQL distribution 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 misunderstanding to believe
> that support for many interfaces allows you to avoid any licensing
> issues. It is a popular misunderstanding.

As I tried to make clear previously, this hasn't got anything to do with
PostgreSQL distributing anything. Nor does it have anything to do with
PostgreSQL obligations. Here, I'll try again:

Debian --
\ Applications
- exim4
\ Links against:
- libpq
\ Links against:
- libssl (OpenSSL)

exim4 is under the GPL
libpq is under BSD (no advertising clause)
libssl is under BSD (advertising clause)

So, Debian is distributing an application (exim4 w/ libpq & libssl)
which includes GPL code (exim4) combined with code under another license
(BSD w/ advertising clause) which *adds additional restrictions* (the
advertising clause) over those in the GPL, which is against the terms of
the GPL. It's *Debian's* problem, but *PostgreSQL* can solve it by
providing the option to link against GNUTLS instead.

> 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 cannot reduce its significance, nor can an
> explicit exception claus increase its significance. OpenSSL
> distribution rights are defined by the OpenSSL license. Full stop.

In the case above, exim4 *can* provide an exception because it's the
*GPL* of *exim4* which is being violated by the advertising clause in
the *OpenSSL* license. Which exim4 upstream has *done*, and which can
be seen in their license (linked to previously in this thread). There
are a number of other GPL'd applications which have done this, mostly
(if not completely) at the prodding of Debian (bacula being another
which comes to mind).

> If you wish to explicitly point out that you don't mind if your
> product is linked against OpenSSL (which should be obvious by the
> fact that you included support for it in your program), you are
> free to do so. Maybe it'll keep the lawyers a little hungrier.
> It's not necessary, and it *cannot* have legal effect.

Programs may not directly link against OpenSSL and so may not directly
include support for it (uhm, exactly the case when something links
against libpq which then links against OpenSSL), but which ends up still
being part of the distributed application.

> Exception clause or not, every author of a derived works that makes
> use of it, should understand their *obligation* to honour any and
> all licenses for any derived software. GPL, LGPL, OpenSSL, Apache,
> whatever. The exception clause is making this obvious. It has no
> legal weight.

Given that I think your premise above is wrong I won't bother argueing
against conclusions you draw from it.

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

This isn't about whether you can use or cannot use OpenSSL. It's about
if you're allowed to distribute GPL applications which are linked to
OpenSSL without violating the terms of the GPL. *This is not about
distributing 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.

The problem is that you're not standing up to FUD, you seem to be
arguing about something completely seperate from the issue that I've
brought up. I can understand Tom's point, or Andrew's point, that this
might not be an issue because of any number of reasons which might
include:
a) technically the program isn't linked till it's own the user's
computer (personally I don't feel that removes the GPL
requirements though I've heard it claimed)

b) The GPL application doesn't link *directly* to OpenSSL and the level
of indirection means the GPL application doesn't *depend* on OpenSSL,
which means it's not a derivative (imv, this isn't very far removed
from 'a', but I can see some distinction)

c) Authors of GPL code are very unlikely to prosecute such a claim
since OpenSSL *is* OSS and does abide by the DFSG (I wonder if the
FSF might find someone some day willing to, though they might not be
insterested due to possible bad press, who knows...)

d) PostgreSQL can be configured to not use SSL when it ships and
therefore as shipped there isn't a problem (again, kind of a stretch)

e) The GPL doesn't apply to shared library linking

f) The OpenSSL falls under the 'distributed with the OS' clause of the
GPL and therefore it isn't a problem that there are additional
restrictions in its license (probably the most practical argument,
but not sure it'd hold up when that'd basically make all of Debian
exempt since it can all be considered 'part of the OS'...)

Your comments above about a PostgreSQL obligation just don't make sense
and so I have to conclude that you don't understand the issue, which may
be my fault for not explaining it clearly enough but there's only so
much I can do.. Hopefully this will help...

Thanks,

Stephen