Re: TODO: GNU TLS

On Thu, Dec 28, 2006 at 09:34:05PM -0500, Stephen Frost wrote:
> * mark(at)mark(dot)mielke(dot)cc (mark(at)mark(dot)mielke(dot)cc) wrote:
> > 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.

I will try again. It is a difficult subject for many.

GPL software derived from PostgreSQL must honour the restrictions defined
by the PostgreSQL (BSD) license.

GPL software derived from OpenSSL must honour the restrictions defined
by the OpenSSL license.

What is the difference? Do you see it? You speak of "compatibility" as
if it means that the above are different in some technical way. They
are NOT different. Just because the GPL >= the PostgreSQL license,
does not allow you to disobey the PostgreSQL license restrictions. You
*cannot* release your entire derived GPL product as GPL, if it is
distributed with PostgreSQL. The PostgreSQL component retains the
PostgreSQL licensing restrictions, The GPL restrictions do not
supercede or replace the PostgreSQL component and there is NOTHING the
GPL can do to change this.

> > 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 GPL *cannot* say this. The GPL *cannot* define how OpenSSL can or
cannot be used. Only the OpenSSL license can define how OpenSSL is
allowed to be distributed or used once distributed.

You are looking at it from the wrong direction. The GPL can prevent
*GPL-derived* works from being non-GPL. The GPL CANNOT prevent one
from deriving from non-GPL works. Take some time to read this a few
times if you need to. The difference is HUGE.

It would be ridiculous for it to be different. If it was different, it
would require all software to have exactly equivalent licenses in
order to be integrated. Insanity. Any lawyer who would claim this
should lose their license to practice law.

I'll state again - there is no such thing as *compatibility* in the
sense you are using it. If they were fully compatible, they would have
the exact same effect. The PostgreSQL license is *not* compatible with
GPL in the sense that they can be interchanged. Read the following
snip from the PostgreSQL license, which is incompatible with the GPL
license:

"Permission to use, copy, modiy, and distribute ... provided that
the above copyright notice and this paragraph and the following two
paragraphs appear in all copies."

A distribution that includes GPL software and PostgreSQL software *must*
include both the GPL license, and the PostgreSQL license. This is an
additional "incompatible" restriction with the GPL. The advertising
clause of the OpenSSL license is a second such restriction. It is not
the first such restriction as some people are trying to make it appear.

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

There is no problem above. Debian must honour all licenses for all
software components. There is no need for an exemption, or an OpenSSL
exception clause. If OpenSSL is included within Debian, than the
Debian distribution should include an attribution to it in the Debian
documentation, and the OpenSSL LICENSE file should be stored somewhere
in the file system.

If there is a problem, feel free to describe the actual points of
conflict, using wording from the licenses itself. You are talking
about a theoretical issue that I you have not shown to exist. Drawing
ascii pictures doesn't substantiate your claim. The choice to use the
GPL as the license for a product cannot stop the product from being
derived from a non-free work. Richard Stallman's virus cannot prevent
people from using non-GPL base software. He can *ONLY* prevent people
from deriving from GPL software. Again, read this a few
times. Legally, it can only go in one direction.

If Richard Stallman wants to say that no part of his GNU system will
make use of non-GPL software, that is his choice. He cannot tell the
authors of other software what they can or cannot derive from. Only
the license of the product being derived from can tell the author
what they are allowed to do. Richard Stallman / GPL is not in the
picture.

The truth here, as I see it, is that Richard Stallman wants people
who use the GPL, to believe in his political ideal, and choose to
only use GPL software wherever possible, to allow his agenda to be
achieved as quickly as possible. For GPL software to be legally
derived from non-GPL software prevents his political ideal from
ever being fully achieved. This is why people are trying to make
open source hardware, and open source drivers for hardware. The
dream is to have a complete software stack that is all guaranteed
to be free to use, and free to derive from. It really is a dream.

I don't share this dream.

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

No. It's because of the FUD surrounding the issue. People would rather
submit, and write an exception clause, than argue, or risk having to
square off against a lawyer. Existence of the clause does not prove that
the clause is necessary, or that it has any legal weight. It only proves
that one or more people were convinced that it wouldn't hurt.

I think it hurts everyone to submit to FUD, no matter if the FUD is
from Microsoft, or from the FSF. I believe that people should be making
choices based on knowledge, and understanding, than because of fear or
uncertainty.

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

It doesn't matter how it happens. If it's possible that OpenSSL might
be linked, than the distribution should include a copy of the OpenSSL
license, and documentation for the distribution should show that
OpenSSL is a part of the distribution. On my Fedora Core 6 system, I
see a copy of the license in:

