Re: TODO: GNU TLS

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

You're talking about GPL software as if it's an entity to which licenses
can be granted and that's just not the case. Licenses are granted to
invidividuals and it's certainly possible that a license can say "You
can distribute this code all you want, except if you put xyz on the same
CD as this code, because I don't like xyz". It's not at all uncommon
for licenses to be incompatible because when all is said and done all of
the licenses involved in a given applicaiton must be satisfied for the
application to be distributed.

In other words, to distribute exim4 the licenses of the following pieces
must all be satisfied:
exim4 itself (GPL)
libc6 (LGPL)
- tzdata ('public domain')
libdb4.3 (Kind of a BSD/GPL mix - Sleepycat, and newBSD for some parts)
libgnutls13 (LGPL)
- libgcrypt11 (LGPL, GPL for documentation)
- libgpg-error0 (LGPL)
- liblzo1 (GPL)
- libopencdk8 (GPL)
- libtasn1-3 (LGPL)
- zlib1g (BSDish)
libldap2 (BSDish - OpenLDAP, LGPL, BSDish - CRL, FSF Makefile.in,
BSDish - HC, BSDish - IBM, IS RFC license, BSDish - ISC, BSDish - JC,
BSDish - MA, BSDish - MIT, BSDish - PM, BSD w/ advertising clause from
UoC with a note that the advertising clause was retroactively removed
by UoC, BSD - UoC, BSDish - UoM with clarification from the OpenLDAP
foundation)
- libsasl2 (BSDish)
libmysqlclient15off (GPL)
- mysql-common (GPL)
libpam0g (BSDish)
- libpam-runtime (BSDish)
libpcre3 (BSDish or GPL if embedded with GPL software)
libperl5.8 (GPL or Artistic)
- perl-base (GPL or Artistic)
libpq4 (BSD)
- libcomerr2 (BSDish)
- libkrb53 (BSDish)
- libssl0.9.8 (BSD w/ advertising clause)
libsasl2-2 (BSDish)
- libdb4.4 (Kind of a BSD/GPL mix - Sleepycat, and newBSD for some
parts)
libsqlite3-0 ('public domain')
debconf (BSDish)

If any of these aren't satisfied then the resultant work can't be
distributed (that's the way copyright works, by default you have no
rights, at least here anyway, aiui).

> 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

I never said anything about obeying or disobeying the PostgreSQL
license.

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

An application can be released under more than one license. The GPL
understands this and doesn't say "everything must be GPL!", it says that
those other licenses can't add any restrictions *beyond* those in the
GPL. The PostgreSQL license doesn't, so there isn't a problem with
combining Postgres (by itself) and GPL programs.

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

Yeah, uh, licenses can say pretty much whatever they want and if you
don't follow them then you're not allowed to distribute it, that's the
way it works. The GPL doesn't define how OpenSSL can be distributed,
no, but what it *does* say (which it certainly can) is that you can't
distribute the *GPL* code when combined with the *OpenSSL* code, and
since the application is comprised of both you're SOL.

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

You're trying to make a distinction that the direction of the dependency
makes a difference. The problem is that there is no 'direction'. The
resulting application is built from both, and the resulting application
is what we're talking about. It doesn't matter that OpenSSL is lower or
higher on the call stack.

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

No, not equivalent, compatible, exactly as I said previously and showed
above. If I purchase the rights to three books under three different
licensing agreements and then combine them, verbatim, into a larger
book, you think that I don't have to follow the licenses under which I
obtained the rights to distribute them? What if those licenses say "you
can't distribute this work as part of another work"? You think I can
just ignore that? The only reason I have any rights at all is because
of the license which grants me the rights, and that license can dictate
the terms of that grant.

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

Being compatible certainly doesn't require they have the same effect, it
just requires that a work comprised of both can be distributed in such a
way as to satisfy the requirements of both.

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

Right, the GPL says you have to include the license, so including the
license for PostgreSQL *isn't* a new restriction that the GPL doesn't
have. The problem is *exactly* that the OpenSSL license has a
restriction above and beyond that.

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

Exactly! We have to honor them *all*, and it makes no difference the
order in which things appear.

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

Certainly.

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

The issue is that the application is exactly that derivation which
combines both GPL code and code under other licenses (which needs to
then be GPL compatible or the resulting application can't be
distributed).

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

I couldn't care less two whits about what Stallman wants, honestly. The
issue I'm trying to deal with is that Debian, being perhaps overly
cautious as they tend to be, has an interpretation (which makes quite
reasonable sense to me anyway) of the GPL which makes GPL applications
using OpenSSL a problem. While we've been working to get authors of
such applications to add exeptions for OpenSSL, projects which provide
the option to use GNUTLS can reduce the amount of work considerably.

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

I really have no idea where you get the idea that there is FUD going on.
FUD means that there's some implication of risk on the person being
asked to do something. That's simply not the case here- there's no risk
to PostgreSQL, or to exim4 in the above case, or pretty much to anyone
except distributions like Debian and even that's pretty minimal.
Debian's certainly not going around saying "if you don't do this,
lawyers will come after you!" because it doesn't make any *sense*. It's
more like "if you don't do this then we're worried you might some day
decide to sue us over it". While the exim or other folks might have
decided it's easier to just add the exception than to argue over it that
doesn't imply there was FUD involved.

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

b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
...
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote
it.

Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.

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

Uhm, yeah, so, no, that'd be exactly the problem, heh.

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

I think you're confusing the issues. :)

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

The GPL has an explicit exception for this, as I mentioned previously..
Given the nature of Debian I don't think it'd work for them though.

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

While I appriciate your enthusiasm to counter FUD, I'm pretty much
convinced that it's rather misplaced here.

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

<Shrug>

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

I'm not advocating this, heh. This hasn't got anything to do w/
distributing PostgreSQL or OpenSSL by themselves but rather distributing
them when combined with a GPL licensed application.

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

Exactly, GPL code and non-GPL code can end up in the same binary but to
be legally distributed the licenses of both have to be satisfied.

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

As I mentioned, the GPL has an explicit exception for the OS:
However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.

The reason this doesn't really work for Debian is that the whole thing
is distributed together, not seperately (at least in some cases).

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

heh, and that's exactly what Debian is trying it's best to do.

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

Sure, but Debian does it and then distributes the results and so has to
deal with all of the licenses, and, yes, how they interact with each
other.

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

I don't think it's true either, I was listing reasons why some might
feel this isn't an issue (and noting that your claims weren't among
them).

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

Exactly, that's what Debian's trying to do.

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

In the end I'd have to defer to the folks on debian-legal and the Debian
ftpmasters and mirror operators. In the end I think that their
interpretation is the correct one but I wasn't the one who originally
thought this all through.

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

Sorry for being presuming but I'm honestly suprised that there was
really a question about what happens when a GPL application is combined
with other non-GPL code. I suppose being part of Debian I've gotten
used to people being familiar with Debian's take on it.

Thanks,

Stephen