/usr/share/doc/openssl-0.9.8b/LICENSE

As well as in the header of most files such as:

/usr/include/openssl/ssl.h

I assume if I look hard enough, I would find something that qualifies
as an attribution to Fedora Core containing OpenSSL within the Fedora
Core documentation. If Fedora Core wishes to be legal, and respect all
licenses of included software components, it should.

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

Where are the words in the GPL that you think make your case? I haven't
seen them in this thread. I've seen references to the thinking of other
people, mostly people who have an FSF agenda to maintain. Where are the
words? Is it all hearsay?

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

It is ONLY about distributing OpenSSL. GPL applications can CERTAINLY
link against a legally distributed and used OpenSSL without violating
the GPL.

I think you are confusing the intent of Richard Stallman in authoring
the GPL, with any legal weight the GPL actually has. One is about the
dream. The other is about what the countries we live in, allow to be
written on paper.

Find words in the GPL that prevent one from choosing to use the GPL as
the license for your software, even if your software legally links
against a non-GPL product. I assume you are aware that GPL software is
often compiled using proprietary compilers and linkers, and linked
with proprietary system libraries, and executed on proprietary
operating systems, running on proprietary hardware. Will you claim
that this violates the GPL as well?

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

I am *only* standing up to the FUD. Your points a), and b) below are
practical issues. The FUD is about people repeating fear and uncertainty
to open source project mailing lists all over the world.

On practical issues, my opinion might be quite different. I'll offer
them below, although after how you've responded to my other opinions,
I'll assume you might not care to read them... :-)

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

My opinion: If distributed in binary form, than the distribution
itself must obey the OpenSSL restrictions. This includes ensuring that
documentation for the distribution includes an attribution to the
OpenSSL project, and ensuring that the OpenSSL license is included
in the distribution.

If the user downloads PostgreSQL and OpenSSL separately, and then uses
both legally, linking them together, no distribution has occurred. As
copyright law is about distribution, copyright law cannot prevent one
from linking the pieces together at compile time or run time. If the
user distributes the binary image, then this goes back to the previous
paragraph.

Some lawyer might be able to convince a judge that PostgreSQL requires
OpenSSL to operate, and therefore, PostgreSQL is a fully derived work,
and not including OpenSSL does not free the PostgreSQL owners of
responsibility. The case seems pretty shaky, though, and OpenSSL is
not a required component of PostgreSQL.

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

My opinion: Not different from 'a' at all. GPL applications can be
legally derived from non-GPL applications. The license restriction of
the product that is being derived from determine whether the
derivation is legal or not. Richard Stallman doesn't want people to do
this, because it hurts his cause, but legally, he can't stop them,
as it is a necessary part of life with software. The product is always
derived from at least one non-GPL product, even if only the hardware
that it sits on. That is, until the FSF achieves its agenda of having
a 100% GPL system....

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

My opinion: This usually takes the form of 1) somebody forgetting to
honour a part of the license, 2) somebody pointing it out, 3) somebody
grudingly obeying. This might be a GPL-derived product that was released
from the authors as binary only, where the software is grudingly released
upon request (perhaps request by the FSF). This might be an OpenSSL-derived
product that was released from the authors without attributing OpenSSL
in the documentation, in which case they add a note in the documentation.
This could be a BSD-derived product that forgets to include a copy of
the BSD license in the distribution, in which case the license is
grudingly added back.

It doesn't matter what the license is. People know they should honour
the license. Ignorance is not an excuse. Choosing to ignore the license
is not honourable.

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

This goes back to a). If the distribution includes OpenSSL, it must
honour the OpenSSL license. If PostgreSQL is not shipped with OpenSSL,
but allows it to be linked with OpenSSL, than the responsibility is
moved to the person who links the application and redistributes the
linked application. If the end user does it, then it is not a
redistribution, so copyright law cannot apply.

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

My opinion: I don't think this is true. LGPL doesn't apply to shared
library linking. GPL does.

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

My opinion: Same as a). The responsibility is moved to the distributor.
The OS distribution must honour the license.

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

I think we've both concluded that the other person doesn't understand the
issue. Although it may be clear to you or I that the other is wrong, I
think the strength of the arguments will stand on their own as to whether
other people choose to believe you, I, or some third interpretation.

I've tried not to be presuming. I ask of you the same.

Cheers,
mark

--
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)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 bind them...

http://mark.mielke.cc/