Thread: TODO: GNU TLS
Hello,
What is the consideration here? I read the thread and it appears that
OpenSSL is not compatible with GPL? But we don't care about that right?
The OpenSSL looks pretty BSDish to me, expect the advertising clause (is
that what caused XFree86.org to fork?).
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
* Joshua D. Drake (jd@commandprompt.com) wrote:
> What is the consideration here? I read the thread and it appears that
> OpenSSL is not compatible with GPL? But we don't care about that right?
> The OpenSSL looks pretty BSDish to me, expect the advertising clause (is
> that what caused XFree86.org to fork?).
OpenSSL isn't compatible with the GPL. We do care because GPL
applications link against libpq and therefore can end up linking against
OpenSSL. I don't believe it was the OpenSSL advertising clause that
caused the XFree86.org fork. My vaugue recollection is that XFree86
changed their license to include something like an advertising clause
and that's what cause the split.
Thanks,
Stephen
Joshua D. Drake wrote: > Hello, > > What is the consideration here? I read the thread and it appears that > OpenSSL is not compatible with GPL? But we don't care about that right? > The OpenSSL looks pretty BSDish to me, expect the advertising clause (is > that what caused XFree86.org to fork?). Folks, please restate the topic in the email body, rather than requiring people to magically remember the subject. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Thu, 2006-12-28 at 13:01 -0500, Stephen Frost wrote:
> * Joshua D. Drake (jd@commandprompt.com) wrote:
> > What is the consideration here? I read the thread and it appears that
> > OpenSSL is not compatible with GPL? But we don't care about that right?
> > The OpenSSL looks pretty BSDish to me, expect the advertising clause (is
> > that what caused XFree86.org to fork?).
>
> OpenSSL isn't compatible with the GPL.
The original discussion stated that well placed attorneys in the market
feel that the FSF is trying to reach beyond the hands of god on this one
and that we don't need to worry about it (my words, for actual quote
read thread ;)).
> We do care because GPL
> applications link against libpq and therefore can end up linking against
> OpenSSL. \
Our concern is whether PostgreSQL is legally linked, not if something
else is. /me is trying to think very hard of a program that is GPL that
links to to PostgreSQL that would have a problem....
> I don't believe it was the OpenSSL advertising clause that
> caused the XFree86.org fork. My vaugue recollection is that XFree86
> changed their license to include something like an advertising clause
> and that's what cause the split.
That's what I meant, that Xfree86.org added an advertising clause which
caused the split.
Sincerely,
Joshua D. Drake
>
> Thanks,
>
> Stephen
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
On Thu, 2006-12-28 at 13:02 -0500, Bruce Momjian wrote: > Joshua D. Drake wrote: > > Hello, > > > > What is the consideration here? I read the thread and it appears that > > OpenSSL is not compatible with GPL? But we don't care about that right? > > The OpenSSL looks pretty BSDish to me, expect the advertising clause (is > > that what caused XFree86.org to fork?). > > Folks, please restate the topic in the email body, rather than requiring > people to magically remember the subject. http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
* Joshua D. Drake (jd@commandprompt.com) wrote: > On Thu, 2006-12-28 at 13:01 -0500, Stephen Frost wrote: > > OpenSSL isn't compatible with the GPL. > > The original discussion stated that well placed attorneys in the market > feel that the FSF is trying to reach beyond the hands of god on this one > and that we don't need to worry about it (my words, for actual quote > read thread ;)). Yeah, that's nice. > > We do care because GPL > > applications link against libpq and therefore can end up linking against > > OpenSSL. \ > > Our concern is whether PostgreSQL is legally linked, not if something > else is. /me is trying to think very hard of a program that is GPL that > links to to PostgreSQL that would have a problem.... Looking at it from the point of view that psql if fine and therefore there isn't a problem is *very* short-sighted. Some of the packages currently in Debian/unstable which are licensed under the GPL and linked against libpq4 (a few of which have already provided exceptions for linking against OpenSSL): amarok http://packages.debian.org/changelogs/pool/main/a/amarok/current/copyright aolserver4-nspostgres http://packages.debian.org/changelogs/pool/main/a/aolserver4-nspostgres/current/copyright asterisk (which has provided an OpenSSL exception) http://packages.debian.org/changelogs/pool/main/a/asterisk/current/copyright bacula (which has provided an OpenSSL exception) http://packages.debian.org/changelogs/pool/main/b/bacula/current/copyright bandwidthd http://packages.debian.org/changelogs/pool/main/b/bandwidthd/current/copyright courier http://packages.debian.org/changelogs/pool/main/c/courier/current/copyright cvm http://packages.debian.org/changelogs/pool/main/c/cvm/current/copyright cvsnt http://packages.debian.org/changelogs/pool/main/c/cvsnt/current/copyright cyphesis-cpp http://packages.debian.org/changelogs/pool/main/c/cyphesis-cpp/current/copyright exim4 (which has provided an OpenSSL exception) http://packages.debian.org/changelogs/pool/main/e/exim4/current/copyright gambas http://packages.debian.org/changelogs/pool/main/g/gambas/current/copyright gnokii http://packages.debian.org/changelogs/pool/main/g/gnokii/current/copyright gnugk (which has provided an OpenSSL exception) http://packages.debian.org/changelogs/pool/main/g/gnugk/current/copyright gnustep-dl2 http://packages.debian.org/changelogs/pool/main/g/gnustep-dl2/current/copyright gphotocoll http://packages.debian.org/changelogs/pool/main/g/gphotocoll/current/copyright grass http://packages.debian.org/changelogs/pool/main/g/grass/current/copyright guile-pg http://packages.debian.org/changelogs/pool/main/g/guile-pg/current/copyright guile-simplesql http://packages.debian.org/changelogs/pool/main/g/guile-simplesql/current/copyright jabberd2 http://packages.debian.org/changelogs/pool/main/j/jabberd2/current/copyright libdbd-pg-perl http://packages.debian.org/changelogs/pool/main/libd/libdbd-pg-perl/current/copyright postgis http://packages.debian.org/changelogs/pool/main/p/postgis/current/copyright And quite a few others, I'm sure, I just got tired of looking. Thanks, Stephen
> Some of the packages currently in Debian/unstable which are licensed > under the GPL and linked against libpq4 (a few of which have already > provided exceptions for linking against OpenSSL): Sounds to me like the list below needs to add an OpenSSL exception and that PostgreSQL needs to make mention in the docs somewhere of the potential issue. Sincerely, Joshua D. Drake > > amarok > http://packages.debian.org/changelogs/pool/main/a/amarok/current/copyright > aolserver4-nspostgres > http://packages.debian.org/changelogs/pool/main/a/aolserver4-nspostgres/current/copyright > asterisk (which has provided an OpenSSL exception) > http://packages.debian.org/changelogs/pool/main/a/asterisk/current/copyright > bacula (which has provided an OpenSSL exception) > http://packages.debian.org/changelogs/pool/main/b/bacula/current/copyright > bandwidthd > http://packages.debian.org/changelogs/pool/main/b/bandwidthd/current/copyright > courier > http://packages.debian.org/changelogs/pool/main/c/courier/current/copyright > cvm > http://packages.debian.org/changelogs/pool/main/c/cvm/current/copyright > cvsnt > http://packages.debian.org/changelogs/pool/main/c/cvsnt/current/copyright > cyphesis-cpp > http://packages.debian.org/changelogs/pool/main/c/cyphesis-cpp/current/copyright > exim4 (which has provided an OpenSSL exception) > http://packages.debian.org/changelogs/pool/main/e/exim4/current/copyright > gambas > http://packages.debian.org/changelogs/pool/main/g/gambas/current/copyright > gnokii > http://packages.debian.org/changelogs/pool/main/g/gnokii/current/copyright > gnugk (which has provided an OpenSSL exception) > http://packages.debian.org/changelogs/pool/main/g/gnugk/current/copyright > gnustep-dl2 > http://packages.debian.org/changelogs/pool/main/g/gnustep-dl2/current/copyright > gphotocoll > http://packages.debian.org/changelogs/pool/main/g/gphotocoll/current/copyright > grass > http://packages.debian.org/changelogs/pool/main/g/grass/current/copyright > guile-pg > http://packages.debian.org/changelogs/pool/main/g/guile-pg/current/copyright > guile-simplesql > http://packages.debian.org/changelogs/pool/main/g/guile-simplesql/current/copyright > jabberd2 > http://packages.debian.org/changelogs/pool/main/j/jabberd2/current/copyright > libdbd-pg-perl > http://packages.debian.org/changelogs/pool/main/libd/libdbd-pg-perl/current/copyright > postgis > http://packages.debian.org/changelogs/pool/main/p/postgis/current/copyright > > And quite a few others, I'm sure, I just got tired of looking. > > Thanks, > > Stephen -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
* Joshua D. Drake (jd@commandprompt.com) wrote:
> > Some of the packages currently in Debian/unstable which are licensed
> > under the GPL and linked against libpq4 (a few of which have already
> > provided exceptions for linking against OpenSSL):
>
> Sounds to me like the list below needs to add an OpenSSL exception and
> that PostgreSQL needs to make mention in the docs somewhere of the
> potential issue.
Gee, thanks. Perhaps one might consider the license a reason why some
might prefer GNUTLS and would like to see the option? I'm pretty
confident that Debian, at least, would switch to using GNUTLS for
Postgres were it available. It's certainly something we'd like to see
supported by upstream as an alternative to OpenSSL. Given the patch is
available it's possible we could just apply it locally (as was done w/
OpenLDAP) but I really don't think anyone would like to see that.
Thanks,
Stephen
> Gee, thanks. Perhaps one might consider the license a reason why some
> might prefer GNUTLS and would like to see the option? I'm pretty
> confident that Debian, at least, would switch to using GNUTLS for
> Postgres were it available. It's certainly something we'd like to see
> supported by upstream as an alternative to OpenSSL. Given the patch is
> available it's possible we could just apply it locally (as was done w/
> OpenLDAP) but I really don't think anyone would like to see that.
I am not the one you need to convince :). I honestly don't care that
much. I am just trying to help clean up the TODO list. If you want the
GNU TLS patch accepted, you should probably start a thread about that
problem specifically.
Currently, Tom Lane does not like how invasive the patch is. So someone
is going to have to convince him this is a good idea or some of the
other committers.
Sincerely,
Joshua D. Drake
>
> Thanks,
>
> Stephen
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
* Joshua D. Drake (jd@commandprompt.com) wrote:
> I am not the one you need to convince :). I honestly don't care that
> much. I am just trying to help clean up the TODO list. If you want the
> GNU TLS patch accepted, you should probably start a thread about that
> problem specifically.
Given the thread subject I figured that was in scope... :)
> Currently, Tom Lane does not like how invasive the patch is. So someone
> is going to have to convince him this is a good idea or some of the
> other committers.
Yeah, I saw that, but I think Martijn answers that quite well:
> More than half the patch is simply moving the OpenSSL related stuff
> from fe/be-secure.c to fe/be-secure-openssl.c. If you create the
> -openssl versions first you can more easily see that the changes are in
> fact quite minor. Unfortunatly diff can't represent the change "copy N
> lines from file A to file B" very efficiently.
And following on to that wrt code maintenance:
> Hmm, I see your point. I guess that's an unavoidable side-effect of the
> process :(. However, judging from the CVS logs, these have not been files
> with a high change rate. I think it's worth it but I can imagine other
> people see that differently.
As for Brunce's comment here:
> Of course, we are trading a BSD license with advertizing clause with an
> LGPL license. I guess it makes sense.
I don't see that we're *trading* anything here if we support both, we're
providing users with the choice of which they'd prefer. I'd agree with
Martijn from above- the benefit is worth the (hopefully low) maintenance
cost.
Thanks,
Stephen
> I don't see that we're *trading* anything here if we support both, we're
> providing users with the choice of which they'd prefer. I'd agree with
> Martijn from above- the benefit is worth the (hopefully low) maintenance
> cost.
Well for my honest opinion, I think we should pick *one* and stick with
it. I don't care which. Same for readline. Either spoon up libedit in
ice cream glory or use just readline :)
Sincerely,
Joshua D. Drake
>
> Thanks,
>
> Stephen
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
"Joshua D. Drake" <jd@commandprompt.com> writes:
> Currently, Tom Lane does not like how invasive the patch is.
If GNUTLS really wants to take market share from OpenSSL, why don't they
provide a more nearly compatible API? I don't see why we should have
to jump through so many hoops in order to satify someone else's license
fetish. (And it is a fetish, because only a compulsively narrow-minded
reading of the licenses yields the conclusion that there's a problem.)
regards, tom lane
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
> > Currently, Tom Lane does not like how invasive the patch is.
>
> If GNUTLS really wants to take market share from OpenSSL, why don't they
> provide a more nearly compatible API? I don't see why we should have
They do but it's GPL. Not to mention that the OpenSSL API isn't exactly
a shining star in the software world... I really don't feel this has
got anything to do with 'market share' and I'm not advocating Postgres
drop support for OpenSSL. I disagree that the only way Postgres should
support multiple libraries for a given component is if they provide the
same API- we wouldn't have much in the way of authentication options if
that was really the case. The patch appears large because of things
being moved around and not becuase it is tremendously invasive. Also,
this area hasn't required a lot of maintenance in the past and I doubt
adding GNUTLS support would change that.
> to jump through so many hoops in order to satify someone else's license
> fetish. (And it is a fetish, because only a compulsively narrow-minded
> reading of the licenses yields the conclusion that there's a problem.)
While I appriciate that RH isn't concerned I don't feel their
interpretation is the only possible one which could come out of a court
case. Not to mention that just finding out would be expensive in its
own right.
Thanks,
Stephen
On Thu, Dec 28, 2006 at 10:13:14AM -0800, Joshua D. Drake wrote:
> On Thu, 2006-12-28 at 13:01 -0500, Stephen Frost wrote:
> > * Joshua D. Drake (jd@commandprompt.com) wrote:
> > > What is the consideration here? I read the thread and it appears that
> > > OpenSSL is not compatible with GPL? But we don't care about that right?
> > > The OpenSSL looks pretty BSDish to me, expect the advertising clause (is
> > > that what caused XFree86.org to fork?).
> > OpenSSL isn't compatible with the GPL.
With few exceptions, you cannot derive or include GPL software in your
non-GPL software. The GPL works very hard to maintain this position to
"protect" the freedom of the user.
The GPL cannot control how OpenSSL is distributed, though. The OpenSSL
license controls this. I don't see any place in the (short and sweet!)
OpenSSL license that prevents it from being using in GPL software. Are
you reading some particular point in the OpenSSL license that I am not?
PostgreSQL isn't GPL software anyways, and there is certainly nothing
in the OpenSSL license preventing it from being used in PostgreSQL.
If the argument is that the 'whole derived product' must fit the
outter most provided license, then I think you should consider that
PostgreSQL should not include *ANY* GPL software, as any user of
PostgreSQL cannot be guaranteed of the generous freedoms provided by
the PostgreSQL license. Some components are covered by GPL, which is
restrictive compared to PostgreSQL.
Down this path is the impractical, and silly conclusion that all
software must be licensed under the exact same license to be
distributed. An all GPL distribution, for example. While those with a
political agenda such as Richard Stallman would cheer at this result,
those people do not have the power to force this will on us.
The Free Software Foundation provides an LGPL that has fewer restrictions
than GPL, out of recognition that their political goals are not practical
for all uses. LGPL software may be linked with GPL software without
invalidating the GPL rights of the user. GPL applies to the GPL part,
and LGPL applies to the LGPL part. All is well in the world.
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.
Anybody who believes OpenSSL is a problem, must be aware of some
software distribution for which the OpenSSL licensing terms are
unreasonable. I'm not sure who that would be. They ask for
attribution. They ask that their name not be used to promote another
product. They ask that their name not be used in the name of another
product. All of these terms seem fair to me.
> The original discussion stated that well placed attorneys in the market
> feel that the FSF is trying to reach beyond the hands of god on this one
> and that we don't need to worry about it (my words, for actual quote
> read thread ;)).
I agree with Tom - if they really want people to use GNUTLS, why did
they make it have such a different interface?
I recently had to choose between the two for a product at work, and
GNUTLS seemed to fall short in several areas. It was a race between
GNUTLS seeming to having superior documentation vs OpenSSL seeming to
have superior functionality. For my rather complicated requirements,
OpenSSL won out (function is more important than documentation), and
the product using it is about 90% complete. It includes such ugliness
as OpenSSL/C code that needs to load the encrypted private key and
client/server x509 certificates from a Java Keystore (JKS)... Total
fun... :-)
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/
On Thu, Dec 28, 2006 at 02:48:56PM -0500, Stephen Frost wrote:
> I disagree that the only way Postgres should support multiple
> libraries for a given component is if they provide the same API- we
> wouldn't have much in the way of authentication options if that was
> really the case.
I don't believe that was said. However, using two very different APIs
for the exact same purpose, providing the exact same functionality
would seem to require a business case. If fear of litigation over
what seems to be a non-existent point is the only business case, the
position deserves to be challenged.
There are other elements that could be included in the business case.
For example, the documentation for GNUTLS seems to be significantly
better.
I don't like fear mongering. It smells like FUD. :-)
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/
* 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).
*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
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). > > *That's* the issue here, not whatever it is you were arguing against. > Stephen, you write as if there were no legal disagreement about this. But there is, as you well know. My understanding is that most of the non-FSF lawyers who have looked at this think it's not a problem. I am not a lawyer, and AFAIK neither are you. Maybe we all need to stop playing Perry Mason and take some well informed legal advice. cheers andrew
> Stephen, you write as if there were no legal disagreement about this.
> But there is, as you well know. My understanding is that most of the
> non-FSF lawyers who have looked at this think it's not a problem. I am
> not a lawyer, and AFAIK neither are you. Maybe we all need to stop
> playing Perry Mason and take some well informed legal advice.
But Perry Mason was so cool!
>
> cheers
>
> andrew
>
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
* mark@mark.mielke.cc (mark@mark.mielke.cc) wrote: > On Thu, Dec 28, 2006 at 02:48:56PM -0500, Stephen Frost wrote: > > I disagree that the only way Postgres should support multiple > > libraries for a given component is if they provide the same API- we > > wouldn't have much in the way of authentication options if that was > > really the case. > > I don't believe that was said. However, using two very different APIs > for the exact same purpose, providing the exact same functionality > would seem to require a business case. If fear of litigation over > what seems to be a non-existent point is the only business case, the > position deserves to be challenged. > > There are other elements that could be included in the business case. > For example, the documentation for GNUTLS seems to be significantly > better. I havn't done serious comparisons of the two since the license issue matters to me, honestly, so this can be taken with a grain of salt, but... OpenSSL has more features and some niceties like the TLS_CACERTDIR (I've asked for this in GNUTLS, actually, so it mighthave it soon) They can each be faster than the other in some instances (I'm not sure which though, I've heard of 15% differences in eachdirection depending on architecture though) GNUTLS has a nicer/better API GNUTLS has a smaller memory footprint OpenSSL is working to get NIST certification/approval (it had it, but then lost it for some reason and they're working toget that fixed) GNUTLS has better documentation Actually, from a comparison done for libcurl (which supports both): GnuTLS vs OpenSSLWhile these two libraries offer similar features, they are not equal. Bothlibraries have features the otherone lacks. libcurl does not (yet) offer astandardized stable ABI if you decide to switch from using libcurl-openssltolibcurl-gnutls or vice versa. The GnuTLS support is very recent in libcurland it has not been tested norused very extensively, while the OpenSSLequivalent code has been used and thus matured for more than seven (7) years. GnuTLS - LGPL licensened - supports SRP - lacks SSLv2 support - lacks MD2 support (used by at least some CA certs) -lacks the crypto functions libcurl uses for NTLM OpenSSL - Original BSD licensened - lacks SRP - supports SSLv2 - older and more widely used - provides crypto functionslibcurl uses for NTLM - libcurl can do non-blocking connects with it in 7.15.4 and later That was from May 15, 2006: http://curl.mirrors.cyberservers.net/legal/distro-dilemma.html Regarding SSLv2 support, the GNUTLS page has this: Support for TLS 1.1, TLS 1.0 and SSL 3.0 protocols * Since SSL 2.0 is insecure it is not supported. * TLS 1.2 is supported in the experimental branch. > I don't like fear mongering. It smells like FUD. :-) While I didn't intend it as fear mongering I can understand that might be the impression whenever licenses and possible license violations are brought up. I don't know of anyone who's actually attempting to prosecute this nor do I generally expect someone to in the future. Even so though, it wouldn't be a PostgreSQL issue anyway but rather an issue for someone distributing OpenSSL and some GPL application which linked against it (ie: a distribution like Debian). Thanks, Stephen
* Andrew Dunstan (andrew@dunslane.net) wrote:
> Stephen Frost wrote:
> >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.
>
> Stephen, you write as if there were no legal disagreement about this.
I was trying to explain the issue as I understood it. I'm happy to
admit that not everyone feels this is an issue (in fact, I've said as
much elsewhere in this thread). That doesn't mean there aren't some who
*do* feel it's an issue though.
> But there is, as you well know. My understanding is that most of the
> non-FSF lawyers who have looked at this think it's not a problem. I am
> not a lawyer, and AFAIK neither are you. Maybe we all need to stop
> playing Perry Mason and take some well informed legal advice.
I'm certainly not a lawyer and I'd be astounded if anyone felt I
represented myself as such. I don't have opinions from any lawyers
beyond Tom's comments previously from RH's legal team and FSF's comments
on the issue. I don't know where the 'most of the non-FSF lawyers'
claim comes from, if you're aware of others who have commented on it I'd
be happy to listen to them. I do know that this has been an issue for
Debian for quite some time and it seems rather unlikely that Debian's
position on it will change. SPI does have a pro-bono lawyer but I
don't know that this question has been posed to him, probably because
the general consensus among the Debian Powers that Be is that it is an
issue and we try to not bother our pro-bono lawyer too much (being, uh,
pro-bono and all).
Thanks,
Stephen
Stephen Frost wrote: >> My understanding is that most of the >> non-FSF lawyers who have looked at this think it's not a problem. I am >> not a lawyer, and AFAIK neither are you. Maybe we all need to stop >> playing Perry Mason and take some well informed legal advice. >> > > I'm certainly not a lawyer and I'd be astounded if anyone felt I > represented myself as such. I don't have opinions from any lawyers > beyond Tom's comments previously from RH's legal team and FSF's comments > on the issue. I don't know where the 'most of the non-FSF lawyers' > claim comes from, if you're aware of others who have commented on it I'd > be happy to listen to them. I said that was my understanding, not that I had direct knowledge of it. But maybe I'm wrong. > I do know that this has been an issue for > Debian for quite some time and it seems rather unlikely that Debian's > position on it will change. SPI does have a pro-bono lawyer but I > don't know that this question has been posed to him, probably because > the general consensus among the Debian Powers that Be is that it is an > issue and we try to not bother our pro-bono lawyer too much (being, uh, > pro-bono and all). > I have a sneaking suspicion that there are some hidden agendas in all this. I agree with this comment from Steve Langasek at http://lists.debian.org/debian-legal/2003/01/msg00022.html : > Sure, code can be rewritten to use gnutls natively. But I don't > understand why anyone would consider this a useful expenditure of > developer resources when the necessary OpenSSL compat glue could simply > be made available under the LGPL. > > If this is such an issue, why hasn't somebody done that? cheers andrew
On Thu, Dec 28, 2006 at 05:16:58PM -0500, Andrew Dunstan wrote: > I agree with this comment from Steve Langasek at > http://lists.debian.org/debian-legal/2003/01/msg00022.html : > > >Sure, code can be rewritten to use gnutls natively. But I don't > >understand why anyone would consider this a useful expenditure of > >developer resources when the necessary OpenSSL compat glue could simply > >be made available under the LGPL. > > If this is such an issue, why hasn't somebody done that? Maybe because the OpenSSL interface is terrible? I'm not sure if it's actually possible to emulate the OpenSSL interface, given the way the libraries work internally are completely different. There is an OpenSSL compatability layer, but postgres won't compile with it because it's nowhere near complete enough, even for the simple things postgres wants to do. However, in this case we're talking about code that has already been written. So the work has already been done... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
* Andrew Dunstan (andrew@dunslane.net) wrote: > Stephen Frost wrote: > >I do know that this has been an issue for > >Debian for quite some time and it seems rather unlikely that Debian's > >position on it will change. SPI does have a pro-bono lawyer but I > >don't know that this question has been posed to him, probably because > >the general consensus among the Debian Powers that Be is that it is an > >issue and we try to not bother our pro-bono lawyer too much (being, uh, > >pro-bono and all). > > > > I have a sneaking suspicion that there are some hidden agendas in all this. I'm certainly not aware of any personally. I doubt Debian in general does either since this isn't exactly a fun thing for us to have to deal with. > I agree with this comment from Steve Langasek at > http://lists.debian.org/debian-legal/2003/01/msg00022.html : Unfortunately, the glue hasn't been made available under the LGPL. While I agree with Steve generally (and in fact have been discussing this whole bit with him on IRC), in this case he's right but the point is moot- it *could* be done, but it *hasn't* been done. The options are to go ask the original author about relicensing it (which I think has actually been done already) or rewriting it (which apparently hasn't been done). > >Sure, code can be rewritten to use gnutls natively. But I don't > >understand why anyone would consider this a useful expenditure of > >developer resources when the necessary OpenSSL compat glue could simply > >be made available under the LGPL. > > If this is such an issue, why hasn't somebody done that? Based on what I've seen happen to date it appears that projects would rather just include GNUTLS support directly than write a wrapper to support the OpenSSL API using GNUTLS. Indeed, that's exactly the approach Martijn took as well. My guess as to why this would be is that it's simply not *that* difficult to do and maintain, and in the end perhaps some prefer the GNUTLS API over the OpenSSL API, or feel that more things are moving in that direction. I don't know, I can't speak for them so I'm really just speculating, but the empirical evidence is that projects support GNUTLS and there doesn't exist a non-GPL OpenSSL API for GNUTLS yet. I understand that at least some GPL projects do use the GPL OpenSSL API for GNUTLS but it's not common. (fe: I know exim4, elinks, mutt, samba, curl/libcurl, and others support GNUTLS directly while the only project I've heard of using the wrapper is slrn, cupsys used the compat layer at one point but then changed to using GNUTLS directly). Maybe people feel that using a compat layer is uglier than using GNUTLS directly? Thanks, Stephen
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/
* mark@mark.mielke.cc (mark@mark.mielke.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
seesome distinction)
c) Authors of GPL code are very unlikely to prosecute such a claim since OpenSSL *is* OSS and does abide by the DFSG
(Iwonder 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,
kindof 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
areadditional restrictions in its license (probably the most practical argument, but not sure it'd hold up when
that'dbasically 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
Stephen Frost <sfrost@snowman.net> writes:
> 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.
Stephen, let me explain *exactly* why I think this is horsepucky.
libjpeg, my other major open-source project, has always been shipped
under a BSD-ish license that includes an "advertising" clause; I quote:
: (2) If only executable code is distributed, then the accompanying
: documentation must state that "this software is based in part on the work of
: the Independent JPEG Group".
Curiously, every single GPL-license web browser in the world uses
libjpeg. Until I see a widespread willingness to remove JPEG support in
GPL-licensed software, and/or somebody providing a pure-GPL replacement
for libjpeg, I am not going to take this argument seriously. There is
exactly zero meaningful difference between the libjpeg license terms and
the OpenSSL terms, but where is the pushback on libjpeg? I have not
seen any, in all the years I worked on that project.
(At one point RMS did make a half-hearted attempt to get me to relicense
libjpeg as GPL, but I have never seen any indication whatsoever that
anyone else cared.)
regards, tom lane
On Thu, Dec 28, 2006 at 09:34:05PM -0500, Stephen Frost wrote:
> * mark@mark.mielke.cc (mark@mark.mielke.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
thefollowing 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@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/
mark@mark.mielke.cc wrote: > 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. I think the issue revolves around the conditions that GPL stipulates about "linking against" libraries requiring the entire product to be *distributed* as GPL, even if components have differing licenses. This is the so-called "viral" clause that gets much attention! Now as Tom pointed out, I dunno why OpenSSL suddenly gets so much attention, but anyway, just trying to clarify why *in principle* that Stephen F is talking about a valid *possible* interpretation of the licensing maze... Cheers Mark
On 12/29/06, Stephen Frost wrote: > > 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. > 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). Considering that the problem is caused by the choice for a license so restrictive it prohibits linking to OpenSSL, I think a license exception in said restrictive license is exactly the right way for Debian to solve their problem. Jochem
On Fri, Dec 29, 2006 at 12:08:37AM -0500, Tom Lane wrote: > Stephen, let me explain *exactly* why I think this is horsepucky. > > libjpeg, my other major open-source project, has always been shipped > under a BSD-ish license that includes an "advertising" clause; I quote: > > : (2) If only executable code is distributed, then the accompanying > : documentation must state that "this software is based in part on the work of > : the Independent JPEG Group". That's not an advertising clause, that merely asks that it be mentioned somewhere in the documentation, which is copied along with the rest of the code, so that's not limiting the redisitribution of anything. It also only applies when the source is not distributed, which means for the GPL it's a total non-issue. The OpenSSL licence on the other hand wants any advertising material of any application mentioning the use of SSL to include the acknowledgement. This would include flyers printed for a conference, or the label of the CD that contains it. Surely you can see the difference? > Curiously, every single GPL-license web browser in the world uses > libjpeg. Until I see a widespread willingness to remove JPEG support in > GPL-licensed software, and/or somebody providing a pure-GPL replacement > for libjpeg, I am not going to take this argument seriously. There is > exactly zero meaningful difference between the libjpeg license terms and > the OpenSSL terms, but where is the pushback on libjpeg? I have not > seen any, in all the years I worked on that project. Because there is a very large, very meaningful difference. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
* Martijn van Oosterhout (kleptog@svana.org) wrote:
> On Fri, Dec 29, 2006 at 12:08:37AM -0500, Tom Lane wrote:
> > libjpeg, my other major open-source project, has always been shipped
> > under a BSD-ish license that includes an "advertising" clause; I quote:
> >
> > : (2) If only executable code is distributed, then the accompanying
> > : documentation must state that "this software is based in part on the work of
> > : the Independent JPEG Group".
>
> That's not an advertising clause, that merely asks that it be mentioned
> somewhere in the documentation, which is copied along with the rest of
> the code, so that's not limiting the redisitribution of anything. It
> also only applies when the source is not distributed, which means for
> the GPL it's a total non-issue.
Exactly. There isn't a "only executable code is distributed" case when
GPL code is involved so that clause wouldn't ever apply.
> Because there is a very large, very meaningful difference.
Agreed.
Thanks,
Stephen
On Fri, Dec 29, 2006 at 08:31:34PM +1300, Mark Kirkwood wrote:
> mark@mark.mielke.cc wrote:
> >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.
> I think the issue revolves around the conditions that GPL stipulates
> about "linking against" libraries requiring the entire product to be
> *distributed* as GPL, even if components have differing licenses. This
> is the so-called "viral" clause that gets much attention!
*nod*
This is what people are thinking. It's about direction where the grey zone
starts to occur. GPL is viral in that a GPL-derived product must be GPL.
We're not talking about including GPL code in OpenSSL, though. This is
about OpenSSL as the base library. The GPL cannot stipulate that a GPL
program may only be linked against GPL libraries, or used on a GPL
operating system, on GPL hardware. For example, if GNU coreutils is
compiled for HP-UX. This is "linking against" software that is much
more restrictive than the OpenSSL license. Is Stephen, or the people
whose opinion he is repeating, going to claim that the FSF considers
this an illegal distribution of GNU coreutils?
The GPL can only require that any product *derived* from the work
licensed with the GPL, only be derived from by products which are
themselves GPL.
I'm not that stunned that this is confusing to people. There is so much
invalid information available, and most of us try to stay away from law
as much as possible. It can be overwhelming. :-)
> Now as Tom pointed out, I dunno why OpenSSL suddenly gets so much
> attention, but anyway, just trying to clarify why *in principle* that
> Stephen F is talking about a valid *possible* interpretation of the
> licensing maze...
*nod*
Thanks for the input.
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/
On Fri, Dec 29, 2006 at 09:52:08AM -0500, mark@mark.mielke.cc wrote: > > I think the issue revolves around the conditions that GPL stipulates > > about "linking against" libraries requiring the entire product to be > > *distributed* as GPL, even if components have differing licenses. This > > is the so-called "viral" clause that gets much attention! > We're not talking about including GPL code in OpenSSL, though. This is > about OpenSSL as the base library. The GPL cannot stipulate that a GPL > program may only be linked against GPL libraries, or used on a GPL > operating system, on GPL hardware. For example, if GNU coreutils is > compiled for HP-UX. This is "linking against" software that is much > more restrictive than the OpenSSL license. Is Stephen, or the people > whose opinion he is repeating, going to claim that the FSF considers > this an illegal distribution of GNU coreutils? No, because that falls under the "operating system" exception. Additionally, "linking against" is no problem. It's *distributing* the "linked against" version that gets you in trouble. The GPL doesn't care about *use*, only about distribution. > The GPL can only require that any product *derived* from the work > licensed with the GPL, only be derived from by products which are > themselves GPL. Correct. Additionally it can require that when you *distribute* that compiled GPL program (the compiled version being a derived work of the source), you provide the source to all the libraries used while running it (barring the operating system exception). It couldn't care less what licence is used by those libraries, as long as that licence is compatable with the requirements the GPL has of the source (which is not that the source must be GPL. > I'm not that stunned that this is confusing to people. There is so much > invalid information available, and most of us try to stay away from law > as much as possible. It can be overwhelming. :-) The reason this issue is confusing is because it's nobodies fault. PostgreSQL by itself, no problem. Exim by itself, no problem. OpenSSL, by itself, no problem. It's only when Debian want's to *distribute* a compiled version of Exim linked against libpq while simultaneously complying with all the licences. Now Exim has granted an exception that gets Debian off the hook, but they didn't have to do that. > > Now as Tom pointed out, I dunno why OpenSSL suddenly gets so much > > attention, but anyway, just trying to clarify why *in principle* that > > Stephen F is talking about a valid *possible* interpretation of the > > licensing maze... > > *nod* OpenSSL is a very different beast and one of very very few packages with this problem. See my other message. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
* mark@mark.mielke.cc (mark@mark.mielke.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
advertisingclause 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 someparts)
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
* Martijn van Oosterhout (kleptog@svana.org) wrote:
> On Fri, Dec 29, 2006 at 09:52:08AM -0500, mark@mark.mielke.cc wrote:
> > We're not talking about including GPL code in OpenSSL, though. This is
> > about OpenSSL as the base library. The GPL cannot stipulate that a GPL
> > program may only be linked against GPL libraries, or used on a GPL
> > operating system, on GPL hardware. For example, if GNU coreutils is
> > compiled for HP-UX. This is "linking against" software that is much
> > more restrictive than the OpenSSL license. Is Stephen, or the people
> > whose opinion he is repeating, going to claim that the FSF considers
> > this an illegal distribution of GNU coreutils?
>
> No, because that falls under the "operating system" exception.
> Additionally, "linking against" is no problem. It's *distributing* the
> "linked against" version that gets you in trouble.
>
> The GPL doesn't care about *use*, only about distribution.
Right, if you actually distributed GNU coreutils *and* HP-UX together as
an application, then, yes, that'd be a violation because of the
additional restrictions put on the result by the HP-UX license. If you
distributed GNU coreutils by itself but compiled to run on HP-UX systems
then that's *not* a violation because the HP-UX code isn't being
distributed as part of the application, even though it's linked against
on the resultant system.
> > The GPL can only require that any product *derived* from the work
> > licensed with the GPL, only be derived from by products which are
> > themselves GPL.
>
> Correct. Additionally it can require that when you *distribute* that
> compiled GPL program (the compiled version being a derived work of the
> source), you provide the source to all the libraries used while running
> it (barring the operating system exception). It couldn't care less what
> licence is used by those libraries, as long as that licence is
> compatable with the requirements the GPL has of the source (which is
> not that the source must be GPL.
Right.
> > I'm not that stunned that this is confusing to people. There is so much
> > invalid information available, and most of us try to stay away from law
> > as much as possible. It can be overwhelming. :-)
>
> The reason this issue is confusing is because it's nobodies fault.
Yeah. :( Makes it more frustrating when trying to explain it to people
too.. "It's nothing you did, but..."
> PostgreSQL by itself, no problem. Exim by itself, no problem. OpenSSL,
> by itself, no problem. It's only when Debian want's to *distribute* a
> compiled version of Exim linked against libpq while simultaneously
> complying with all the licences.
(and then having libpq linked against OpenSSL)
> Now Exim has granted an exception that gets Debian off the hook, but
> they didn't have to do that.
Right. If they didn't then it's conceivable that Exim could sue Debian
for violating the GPL license. Not exactly likely to happen but being
cautious it's best to get their explicit approval rather than playing
the "well, we'll just wait and see if they sue us" game.
> > > Now as Tom pointed out, I dunno why OpenSSL suddenly gets so much
> > > attention, but anyway, just trying to clarify why *in principle* that
> > > Stephen F is talking about a valid *possible* interpretation of the
> > > licensing maze...
> >
> > *nod*
>
> OpenSSL is a very different beast and one of very very few packages
> with this problem. See my other message.
Yup. Thankfully... It'd be quite the headache if there were alot of
cases like this. :/
Thanks,
Stephen
Martijn van Oosterhout <kleptog@svana.org> writes:
> On Fri, Dec 29, 2006 at 12:08:37AM -0500, Tom Lane wrote:
>> libjpeg, my other major open-source project, has always been shipped
>> under a BSD-ish license that includes an "advertising" clause; I quote:
>>
>> : (2) If only executable code is distributed, then the accompanying
>> : documentation must state that "this software is based in part on the work of
>> : the Independent JPEG Group".
> That's not an advertising clause,
That's not a fact, that's an opinion, and unless you're a lawyer who's
studied the matter, I don't think your opinion carries much weight.
Admittedly mine doesn't either --- but the point here is that it's
extremely debatable whether there is any real difference between OpenSSL
and other projects that no one is complaining about.
regards, tom lane
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > On Fri, Dec 29, 2006 at 12:08:37AM -0500, Tom Lane wrote:
> >> libjpeg, my other major open-source project, has always been shipped
> >> under a BSD-ish license that includes an "advertising" clause; I quote:
> >>
> >> : (2) If only executable code is distributed, then the accompanying
> >> : documentation must state that "this software is based in part on the work of
> >> : the Independent JPEG Group".
>
> > That's not an advertising clause,
>
> That's not a fact, that's an opinion, and unless you're a lawyer who's
> studied the matter, I don't think your opinion carries much weight.
It doesn't say "All advertising materials ...", that makes it quite
different from the OpenSSL clause. It also has the 'if only executable
code is distributed' conditional, which the OpenSSL clause doesn't.
Sure, I'm not a lawyer, but I'd have a hard time believing the two
clauses so similar as to have the exact same effect with such
differences.
> Admittedly mine doesn't either --- but the point here is that it's
> extremely debatable whether there is any real difference between OpenSSL
> and other projects that no one is complaining about.
Each case is different and is considered seperately. I'm pretty
sure that the libjpeg case has been considered and was found to not be a
problem. While perhaps more cautious than most, Debian isn't actually
out to make all the world GPL or to attempt to brow-beat everyone into
following Stallman. We'd be perfectly happy for OpenSSL to just drop
that clause but otherwise leave the license as BSDish, or even to change
it to a clause such as that above (though if they can change the license
at all, seems like it'd be best to just drop it, but whatever). Were
that to happen we'd stop caring about using GNUTLS (at least, as a
project).
Thanks,
Stephen
> > Now Exim has granted an exception that gets Debian off the hook, but
> > they didn't have to do that.
> Right. If they didn't then it's conceivable that Exim could sue Debian
> for violating the GPL license. Not exactly likely to happen but being
> cautious it's best to get their explicit approval rather than playing
> the "well, we'll just wait and see if they sue us" game.
This is pure FUD, and unacceptable if spoken from a position of
authority. State what you think this theoretical case would be. At
least if you picked GPL including closed source code, you might be
able to claim that the resulting derived work was not distributed
complete with source code. OpenSSL, however, is open source. The only
possible complaint could be "you failed to advertise OpenSSL in the
resulting distributed image", which would be a correct observation,
easily corrected by the inclusion of a note in the documentation for
the distributed software unit that includes both pieces of software.
This correction is an existing requirement for any software
distribution that includes OpenSSL, It is an acceptable, and easily
honoured requirement.
Anybody who has a problem admitting that their software distribution
includes OpenSSL software in their documentation, has no sympathy from
me. Attribution is an acceptable right to enforce under copyright law,
and an honourable practice with or without a licensing requirement
explicitly stating this as a requirement.
Caution to the point of fantasy is a waste of resources. Caution to
further a political agenda (not you - but the people whose opinions you
are repeating) is exploitation.
I am unable to find a single clause in the GPL (which I have analyzed
many years ago, but also re-read several times in the last two days)
that would make it impossible to satisfy all of the GPL, PostgreSQL
(BSD) license, and the OpenSSL license at the same time. Every single
clause of all three licenses can be easily satisfied without conflict.
Those of you who are claiming otherwise, have failed to point to a
single phrase in the GPL that could not be satisfied when distributing
all three pieces of software as a single unit. Without a single point
of true conflict between all three licenses, I do not accept that
there is any case to require an OpenSSL exemption clause for
Debian. Those who are doing so are doing a disservice to everyone by
contributing to the general confusion on this subject. The clause is
not required. The clause has no effect.
To distribute a software unit that includes software from all of a
GPL product, PostgreSQL, and OpenSSL, one needs only do the following:
1) Documentation for the software unit should include documentation to describe that the software includes
OpenSSL.
2) The distribution of the software unit should include a text copy of all three licenses.
3) Source code for the entire unit should be provided. I don't believe the FSF can legally enforce this
requirement,however, with GPL + PostgreSQL + OpenSSL, there is *NO* conflict. The source code for all three
canbe made available upon request, or contained within the distribution.
4) Various other minor points, such as the requirement that changes are dated and such. None of which conflict
betweenthe three licenses.
To state again. There is *NO* conflict between the licenses. The terms
of each can be fulfilled completely, and separately, without
invalidating each other. Those who claim otherwise need to point to a
specific requirement from one of the licenses that would prevent it
from being used. They cannot, because such a point does not
exist. Ascii pictures. Hearsay. Confusion regarding existing practice
or existing thoughts on the matter. No single point of conflict has
been raised. The GPL does not state that "GPL software may not derive
from software that has an advertising clause." Considering that this
is the primary point raised by people, it is ironic that the GPL has
no such restriction.
Be honest about it. *You* don't like the advertising clause. The GPL
has nothing to say on the issue, and therefore is *NOT* in conflict
with it.
This thread has re-enforced my conclusion that the GPL is a poor choice
of license for any product I ever work on in the future. A decade ago,
as a teenager, I thought it was cool to put GPL on the software that I
made available to the world. I felt like I was part of something bigger.
Now I just feel disgusted. The GPL is not about freedom. It is about
enforcing a world view on all who use your software.
Thank you PostgreSQL contributors for choosing the BSD style. I think
it was an excellent choice.
This is my last contribution to this thread. I've said my piece. Note
that I don't intend to convert all of you. As this issue is primarily
political, people will have a tendency to stay with their own camp,
regardless of what is said. We all have a tendencies to read each others
words, looking only for fault in what is said, purposefully choosing not
to assimilate the other persons contribution. It's called the "I am right
you are wrong" syndrome, and I'm not exempt from it.
I hope I provided value to this discussion. If not, I apologize.
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/
On 12/29/06, Stephen Frost wrote: > 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). My question is whom is going to sue whom? And if so would they win? And if they win, will they win a crippling amount? Will the folks at exim sue? Not likely, they make free software that is DESIGNED to work with OpenSSL. "Exim can be built to support encrypted SMTP connections... Before you can do this, you must install the OpenSSL library, which Exim uses for this purpose." Will they win if they sue? Not likely, there are probably lots of long legal terms (like latches, estoppal) that can be used in a defense. You can't go and build software specifically designed to use something, and over the course of years dupe people into using it only to go, ta-da, busted for "additional GPL restrictions". And even if you succeed in this, you're not going to win big bucks. Perhaps you can simply prevent people from using your software. Given that using your software in the form you distribute it requires openssl, and you've sued people for using openssl with it, it's likely *no one* is going to use your software. And if you continue to dupe people into using your software and then suing them, you'd run some legal risks yourself. I mean, the theory of this legal case that debian people build seems terrible to me! Any case with this many highly unlikely AND clauses and such horrible outcomes for everyone seems unlikely to happen AND be won AND result in significant harm. If you don't like the advertising clause of openssl that is fine, avoid using software that uses it etc etc. But I think the debian hype of various forms of legal jeopardy goes a bit far, and does smell a bit FUDish. Fun to follow though. And if there is a nice implementation of GNUTLS that succeeds on the technical merits, no objection there either. - August
* mark@mark.mielke.cc (mark@mark.mielke.cc) wrote:
> > > Now Exim has granted an exception that gets Debian off the hook, but
> > > they didn't have to do that.
> > Right. If they didn't then it's conceivable that Exim could sue Debian
> > for violating the GPL license. Not exactly likely to happen but being
> > cautious it's best to get their explicit approval rather than playing
> > the "well, we'll just wait and see if they sue us" game.
>
> This is pure FUD, and unacceptable if spoken from a position of
> authority. State what you think this theoretical case would be. At
I've made it clear previously, but sure, why not. The case would be
something along the lines of Exim sueing Debian for building a
derivative (Exim w/ OpenSSL) which violated the terms of distribution of
Exim (GPL) which means Debian would be breaking copyright law by
distributing the resulting application.
With copyright law you have to show that you *have* the right, and
anything which is done against the license which gives you that right
which nullifies the license means you don't get to distribute the work,
at all. There's really not a whole lot more to it than that, and
there's nothing FUDdy about it.
> least if you picked GPL including closed source code, you might be
> able to claim that the resulting derived work was not distributed
> complete with source code. OpenSSL, however, is open source. The only
The GPL requires more than just being 'open source'.
> possible complaint could be "you failed to advertise OpenSSL in the
> resulting distributed image", which would be a correct observation,
No, a complaint could be "you didn't honor the terms of the GPL under
which you received the rights to distribute the work."
> easily corrected by the inclusion of a note in the documentation for
> the distributed software unit that includes both pieces of software.
> This correction is an existing requirement for any software
> distribution that includes OpenSSL, It is an acceptable, and easily
> honoured requirement.
Yet *having* that requirement on a *derived work* which includes GPL
code is *against* the terms of the GPL. That's *exactly* the issue.
The GPL says more than "you must provide the source code to everything",
it explicitly includes a requirement that no additional restrictions be
put on the derivative (lest requirements for no-additional-distribution
or must-charge-for-other-distribution be added which defeats much of the
point of the GPL).
> Anybody who has a problem admitting that their software distribution
> includes OpenSSL software in their documentation, has no sympathy from
> me. Attribution is an acceptable right to enforce under copyright law,
> and an honourable practice with or without a licensing requirement
> explicitly stating this as a requirement.
That's nice, it's got nothing to do with the conversation at hand, and
might even be FUD based on how you've used that term previously. :)
It's certainly rather frustrating to get these constant attacks during
this conversation where you put up something I'm not advocating and then
say "only bad people would say such things!"
> Caution to the point of fantasy is a waste of resources. Caution to
> further a political agenda (not you - but the people whose opinions you
> are repeating) is exploitation.
I don't believe Debian has any kind of political agenda in this regard.
Debian's agenda is to follow the licenses as best it can. While that
may go beyond what others feel like doing it's a good goal to have.
> I am unable to find a single clause in the GPL (which I have analyzed
> many years ago, but also re-read several times in the last two days)
> that would make it impossible to satisfy all of the GPL, PostgreSQL
> (BSD) license, and the OpenSSL license at the same time. Every single
> clause of all three licenses can be easily satisfied without conflict.
> Those of you who are claiming otherwise, have failed to point to a
> single phrase in the GPL that could not be satisfied when distributing
> all three pieces of software as a single unit. Without a single point
> of true conflict between all three licenses, I do not accept that
> there is any case to require an OpenSSL exemption clause for
> Debian. Those who are doing so are doing a disservice to everyone by
> contributing to the general confusion on this subject. The clause is
> not required. The clause has no effect.
Well, I pointed it out to you before but you seem to have happily
ignored it so I'll provide it again here, perhaps more clearly:
---
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.
---
---
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
---
There you have it. "You may not impose any further restrictions on the
recipients' exercise of the rights granted herein." That's exactly what
the OpenSSL advertising clause does- imposes a further restriction on
the execricse of the rights granted. That's exactly what makes
distributing a whole (comprised of both GPL'd code and OpenSSL) which
grants the permissions for other licensees in the GPL without further
restriction impossible.
> been raised. The GPL does not state that "GPL software may not derive
> from software that has an advertising clause." Considering that this
> is the primary point raised by people, it is ironic that the GPL has
> no such restriction.
Erm, it doesn't need one, it's got a blanket statement, as quoted above.
> Be honest about it. *You* don't like the advertising clause. The GPL
> has nothing to say on the issue, and therefore is *NOT* in conflict
> with it.
See above, heh.
> This thread has re-enforced my conclusion that the GPL is a poor choice
> of license for any product I ever work on in the future. A decade ago,
> as a teenager, I thought it was cool to put GPL on the software that I
> made available to the world. I felt like I was part of something bigger.
> Now I just feel disgusted. The GPL is not about freedom. It is about
> enforcing a world view on all who use your software.
Yay, so you don't like the GPL, doesn't sound like it's got alot to do
with what I like or don't after all. :)
> Thank you PostgreSQL contributors for choosing the BSD style. I think
> it was an excellent choice.
I'm a fan of newBSD (w/o the advertising clause) myself, actually. :)
Thanks,
Stephen
> > Caution to the point of fantasy is a waste of resources. Caution to
> > further a political agenda (not you - but the people whose opinions you
> > are repeating) is exploitation.
>
> I don't believe Debian has any kind of political agenda in this regard.
> Debian's agenda is to follow the licenses as best it can. While that
> may go beyond what others feel like doing it's a good goal to have.
Actually everything about Debian (the project) is a political agenda.
That doesn't mean that it is invalid though.
That being said, this topic is WAY OFF-TOPIC for the discussion. The
discussion is:
Will we accept GNU TLS.
Currently there has not been one technical argument that is valid to
have us include GNU TLS.
Now is their a legal argument? Maybe, but until an *attorney* states
that there is an issue this is all m00t.
Speaking of which I am going to bounce of to SPI and see if we can get
an actual answer to this.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
* August Zajonc (augustz@augustz.com) wrote: > On 12/29/06, Stephen Frost wrote: > > 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). > > My question is whom is going to sue whom? And if so would they win? And if > they win, will they win a crippling amount? > > Will the folks at exim sue? Not likely, they make free software that is > DESIGNED to work with OpenSSL. I don't see that anyone is all that terribly *likely* to sue. Even so, it's best to follow the licenses under which we receive the rights to distribute the software as best we can. I can't say if they chose to sue if they'd win or not, I'd tend to doubt it based on such claims as those you describe but that doesn't mean I'm really all that anxious to actually find out for sure. > "Exim can be built to support encrypted SMTP connections... Before you can do > this, you must install the OpenSSL library, which Exim uses for this purpose." > > Will they win if they sue? Not likely, there are probably lots of long legal > terms (like latches, estoppal) that can be used in a defense. You can't go and > build software specifically designed to use something, and over the course of > years dupe people into using it only to go, ta-da, busted for "additional GPL > restrictions". No, Exim may have been a poor choice as an example, there's other GPL software which doesn't use OpenSSL directly but which does link against libpq. Even so though, our goal is to follow the licenses as best we can, not try to justify not following our understanding of the license based on the likelihood of a successful suit. > And even if you succeed in this, you're not going to win big bucks. Perhaps > you can simply prevent people from using your software. Given that using your > software in the form you distribute it requires openssl, and you've sued > people for using openssl with it, it's likely *no one* is going to use your > software. And if you continue to dupe people into using your software and then > suing them, you'd run some legal risks yourself. Unfortuantely, for many of us, just having to deal with a court at all implies a 'big bucks' cost. > I mean, the theory of this legal case that debian people build seems terrible > to me! > > Any case with this many highly unlikely AND clauses and such horrible outcomes > for everyone seems unlikely to happen AND be won AND result in significant harm. > > If you don't like the advertising clause of openssl that is fine, avoid using > software that uses it etc etc. But I think the debian hype of various forms of > legal jeopardy goes a bit far, and does smell a bit FUDish. It'd only be jeopardy for Debian in any case... We'd just like to avoid the possibility by following the licenses as best we understand them. As for my personal feeling on the advertising clause, I'm not really a fan of it but at the same time it doesn't bother me all that much. We havn't got any choice if we want to use PostgreSQL w/ SSL though, do we? > Fun to follow though. And if there is a nice implementation of GNUTLS that > succeeds on the technical merits, no objection there either. As I posted about elsewhere, there are features in GNUTLS which aren't in OpenSSL, and vice-versa, along with claims of speed improvments from one over the other depending on platform. Also as mentioned last time this was brought up, GNUTLS is being used in quite a few different areas of Debian and has proven to work quite reasonably. (http://www.webservertalk.com/archive307-2006-4-1456230.html) Thanks, Stephen
* Joshua D. Drake (jd@commandprompt.com) wrote: > Actually everything about Debian (the project) is a political agenda. > That doesn't mean that it is invalid though. *smirk > That being said, this topic is WAY OFF-TOPIC for the discussion. The > discussion is: > > Will we accept GNU TLS. > > Currently there has not been one technical argument that is valid to > have us include GNU TLS. Well, perhaps you weren't following everything but I did try to bring up a couple points about GNUTLS vs. OpenSSL which I'll mention again here where more people might actually notice it, heh: OpenSSL has more features and some niceties like the TLS_CACERTDIR (I've asked for this in GNUTLS, actually, so it mighthave it soon) They can each be faster than the other in some instances (I'm not sure which though, I've heard of 15% differences in eachdirection depending on architecture though) GNUTLS has a nicer/better API GNUTLS has a smaller memory footprint OpenSSL is working to get NIST certification/approval (it had it, but then lost it for some reason and they're working toget that fixed) GNUTLS has better documentation Actually, from a comparison done for libcurl (which supports both): GnuTLS vs OpenSSLWhile these two libraries offer similar features, they are not equal. Bothlibraries have features the otherone lacks. libcurl does not (yet) offer astandardized stable ABI if you decide to switch from using libcurl-openssltolibcurl-gnutls or vice versa. The GnuTLS support is very recent in libcurland it has not been tested norused very extensively, while the OpenSSLequivalent code has been used and thus matured for more than seven (7)years. GnuTLS - LGPL licensened - supports SRP - lacks SSLv2 support - lacks MD2 support (used by at least some CA certs) -lacks the crypto functions libcurl uses for NTLM OpenSSL - Original BSD licensened - lacks SRP - supports SSLv2 - older and more widely used - provides crypto functionslibcurl uses for NTLM - libcurl can do non-blocking connects with it in 7.15.4 and later That was from May 15, 2006: http://curl.mirrors.cyberservers.net/legal/distro-dilemma.html Regarding SSLv2 support, the GNUTLS page has this: Support for TLS 1.1, TLS 1.0 and SSL 3.0 protocols * Since SSL 2.0 is insecure it is not supported. * TLS 1.2 is supported in the experimental branch. > Now is their a legal argument? Maybe, but until an *attorney* states > that there is an issue this is all m00t. > > Speaking of which I am going to bounce of to SPI and see if we can get > an actual answer to this. That would be interesting to find out. I'm kind of suprised it wasn't brought up before so that we could say "well, from our understanding of what our lawyer said..." or something along those lines. Thanks, Stephen
On Fri, Dec 29, 2006 at 10:32:34AM -0800, Joshua D. Drake wrote:
> Currently there has not been one technical argument that is valid to
> have us include GNU TLS.
1) The normal freedom that not being tied down to a single product provides. The same reason somebody might build
MySQL+ PostgreSQL support into their product. It usually forces a generic abstraction to be used, which may be a long
terminvestment into a better code base within PostgreSQL.
2) Documentation is much better in GNUTLS. When using OpenSSL, I find myself frequently referring to the source code
itself,as the best documentation available is for the now-possibly-out-of-date SSLeay.
3) Due to various political agendas, and legal confusion, GNUTLS has been steadily growing in popularity. One day it
maybe that GNUTLS is better maintained and well known than OpenSSL, at which point it might be a practical choice to
onlysupport GNUTLS, and drop support for OpenSSL entirely.
4) GNUTLS development seems more active? OpenSSL has been in a frozen/mature state for a while. I don't understand why
OpenSSLis still labelled as 0.9.x, which might indicate alpha quality, under heavy development.
I don't find the reasons too compelling - but they are points to
consider.
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/
> entirely.
>
> 4) GNUTLS development seems more active? OpenSSL has been in a frozen/mature
> state for a while. I don't understand why OpenSSL is still labelled as
> 0.9.x, which might indicate alpha quality, under heavy development.
>
> I don't find the reasons too compelling - but they are points to
> consider.
5) GNUTLS does not run well under all of our supported platforms.
Joshua D. Drake
>
> Cheers,
> mark
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
* Joshua D. Drake (jd@commandprompt.com) wrote:
> > 4) GNUTLS development seems more active? OpenSSL has been in a frozen/mature
> > state for a while. I don't understand why OpenSSL is still labelled as
> > 0.9.x, which might indicate alpha quality, under heavy development.
> >
> > I don't find the reasons too compelling - but they are points to
> > consider.
>
> 5) GNUTLS does not run well under all of our supported platforms.
While I don't disagree about that, I would like to reiterate that I
wouldn't advocate or even suggest dropping OpenSSL support or removing
OpenSSL as the default.
Thanks,
Stephen
On Friday 29 December 2006 14:49, Joshua D. Drake wrote:
> > entirely.
> >
> > 4) GNUTLS development seems more active? OpenSSL has been in a
> > frozen/mature state for a while. I don't understand why OpenSSL is still
> > labelled as 0.9.x, which might indicate alpha quality, under heavy
> > development.
> >
> > I don't find the reasons too compelling - but they are points to
> > consider.
>
> 5) GNUTLS does not run well under all of our supported platforms.
>
given options like --enable-dtrace and --with-libedit-preferred, I don't find
this argument compelling...
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
On Fri, 2006-12-29 at 17:57 -0500, Robert Treat wrote:
> On Friday 29 December 2006 14:49, Joshua D. Drake wrote:
> > > entirely.
> > >
> > > 4) GNUTLS development seems more active? OpenSSL has been in a
> > > frozen/mature state for a while. I don't understand why OpenSSL is still
> > > labelled as 0.9.x, which might indicate alpha quality, under heavy
> > > development.
> > >
> > > I don't find the reasons too compelling - but they are points to
> > > consider.
> >
> > 5) GNUTLS does not run well under all of our supported platforms.
> >
>
> given options like --enable-dtrace and --with-libedit-preferred, I don't find
> this argument compelling...
I don't like either of those options either.
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
* Joshua D. Drake (jd@commandprompt.com) wrote:
> On Fri, 2006-12-29 at 17:57 -0500, Robert Treat wrote:
> > On Friday 29 December 2006 14:49, Joshua D. Drake wrote:
> > given options like --enable-dtrace and --with-libedit-preferred, I don't find
> > this argument compelling...
>
> I don't like either of those options either.
What about --with-pam, --with-ldap, --with-gnu-ld ? I also wonder
about --with-tcl, --with-perl, --with-python, --with-krb5.. We
do support quite a few platforms...
Thanks,
Stephen
On Fri, 2006-12-29 at 18:56 -0500, Stephen Frost wrote:
> * Joshua D. Drake (jd@commandprompt.com) wrote:
> > On Fri, 2006-12-29 at 17:57 -0500, Robert Treat wrote:
> > > On Friday 29 December 2006 14:49, Joshua D. Drake wrote:
> > > given options like --enable-dtrace and --with-libedit-preferred, I don't find
> > > this argument compelling...
> >
> > I don't like either of those options either.
>
> What about --with-pam, --with-ldap, --with-gnu-ld ? I also wonder
> about --with-tcl, --with-perl, --with-python, --with-krb5.. We
> do support quite a few platforms...
I do not like --enable-dtrace because it is a Solaris only thing and a
waste of maintability resources (although small).
I do not like --with-libedit-preferred because I think it should be
--with-libedit and readline should be ripped out.
I do not like --with-krb5 because it has extremely limited real world
use.
I do not like --with-tcl because well... it is tcl
I do not like --with-pam but only because I have never gotten it to
work.
I do like --with-python because all other languages are inferior.
I do like --with-ldap because it is pretty much standard within
directory lookups by the nature of Active Directory.
I do not like "Green Eggs and Ham", said Sam I am.
Sincerely,
Joshua D. Drake
>
> Thanks,
>
> Stephen
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
* Joshua D. Drake (jd@commandprompt.com) wrote:
> I do not like --enable-dtrace because it is a Solaris only thing and a
> waste of maintability resources (although small).
While the analysis can only be done on Solaris I feel that improvments
from the analysis may be useful on other platforms. For that I don't
feel it's a waste of resources.
> I do not like --with-libedit-preferred because I think it should be
> --with-libedit and readline should be ripped out.
Not all that particular on this one as long as my psql works well. :) I
do like the improvments in 8.2 too.
> I do not like --with-krb5 because it has extremely limited real world
> use.
Riiigghhhttt... Only every Windows setup which uses Active Directory,
most major universities, and certain large corporations (uh, AOL?) would
even think to use something like Kerberos!
> I do not like --with-tcl because well... it is tcl
Haha.
> I do not like --with-pam but only because I have never gotten it to
> work.
We use it on some of our production systems (since it can provide
cracklib, password expiration, etc, and the postgres instance inside
it's own vserver so it doesn't hurt as much to make the passwd/shadow
files available to it...). I'd be happy to help you get it to work if
you'd like, and I could even provide you with some PG/C functions to use
password changing and password aging. :)
> I do like --with-python because all other languages are inferior.
haha.
> I do like --with-ldap because it is pretty much standard within
> directory lookups by the nature of Active Directory.
Funny you like LDAP but not Kerberos, both of which are part of Active
Directory... Using LDAP simple binds to AD for authentication is
*quite* silly and *much* less secure than using Kerberos...
> I do not like "Green Eggs and Ham", said Sam I am.
hehe.
Thanks,
Stephen
> > I do not like --with-krb5 because it has extremely limited real world
> > use.
>
> Riiigghhhttt... Only every Windows setup which uses Active Directory,
> most major universities, and certain large corporations (uh, AOL?) would
> even think to use something like Kerberos!
I said "Extremely Limited" real world use. Between just two of my
customers, in the next 2 years we (CMD) will have 12 thousand postgresql
installations. Not one of them will use Kerberos.
>
> > I do not like --with-pam but only because I have never gotten it to
> > work.
>
> We use it on some of our production systems (since it can provide
> cracklib, password expiration, etc, and the postgres instance inside
> it's own vserver so it doesn't hurt as much to make the passwd/shadow
> files available to it...). I'd be happy to help you get it to work if
> you'd like, and I could even provide you with some PG/C functions to use
> password changing and password aging. :)
Oh, I am sure it is great. I have just never tried that hard to get it
to work :)
> > I do like --with-ldap because it is pretty much standard within
> > directory lookups by the nature of Active Directory.
>
> Funny you like LDAP but not Kerberos, both of which are part of Active
> Directory... Using LDAP simple binds to AD for authentication is
> *quite* silly and *much* less secure than using Kerberos...
Yes but LDAP gives me a lot of other things, easily and it has SSL. SSL
+ Firewall gives me 98% of the security I need.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
On Dec 29, 2006, at 7:09 PM, Joshua D. Drake wrote: > On Fri, 2006-12-29 at 18:56 -0500, Stephen Frost wrote: >> * Joshua D. Drake (jd@commandprompt.com) wrote: >>> On Fri, 2006-12-29 at 17:57 -0500, Robert Treat wrote: >>>> On Friday 29 December 2006 14:49, Joshua D. Drake wrote: >>>> given options like --enable-dtrace and --with-libedit-preferred, >>>> I don't find >>>> this argument compelling... >>> >>> I don't like either of those options either. >> >> What about --with-pam, --with-ldap, --with-gnu-ld ? I also wonder >> about --with-tcl, --with-perl, --with-python, --with-krb5.. We >> do support quite a few platforms... > > I do not like --enable-dtrace because it is a Solaris only thing and a > waste of maintability resources (although small). It works on solaris, opensolaris, all the distributions based on opensolaris. It should work in the next version of Mac OS X and most likely in the next version of FreeBSD. The dtrace allows people to answer questions on production systems that were otherwise mysteries. I think it is not a waste at all. > I do not like --with-libedit-preferred because I think it should be > --with-libedit and readline should be ripped out. > > I do not like --with-krb5 because it has extremely limited real world > use. I see quite a bit of kerberos in the Enterprise world. > I do not like --with-tcl because well... it is tcl > > I do not like --with-pam but only because I have never gotten it to > work. > > I do like --with-python because all other languages are inferior. > > I do like --with-ldap because it is pretty much standard within > directory lookups by the nature of Active Directory. > > I do not like "Green Eggs and Ham", said Sam I am. I don't understand why this has devolved into an argument about what people do and don't like. It's like specifically choosing a forum that will have the most disagreement. // Theo Schlossnagle // CTO -- http://www.omniti.com/~jesus/ // OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
> > I don't understand why this has devolved into an argument about what > people do and don't like. It's like specifically choosing a forum > that will have the most disagreement. Yep :), I saw we go over to debian-general and ask why they are trying to make all these projects use GNU/TLS ;) Joshua D. Drake > > // Theo Schlossnagle > // CTO -- http://www.omniti.com/~jesus/ > // OmniTI Computer Consulting, Inc. -- http://www.omniti.com/ > > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
* Joshua D. Drake (jd@commandprompt.com) wrote:
> > > I do not like --with-krb5 because it has extremely limited real world
> > > use.
> >
> > Riiigghhhttt... Only every Windows setup which uses Active Directory,
> > most major universities, and certain large corporations (uh, AOL?) would
> > even think to use something like Kerberos!
>
> I said "Extremely Limited" real world use. Between just two of my
> customers, in the next 2 years we (CMD) will have 12 thousand postgresql
> installations. Not one of them will use Kerberos.
There's no accounting for poor taste...
> > > I do not like --with-pam but only because I have never gotten it to
> > > work.
> >
> > We use it on some of our production systems (since it can provide
> > cracklib, password expiration, etc, and the postgres instance inside
> > it's own vserver so it doesn't hurt as much to make the passwd/shadow
> > files available to it...). I'd be happy to help you get it to work if
> > you'd like, and I could even provide you with some PG/C functions to use
> > password changing and password aging. :)
>
> Oh, I am sure it is great. I have just never tried that hard to get it
> to work :)
Oh, I never said it was great, just said that we used it since PG
doesn't directly provide the things we need (cracklib, password aging,
etc).
> > > I do like --with-ldap because it is pretty much standard within
> > > directory lookups by the nature of Active Directory.
> >
> > Funny you like LDAP but not Kerberos, both of which are part of Active
> > Directory... Using LDAP simple binds to AD for authentication is
> > *quite* silly and *much* less secure than using Kerberos...
>
> Yes but LDAP gives me a lot of other things, easily and it has SSL. SSL
> + Firewall gives me 98% of the security I need.
Unfortunately, security isn't a game of percentages. Hopefully you'll
never have a server compromised which is then used to capture passwords
which can then be used to jump to other systems... Kerberos is there
and it's not too hard to use (though does depend on the MIT Kerberos for
Windows service currently). Supporting SSPI/GSSAPI and then writing a
small document on how to generate Windows keytabs for Postgres would
mean single-sign-on for Windows users using applications which use
libpq...
Thanks,
Stephen
Robert Treat wrote: > On Friday 29 December 2006 14:49, Joshua D. Drake wrote: > > > entirely. > > > > > > 4) GNUTLS development seems more active? OpenSSL has been in a > > > frozen/mature state for a while. I don't understand why OpenSSL is still > > > labelled as 0.9.x, which might indicate alpha quality, under heavy > > > development. > > > > > > I don't find the reasons too compelling - but they are points to > > > consider. > > > > 5) GNUTLS does not run well under all of our supported platforms. > > > > given options like --enable-dtrace and --with-libedit-preferred, I don't find > this argument compelling... Keep in mind it took years to get OpenSSL support up to the level we have it now. It took SSL experts coming in and out of our development process to get it 100% feature-complete. Doing this for another library, I am afraid, isn't trivial, unlike the above options. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Robert Treat wrote: >> > 5) GNUTLS does not run well under all of our supported platforms. >> > >> >> given options like --enable-dtrace and --with-libedit-preferred, I don't >> find >> this argument compelling... > > Keep in mind it took years to get OpenSSL support up to the level we > have it now. It took SSL experts coming in and out of our development > process to get it 100% feature-complete. Doing this for another > library, I am afraid, isn't trivial, unlike the above options. > Not only that, but in every other case of an extra library, it provides us either with more platform support (e.g. libedit) or more functionality (e.g. dtrace). That's not the case here - we would simply be supporting another way of getting the same functionality on platforms where we already have a library that supports it. cheers andrew
Bruce Momjian <bruce@momjian.us> writes:
> Keep in mind it took years to get OpenSSL support up to the level we
> have it now. It took SSL experts coming in and out of our development
> process to get it 100% feature-complete.
Actually, it's *not* feature-complete even yet.
What basically bothers me about this is that trying to support both the
OpenSSL and GNUTLS APIs is going to be an enormous investment of
development and maintenance effort, because it's such a nontrivial thing
to use properly. It sticks in my craw to be doing that work for no
technical reason, only a license-lawyering reason; and not even a
license issue that everyone is convinced is real.
regards, tom lane
On Sat, Dec 30, 2006 at 02:10:42AM -0500, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Keep in mind it took years to get OpenSSL support up to the level we > > have it now. It took SSL experts coming in and out of our development > > process to get it 100% feature-complete. > > Actually, it's *not* feature-complete even yet. What's missing? I don't see anything on the TODO list relating to this. If you wanted a GnuTLS patch that supported more features than the OpenSSL one, you should have said so. Personally I would have added: - authentication using PGP keys - anonymous DH (ie doing encryption, without authentication or shared keys) I refrained because I figured that would give it even less chance of getting accepted. Additionally the patch implemented: - A command in psql so you could see the parameters of the SSL connection - A method by which other client libraries (say JDBC) could use the authentication and encryption features of libpq, but implement the query protocol themselves. > What basically bothers me about this is that trying to support both the > OpenSSL and GNUTLS APIs is going to be an enormous investment of > development and maintenance effort, because it's such a nontrivial thing > to use properly. It sticks in my craw to be doing that work for no > technical reason, only a license-lawyering reason; and not even a > license issue that everyone is convinced is real. As author of the patch, I'm slightly dismayed people are getting so hung up on the licence issue, when it was *not* the main motivation for writing it. And if there's features you want, put them on the todo list. I'm not sure about Bruce's comment about it being so hard to get the OpenSSL level of support we have, given PostgreSQL is not doing anything not described in the example code. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
* Bruce Momjian (bruce@momjian.us) wrote:
> Robert Treat wrote:
> > given options like --enable-dtrace and --with-libedit-preferred, I don't find
> > this argument compelling...
>
> Keep in mind it took years to get OpenSSL support up to the level we
> have it now. It took SSL experts coming in and out of our development
> process to get it 100% feature-complete. Doing this for another
> library, I am afraid, isn't trivial, unlike the above options.
Uhh, I have no idea where you got the idea that our current OpenSSL
support is anywhere near 100% feature complete for an SSL
implementation. It's certainly not, and we've been over that
previously...
Thanks,
Stephen
* Andrew Dunstan (andrew@dunslane.net) wrote:
> Bruce Momjian wrote:
> > Keep in mind it took years to get OpenSSL support up to the level we
> > have it now. It took SSL experts coming in and out of our development
> > process to get it 100% feature-complete. Doing this for another
> > library, I am afraid, isn't trivial, unlike the above options.
>
> Not only that, but in every other case of an extra library, it provides us
> either with more platform support (e.g. libedit) or more functionality
> (e.g. dtrace). That's not the case here - we would simply be supporting
> another way of getting the same functionality on platforms where we
> already have a library that supports it.
As I mentioned previously there are at least some features GNUTLS has
which OpenSSL doesn't (though I don't pretend to know the level of
importance). There is also the license difference (which there *is* a
pretty clear difference in the license between the two, and some might
prefer one or the other, regardless of if there's actually a problem or
not).
Thanks,
Stephen
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Keep in mind it took years to get OpenSSL support up to the level we
> > have it now. It took SSL experts coming in and out of our development
> > process to get it 100% feature-complete.
>
> Actually, it's *not* feature-complete even yet.
>
> What basically bothers me about this is that trying to support both the
> OpenSSL and GNUTLS APIs is going to be an enormous investment of
> development and maintenance effort, because it's such a nontrivial thing
> to use properly. It sticks in my craw to be doing that work for no
> technical reason, only a license-lawyering reason; and not even a
> license issue that everyone is convinced is real.
The development has been done (and wasn't terribly enormous aiui) and I
have a hard time believeing it's a huge maintenance cost. If features
are added wrt SSL they wouldn't have to be added to both, either,
although in general I doubt it'd be all that difficult to support both
from the get-go but there's no obligataion and someone else who cares
about one or the other could implement it there.
Thanks,
Stephen
* Martijn van Oosterhout (kleptog@svana.org) wrote:
> On Sat, Dec 30, 2006 at 02:10:42AM -0500, Tom Lane wrote:
> > Actually, it's *not* feature-complete even yet.
>
> What's missing? I don't see anything on the TODO list relating to
> this. If you wanted a GnuTLS patch that supported more features than
> the OpenSSL one, you should have said so. Personally I would have
> added:
>
> - authentication using PGP keys
This would be the big feature I think is missing from our current SSL
support. I don't think it'd be terribly difficult to support with
either library (I think most of the work would be on the PG user auth
side, which would be useable by either).
> - anonymous DH (ie doing encryption, without authentication or
> shared keys)
Would be nice.
> I refrained because I figured that would give it even less chance of
> getting accepted.
Indeed..
> Additionally the patch implemented:
>
> - A command in psql so you could see the parameters of the SSL
> connection
> - A method by which other client libraries (say JDBC) could use the
> authentication and encryption features of libpq, but implement the
> query protocol themselves.
>
> > What basically bothers me about this is that trying to support both the
> > OpenSSL and GNUTLS APIs is going to be an enormous investment of
> > development and maintenance effort, because it's such a nontrivial thing
> > to use properly. It sticks in my craw to be doing that work for no
> > technical reason, only a license-lawyering reason; and not even a
> > license issue that everyone is convinced is real.
>
> As author of the patch, I'm slightly dismayed people are getting so
> hung up on the licence issue, when it was *not* the main motivation for
> writing it.
I hadn't intended (or expected) the reaction to the licesneing issue to
turn people off to GNUTLS support in general. My intent was more along
the lines of "I figure you'll support it since it's good to have
options, but additionally it'd resolve an issue for Debian". Though
perhaps that issue is all in Debian's collective head and not anywhere
else. Sorry for that. :/
> And if there's features you want, put them on the todo list. I'm not
> sure about Bruce's comment about it being so hard to get the OpenSSL
> level of support we have, given PostgreSQL is not doing anything not
> described in the example code.
Agreed.
Thanks,
Stephen
On Fri, Dec 29, 2006 at 08:12:47PM -0500, Stephen Frost wrote: > * Joshua D. Drake (jd@commandprompt.com) wrote: > > > We use it on some of our production systems (since it can > > > provide cracklib, password expiration, etc, and the postgres > > > instance inside it's own vserver so it doesn't hurt as much to > > > make the passwd/shadow files available to it...). I'd be happy > > > to help you get it to work if you'd like, and I could even > > > provide you with some PG/C functions to use password changing > > > and password aging. :) > > > > Oh, I am sure it is great. I have just never tried that hard to > > get it to work :) > > Oh, I never said it was great, just said that we used it since PG > doesn't directly provide the things we need (cracklib, password > aging, etc). It's never been clear to me how these things in particular are good security measures, but that's a whole different discussion. > > > > I do like --with-ldap because it is pretty much standard > > > > within directory lookups by the nature of Active Directory. > > > > > > Funny you like LDAP but not Kerberos, both of which are part of > > > Active Directory... Using LDAP simple binds to AD for > > > authentication is *quite* silly and *much* less secure than > > > using Kerberos... > > > > Yes but LDAP gives me a lot of other things, easily and it has > > SSL. SSL + Firewall gives me 98% of the security I need. > > Unfortunately, security isn't a game of percentages. Security is *precisely* a game of percentages. There is a lot of silly voodoo running around in among amateurs tasked with security. The silliest usually involves the "tall fencepost" model, which is the diametric opposite of the "weakest link" model. One example of "tall fencepost" security would be hyper-strong crypto applied by demoralized employees with bad will. Attackers just *love* "tall fencepost" security. > Hopefully you'll never have a server compromised which is then used > to capture passwords which can then be used to jump to other > systems... Yeah, it's good to think about cascading failure modes. > Kerberos is there and it's not too hard to use (though does depend > on the MIT Kerberos for Windows service currently). Supporting > SSPI/GSSAPI and then writing a small document on how to generate > Windows keytabs for Postgres would mean single-sign-on for Windows > users using applications which use libpq... Sounds like a nice feature :) Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
Stephen Frost wrote: > * Martijn van Oosterhout (kleptog@svana.org) wrote: >> On Sat, Dec 30, 2006 at 02:10:42AM -0500, Tom Lane wrote: >>> Actually, it's *not* feature-complete even yet. >> What's missing? I don't see anything on the TODO list relating to >> this. If you wanted a GnuTLS patch that supported more features than >> the OpenSSL one, you should have said so. Personally I would have >> added: >> >> - authentication using PGP keys > > This would be the big feature I think is missing from our current SSL > support. I don't think it'd be terribly difficult to support with > either library (I think most of the work would be on the PG user auth > side, which would be useable by either). Wouldn't it be a lot more logical to support authentication with X.509 certificates rather than PGP keys? Given that SSL already has that at a protocol level AFAIK? And if you are doing any kind of enterprise deployment at lesat, you're likely to have the PKI infrastructure to deal out X.509 already? That said, you could do PGP authentication anyway - independent of SSL - if people wanted it. //Magnus
>> Kerberos is there and it's not too hard to use (though does depend >> on the MIT Kerberos for Windows service currently). Supporting >> SSPI/GSSAPI and then writing a small document on how to generate >> Windows keytabs for Postgres would mean single-sign-on for Windows >> users using applications which use libpq... > > Sounds like a nice feature :) We're looking into SSPI/GSSAPI (I think the latest take is to do it through SASL, but I'm not sure) hopefully for 8.3. (we? Mainly Henry B. Holtz, but I'll try to help him out as needed) //Magnus
> > This would be the big feature I think is missing from our current SSL
> > support. I don't think it'd be terribly difficult to support with
> > either library (I think most of the work would be on the PG user auth
> > side, which would be useable by either).
>
> Wouldn't it be a lot more logical to support authentication with X.509
> certificates rather than PGP keys?
The use of PGP in this manner is silly imo. X.509 would certainly be
interesting.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
On Sat, Dec 30, 2006 at 08:14:16AM -0800, Joshua D. Drake wrote: > > > > This would be the big feature I think is missing from our current SSL > > > support. I don't think it'd be terribly difficult to support with > > > either library (I think most of the work would be on the PG user auth > > > side, which would be useable by either). > > > > Wouldn't it be a lot more logical to support authentication with X.509 > > certificates rather than PGP keys? > > The use of PGP in this manner is silly imo. X.509 would certainly be > interesting. Except tht X.509 is already done (in a sense). The client can supply a certificate that the server can check, and vice-versa. You can't link this with the postgresql username yet, but I havn't seen any proposals about how to do that. The reason I wanted to use PGP is that I already have a PGP key. X.509 certificates are far too complicated (a certificate authority is a useless extra step in my case). Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
On Sat, Dec 30, 2006 at 06:05:14PM +0100, Martijn van Oosterhout wrote:
> Except tht X.509 is already done (in a sense). The client can supply a
> certificate that the server can check, and vice-versa. You can't link
> this with the postgresql username yet, but I havn't seen any proposals
> about how to do that.
I suggest associating the SHA-1 fingerprint with the ROLE. I would love
to have this.
> The reason I wanted to use PGP is that I already have a PGP key. X.509
> certificates are far too complicated (a certificate authority is a
> useless extra step in my case).
I prefer to allow self-signed certificates approved by fingerprint,
rather than content - having a central authority vouche for a person's
right to use my system does not appeal to me. Yes, this does make
X.509 far too complicated. I have a tendency to put garbage in the
X.509 fields, and use only the private key / public key / fingerprint
of public certificate, which would match your use of PGP keys... :-)
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/
> The reason I wanted to use PGP is that I already have a PGP key. X.509
> certificates are far too complicated (a certificate authority is a
> useless extra step in my case).
Complete side note but one feature that I brought up to my team a
potentially useful would be to allow the use of ssh keys for
authentication.
SSH keys are far more prevalent, and they are understood even at the
medium corporate level.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
Stephen Frost wrote: -- Start of PGP signed section. > * Bruce Momjian (bruce@momjian.us) wrote: > > Robert Treat wrote: > > > given options like --enable-dtrace and --with-libedit-preferred, I don't find > > > this argument compelling... > > > > Keep in mind it took years to get OpenSSL support up to the level we > > have it now. It took SSL experts coming in and out of our development > > process to get it 100% feature-complete. Doing this for another > > library, I am afraid, isn't trivial, unlike the above options. > > Uhh, I have no idea where you got the idea that our current OpenSSL > support is anywhere near 100% feature complete for an SSL > implementation. It's certainly not, and we've been over that > previously... My point was that in the past our SSL implementation had known problems, and only people appearing randomly seemed to be able to fix them, e.g. "Bear" was one of them. I have not seen any major complaints recently, so I feel we at least have acceptable SSL support, but it took years. Typically, some SSL export would appear, say there was something wrong with our SSL code, say he didn't have time to fix it, and disappear. I would then chase him around and maybe get a patch from him for a few of the problems he found (but not all of them). I had to stuble together a Certificate Revocation List (CRL) patch for 8.2 from soneone's posted patch. I didn't even know what CRL was, and got no feedback from the community, so I had to figure it out myself to get it into CVS (for server and client sides) and documented. If I couldn't get community help for getting a patch documented for 8.2, what help are we going to get to maintain two ways of doing SSL? For some reason, SSL seems to have more black magic than other libraries. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Stephen Frost wrote: > Yet *having* that requirement on a *derived work* which includes GPL > code is *against* the terms of the GPL. That's *exactly* the issue. > The GPL says more than "you must provide the source code to everything", > it explicitly includes a requirement that no additional restrictions be > put on the derivative (lest requirements for no-additional-distribution > or must-charge-for-other-distribution be added which defeats much of the > point of the GPL). Our BSD license has this restriction: > provided that the above copyright notice and this > paragraph and the following two paragraphs appear in all copies. Why is this not an _additional_ restriction, and hence GPL and BSD software cannot be bundled into a binary? What does "appear in all copies" mean, especially if you don't need to ship the source code under the BSD license? -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
mark@mark.mielke.cc wrote: > On Sat, Dec 30, 2006 at 06:05:14PM +0100, Martijn van Oosterhout wrote: >> Except tht X.509 is already done (in a sense). The client can supply a >> certificate that the server can check, and vice-versa. You can't link >> this with the postgresql username yet, but I havn't seen any proposals >> about how to do that. > > I suggest associating the SHA-1 fingerprint with the ROLE. I would love > to have this. I would suggest a map based on the CN. Any org with a centralized PKI infrastructure is likely to assign certs with the userid or other unique identifier in the CN. //Magnus
If you want real language-lawyer over-reach, check out this 2003 posting that says our BSD license wording is not compatible with the OpenBSD BSD license: http://archives.postgresql.org/pgsql-bugs/2003-11/msg00212.php OpenBSD feels the "without fee" can be misinterpreted, so PostgreSQL was removed from their CDROM. --------------------------------------------------------------------------- mark@mark.mielke.cc wrote: > > > Now Exim has granted an exception that gets Debian off the hook, but > > > they didn't have to do that. > > Right. If they didn't then it's conceivable that Exim could sue Debian > > for violating the GPL license. Not exactly likely to happen but being > > cautious it's best to get their explicit approval rather than playing > > the "well, we'll just wait and see if they sue us" game. > > This is pure FUD, and unacceptable if spoken from a position of > authority. State what you think this theoretical case would be. At > least if you picked GPL including closed source code, you might be > able to claim that the resulting derived work was not distributed > complete with source code. OpenSSL, however, is open source. The only > possible complaint could be "you failed to advertise OpenSSL in the > resulting distributed image", which would be a correct observation, > easily corrected by the inclusion of a note in the documentation for > the distributed software unit that includes both pieces of software. > This correction is an existing requirement for any software > distribution that includes OpenSSL, It is an acceptable, and easily > honoured requirement. > > Anybody who has a problem admitting that their software distribution > includes OpenSSL software in their documentation, has no sympathy from > me. Attribution is an acceptable right to enforce under copyright law, > and an honourable practice with or without a licensing requirement > explicitly stating this as a requirement. > > Caution to the point of fantasy is a waste of resources. Caution to > further a political agenda (not you - but the people whose opinions you > are repeating) is exploitation. > > I am unable to find a single clause in the GPL (which I have analyzed > many years ago, but also re-read several times in the last two days) > that would make it impossible to satisfy all of the GPL, PostgreSQL > (BSD) license, and the OpenSSL license at the same time. Every single > clause of all three licenses can be easily satisfied without conflict. > Those of you who are claiming otherwise, have failed to point to a > single phrase in the GPL that could not be satisfied when distributing > all three pieces of software as a single unit. Without a single point > of true conflict between all three licenses, I do not accept that > there is any case to require an OpenSSL exemption clause for > Debian. Those who are doing so are doing a disservice to everyone by > contributing to the general confusion on this subject. The clause is > not required. The clause has no effect. > > To distribute a software unit that includes software from all of a > GPL product, PostgreSQL, and OpenSSL, one needs only do the following: > > 1) Documentation for the software unit should include documentation > to describe that the software includes OpenSSL. > > 2) The distribution of the software unit should include a text copy > of all three licenses. > > 3) Source code for the entire unit should be provided. I don't believe > the FSF can legally enforce this requirement, however, with > GPL + PostgreSQL + OpenSSL, there is *NO* conflict. The source code > for all three can be made available upon request, or contained within > the distribution. > > 4) Various other minor points, such as the requirement that changes > are dated and such. None of which conflict between the three licenses. > > To state again. There is *NO* conflict between the licenses. The terms > of each can be fulfilled completely, and separately, without > invalidating each other. Those who claim otherwise need to point to a > specific requirement from one of the licenses that would prevent it > from being used. They cannot, because such a point does not > exist. Ascii pictures. Hearsay. Confusion regarding existing practice > or existing thoughts on the matter. No single point of conflict has > been raised. The GPL does not state that "GPL software may not derive > from software that has an advertising clause." Considering that this > is the primary point raised by people, it is ironic that the GPL has > no such restriction. > > Be honest about it. *You* don't like the advertising clause. The GPL > has nothing to say on the issue, and therefore is *NOT* in conflict > with it. > > This thread has re-enforced my conclusion that the GPL is a poor choice > of license for any product I ever work on in the future. A decade ago, > as a teenager, I thought it was cool to put GPL on the software that I > made available to the world. I felt like I was part of something bigger. > Now I just feel disgusted. The GPL is not about freedom. It is about > enforcing a world view on all who use your software. > > Thank you PostgreSQL contributors for choosing the BSD style. I think > it was an excellent choice. > > This is my last contribution to this thread. I've said my piece. Note > that I don't intend to convert all of you. As this issue is primarily > political, people will have a tendency to stay with their own camp, > regardless of what is said. We all have a tendencies to read each others > words, looking only for fault in what is said, purposefully choosing not > to assimilate the other persons contribution. It's called the "I am right > you are wrong" syndrome, and I'm not exempt from it. > > I hope I provided value to this discussion. If not, I apologize. > > 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 bind them... > > http://mark.mielke.cc/ > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Sat, 2006-12-30 at 13:44 -0500, Bruce Momjian wrote: > If you want real language-lawyer over-reach, check out this 2003 posting > that says our BSD license wording is not compatible with the OpenBSD BSD > license: > > http://archives.postgresql.org/pgsql-bugs/2003-11/msg00212.php > > OpenBSD feels the "without fee" can be misinterpreted, so PostgreSQL was > removed from their CDROM. I doubt that hurt us much ;) Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
* Bruce Momjian (bruce@momjian.us) wrote:
> Stephen Frost wrote:
> > Yet *having* that requirement on a *derived work* which includes GPL
> > code is *against* the terms of the GPL. That's *exactly* the issue.
> > The GPL says more than "you must provide the source code to everything",
> > it explicitly includes a requirement that no additional restrictions be
> > put on the derivative (lest requirements for no-additional-distribution
> > or must-charge-for-other-distribution be added which defeats much of the
> > point of the GPL).
>
> Our BSD license has this restriction:
>
> > provided that the above copyright notice and this
> > paragraph and the following two paragraphs appear in all copies.
>
> Why is this not an _additional_ restriction, and hence GPL and BSD
> software cannot be bundled into a binary? What does "appear in all
> copies" mean, especially if you don't need to ship the source code under
> the BSD license?
As I pointed out previously, it's part of the copyright notice, and the
GPL has the exact same requirement:
1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided
thatyou conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of
warranty;keep intact all the notices that refer to this License and to the absence of any warranty; and give any other
recipientsof the Program a copy of this License along with the Program.
So it's *not* an additional restriction. Not to mention the other
reason- the license isn't part of the *work*.
Thanks,
Stephen
* Magnus Hagander (magnus@hagander.net) wrote:
> >> Kerberos is there and it's not too hard to use (though does depend
> >> on the MIT Kerberos for Windows service currently). Supporting
> >> SSPI/GSSAPI and then writing a small document on how to generate
> >> Windows keytabs for Postgres would mean single-sign-on for Windows
> >> users using applications which use libpq...
> >
> > Sounds like a nice feature :)
>
> We're looking into SSPI/GSSAPI (I think the latest take is to do it
> through SASL, but I'm not sure) hopefully for 8.3. (we? Mainly Henry B.
> Holtz, but I'll try to help him out as needed)
While I feel including SASL support would be a good thing I'm not sure
about it's availability on Windows and so wouldn't want SASL support to
mean we don't support SSPI directly... I'd also be happy to help with
any of the above, as best I can (as I think I mentioned before when it
was brought up...).
Thanks,
Stephen
Stephen Frost wrote: -- Start of PGP signed section. > * Bruce Momjian (bruce@momjian.us) wrote: > > Stephen Frost wrote: > > > Yet *having* that requirement on a *derived work* which includes GPL > > > code is *against* the terms of the GPL. That's *exactly* the issue. > > > The GPL says more than "you must provide the source code to everything", > > > it explicitly includes a requirement that no additional restrictions be > > > put on the derivative (lest requirements for no-additional-distribution > > > or must-charge-for-other-distribution be added which defeats much of the > > > point of the GPL). > > > > Our BSD license has this restriction: > > > > > provided that the above copyright notice and this > > > paragraph and the following two paragraphs appear in all copies. > > > > Why is this not an _additional_ restriction, and hence GPL and BSD > > software cannot be bundled into a binary? What does "appear in all > > copies" mean, especially if you don't need to ship the source code under > > the BSD license? > > As I pointed out previously, it's part of the copyright notice, and the > GPL has the exact same requirement: > > 1. You may copy and distribute verbatim copies of the Program's > source code as you receive it, in any medium, provided that you > conspicuously and appropriately publish on each copy an appropriate > copyright notice and disclaimer of warranty; keep intact all the > notices that refer to this License and to the absence of any warranty; > and give any other recipients of the Program a copy of this License > along with the Program. > > So it's *not* an additional restriction. Not to mention the other > reason- the license isn't part of the *work*. It is an _additional_ license you have to include, not just their license. I don't see how requiring an advertizing clause is an additional restriction, but requiring an additional license isn't. I don't understand the "work" issue as it applies here. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
* Magnus Hagander (magnus@hagander.net) wrote:
> Stephen Frost wrote:
> > * Martijn van Oosterhout (kleptog@svana.org) wrote:
> >> On Sat, Dec 30, 2006 at 02:10:42AM -0500, Tom Lane wrote:
> >>> Actually, it's *not* feature-complete even yet.
> >> What's missing? I don't see anything on the TODO list relating to
> >> this. If you wanted a GnuTLS patch that supported more features than
> >> the OpenSSL one, you should have said so. Personally I would have
> >> added:
> >>
> >> - authentication using PGP keys
> >
> > This would be the big feature I think is missing from our current SSL
> > support. I don't think it'd be terribly difficult to support with
> > either library (I think most of the work would be on the PG user auth
> > side, which would be useable by either).
>
> Wouldn't it be a lot more logical to support authentication with X.509
> certificates rather than PGP keys? Given that SSL already has that at a
> protocol level AFAIK? And if you are doing any kind of enterprise
> deployment at lesat, you're likely to have the PKI infrastructure to
> deal out X.509 already?
>
> That said, you could do PGP authentication anyway - independent of SSL -
> if people wanted it.
Err, brain fart on my side, I was thinking about X.509 certs, actually,
not PGP keys. I agree w/ you 100% on this. :)
Thanks,
Stephen
* Magnus Hagander (magnus@hagander.net) wrote:
> mark@mark.mielke.cc wrote:
> > On Sat, Dec 30, 2006 at 06:05:14PM +0100, Martijn van Oosterhout wrote:
> >> Except tht X.509 is already done (in a sense). The client can supply a
> >> certificate that the server can check, and vice-versa. You can't link
> >> this with the postgresql username yet, but I havn't seen any proposals
> >> about how to do that.
> >
> > I suggest associating the SHA-1 fingerprint with the ROLE. I would love
> > to have this.
>
> I would suggest a map based on the CN. Any org with a centralized PKI
> infrastructure is likely to assign certs with the userid or other unique
> identifier in the CN.
Right, this would be how I'd envision it as well. Basically provide a
CA which you trust and then a way to map from DN/CN to PostgreSQL users
(perhaps similar to the ident mapping in implementation?). I'd *also*
like to support full certificate matching (not just the fingerprint...)
but I think doing DN/CN would be a good, easier, first step.
Thanks,
Stephen
* Joshua D. Drake (jd@commandprompt.com) wrote:
>
> > The reason I wanted to use PGP is that I already have a PGP key. X.509
> > certificates are far too complicated (a certificate authority is a
> > useless extra step in my case).
>
> Complete side note but one feature that I brought up to my team a
> potentially useful would be to allow the use of ssh keys for
> authentication.
>
> SSH keys are far more prevalent, and they are understood even at the
> medium corporate level.
While this may be true it's certainly also true that X.509 keys are
understood at both the medium corporate level and mid-level gov't (at
least in the US), especially inside the DOD, where they've been
mandated, as I recall.
Thanks,
Stephen
* Bruce Momjian (bruce@momjian.us) wrote:
> Stephen Frost wrote:
> > So it's *not* an additional restriction. Not to mention the other
> > reason- the license isn't part of the *work*.
>
> It is an _additional_ license you have to include, not just their
> license. I don't see how requiring an advertizing clause is an
> additional restriction, but requiring an additional license isn't.
The GPL fully realizes that there may be other licenses out there which
is why it was written to talk about *restrictions*:
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
> I don't understand the "work" issue as it applies here.
The resulting binary. Honestly, as I've tried to explain before, it's
not a PostgreSQL problem in general. As such, while I'm happy to try
and explain it, I think people have heard enough about it and so will
try to refrain from discussing the detailed legal stuff more on these
lists. Let me just say that Debian feels there's an issue with
distributing GPL applications linked against OpenSSL. Thus, in general,
Debian likes to see GNUTLS as an option for commonly used libraries to
avoid the issue (as they see it) entirely. I'd like to think that
Debian's preference for a library with a different license might at
least add some small amount of weight to the argument to include support
for a different library, but if not then that's pretty much how it goes
and we can just hope that the technical reasons themselves are enough.
Personally, I don't think Debian's alone in at least the preference for
a different license, but I can't say for sure.
I do agree that the technical merits should come first but thought the
licensing issue might be the straw that broke the camel's back, per se.
As much fun as it is discussing this here I don't see it changing
Debian's position. Joshua has said he'll ask SPI's lawyer about it and
that might change things (though I tend to doubt it, personally). It'll
be a while before we get an answer there though, I think.
Thanks,
Stephen
Stephen Frost wrote: > * Magnus Hagander (magnus@hagander.net) wrote: >>>> Kerberos is there and it's not too hard to use (though does depend >>>> on the MIT Kerberos for Windows service currently). Supporting >>>> SSPI/GSSAPI and then writing a small document on how to generate >>>> Windows keytabs for Postgres would mean single-sign-on for Windows >>>> users using applications which use libpq... >>> Sounds like a nice feature :) >> We're looking into SSPI/GSSAPI (I think the latest take is to do it >> through SASL, but I'm not sure) hopefully for 8.3. (we? Mainly Henry B. >> Holtz, but I'll try to help him out as needed) > > While I feel including SASL support would be a good thing I'm not sure > about it's availability on Windows and so wouldn't want SASL support to > mean we don't support SSPI directly... I'd also be happy to help with > any of the above, as best I can (as I think I mentioned before when it > was brought up...). Windows has builtin SASL support since Windows 2000. Though a quick look at the docs right now it looks like it's only supported on server, but the functions are definitely present on my XP client... The idea is to get that to work. //Magnus
On Sat, 2006-12-30 at 14:28 -0500, Stephen Frost wrote:
> * Joshua D. Drake (jd@commandprompt.com) wrote:
> >
> > > The reason I wanted to use PGP is that I already have a PGP key. X.509
> > > certificates are far too complicated (a certificate authority is a
> > > useless extra step in my case).
> >
> > Complete side note but one feature that I brought up to my team a
> > potentially useful would be to allow the use of ssh keys for
> > authentication.
> >
> > SSH keys are far more prevalent, and they are understood even at the
> > medium corporate level.
>
> While this may be true it's certainly also true that X.509 keys are
> understood at both the medium corporate level and mid-level gov't (at
> least in the US), especially inside the DOD, where they've been
> mandated, as I recall.
I am not against X.509 at all. I was saying that instead of PGP, ssh
keys may make more sense.
J
>
> Thanks,
>
> Stephen
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
* Bruce Momjian (bruce@momjian.us) wrote:
> I had to stuble together a Certificate Revocation List (CRL) patch for
> 8.2 from soneone's posted patch. I didn't even know what CRL was, and
> got no feedback from the community, so I had to figure it out myself to
> get it into CVS (for server and client sides) and documented.
I recall talking about CRLs on the lists at one point and encouraging
their inclusion. I would have been happy to explain what they are and
why they're good to have (along with OCSP support...). I thought you
were included in that discussion.
> If I couldn't get community help for getting a patch documented for 8.2,
> what help are we going to get to maintain two ways of doing SSL?
My apologies for not responding to the request (I think I did see it,
though I can't recall for sure). I don't consider myself an SSL or
X.509 expert but I've got some experience with it and would be happy to
help as I can...
> For some reason, SSL seems to have more black magic than other
> libraries.
It's more the certs and X.509, ASN1, etc, that's black magic, imv. :)
Thanks,
Stephen
Stephen Frost wrote: -- Start of PGP signed section. > * Bruce Momjian (bruce@momjian.us) wrote: > > Stephen Frost wrote: > > > So it's *not* an additional restriction. Not to mention the other > > > reason- the license isn't part of the *work*. > > > > It is an _additional_ license you have to include, not just their > > license. I don't see how requiring an advertizing clause is an > > additional restriction, but requiring an additional license isn't. > > The GPL fully realizes that there may be other licenses out there which > is why it was written to talk about *restrictions*: > > 6. Each time you redistribute the Program (or any work based on the > Program), the recipient automatically receives a license from the > original licensor to copy, distribute or modify the Program subject to > these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted herein. > You are not responsible for enforcing compliance by third parties to > this License. I don't see the distinction here. Where does it say having to include another license is a different additional restriction from an advertizing clause? > > I don't understand the "work" issue as it applies here. Right. I wasn't clear in saying that the idea is whether the BSD and GPL licenses can or cannot be merged into a single work. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
* Bruce Momjian (bruce@momjian.us) wrote:
> Stephen Frost wrote:
> > 6. Each time you redistribute the Program (or any work based on the
> > Program), the recipient automatically receives a license from the
> > original licensor to copy, distribute or modify the Program subject to
> > these terms and conditions. You may not impose any further
> > restrictions on the recipients' exercise of the rights granted herein.
> > You are not responsible for enforcing compliance by third parties to
> > this License.
>
> I don't see the distinction here. Where does it say having to include
> another license is a different additional restriction from an
> advertizing clause?
Erm, I thought I included it already, but...
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
That's an existing restriction in the GPL, therefore a restriction in
another license for the same thing is acceptable to the GPL for a
resultant work. You'll also note above it says "an appropriate
copyright notice".
Thanks,
Stephen
Stephen Frost wrote: -- Start of PGP signed section. > * Bruce Momjian (bruce@momjian.us) wrote: > > Stephen Frost wrote: > > > 6. Each time you redistribute the Program (or any work based on the > > > Program), the recipient automatically receives a license from the > > > original licensor to copy, distribute or modify the Program subject to > > > these terms and conditions. You may not impose any further > > > restrictions on the recipients' exercise of the rights granted herein. > > > You are not responsible for enforcing compliance by third parties to > > > this License. > > > > I don't see the distinction here. Where does it say having to include > > another license is a different additional restriction from an > > advertizing clause? > > Erm, I thought I included it already, but... > > 1. You may copy and distribute verbatim copies of the Program's > source code as you receive it, in any medium, provided that you > conspicuously and appropriately publish on each copy an appropriate > copyright notice and disclaimer of warranty; keep intact all the > notices that refer to this License and to the absence of any warranty; > and give any other recipients of the Program a copy of this License > along with the Program. > > That's an existing restriction in the GPL, therefore a restriction in > another license for the same thing is acceptable to the GPL for a > resultant work. You'll also note above it says "an appropriate > copyright notice". I don't see were is says that another license's restriction that is the same as a GPL restriction, but for a different license, is OK. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
* Bruce Momjian (bruce@momjian.us) wrote:
> Stephen Frost wrote:
> > > > 6. Each time you redistribute the Program (or any work based on the
> > > > Program), the recipient automatically receives a license from the
> > > > original licensor to copy, distribute or modify the Program subject to
> > > > these terms and conditions. You may not impose any further
> > > > restrictions on the recipients' exercise of the rights granted herein.
> > > > You are not responsible for enforcing compliance by third parties to
> > > > this License.
> > >
> > > I don't see the distinction here. Where does it say having to include
> > > another license is a different additional restriction from an
> > > advertizing clause?
> >
> > Erm, I thought I included it already, but...
> >
> > 1. You may copy and distribute verbatim copies of the Program's
> > source code as you receive it, in any medium, provided that you
> > conspicuously and appropriately publish on each copy an appropriate
> > copyright notice and disclaimer of warranty; keep intact all the
> > notices that refer to this License and to the absence of any warranty;
> > and give any other recipients of the Program a copy of this License
> > along with the Program.
> >
> > That's an existing restriction in the GPL, therefore a restriction in
> > another license for the same thing is acceptable to the GPL for a
> > resultant work. You'll also note above it says "an appropriate
> > copyright notice".
>
> I don't see were is says that another license's restriction that is the
> same as a GPL restriction, but for a different license, is OK.
It says that above under 6- You may not impose any *further*
restrictions on the recipients' exercise of the rights granted herein.
I appriciate your pedantism but in the end it really doesn't matter very
much. This is, aiui anyway, the way Debian interprets the various
licenses. You're welcome to your own interpretation.
Thanks,
Stephen
Stephen Frost wrote: > > > 1. You may copy and distribute verbatim copies of the Program's > > > source code as you receive it, in any medium, provided that you > > > conspicuously and appropriately publish on each copy an appropriate > > > copyright notice and disclaimer of warranty; keep intact all the > > > notices that refer to this License and to the absence of any warranty; > > > and give any other recipients of the Program a copy of this License > > > along with the Program. > > > > > > That's an existing restriction in the GPL, therefore a restriction in > > > another license for the same thing is acceptable to the GPL for a > > > resultant work. You'll also note above it says "an appropriate > > > copyright notice". > > > > I don't see were is says that another license's restriction that is the > > same as a GPL restriction, but for a different license, is OK. > > It says that above under 6- You may not impose any *further* > restrictions on the recipients' exercise of the rights granted herein. > > I appriciate your pedantism but in the end it really doesn't matter very > much. This is, aiui anyway, the way Debian interprets the various > licenses. You're welcome to your own interpretation. That was my point --- that it isn't clear what "additional restrictions" are, and that an advertizing clause or additional license can be interpreted as the same thing. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Sat, Dec 30, 2006 at 05:03:23PM -0500, Bruce Momjian wrote: > > I appriciate your pedantism but in the end it really doesn't matter very > > much. This is, aiui anyway, the way Debian interprets the various > > licenses. You're welcome to your own interpretation. > > That was my point --- that it isn't clear what "additional restrictions" > are, and that an advertizing clause or additional license can be > interpreted as the same thing. Somehow I don't think a statement requiring you to put some guys name in all your advertising material is the same as requiring you to preserve the copyright notice. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Martijn van Oosterhout wrote: -- Start of PGP signed section. > On Sat, Dec 30, 2006 at 05:03:23PM -0500, Bruce Momjian wrote: > > > I appriciate your pedantism but in the end it really doesn't matter very > > > much. This is, aiui anyway, the way Debian interprets the various > > > licenses. You're welcome to your own interpretation. > > > > That was my point --- that it isn't clear what "additional restrictions" > > are, and that an advertizing clause or additional license can be > > interpreted as the same thing. > > Somehow I don't think a statement requiring you to put some guys name > in all your advertising material is the same as requiring you to > preserve the copyright notice. Agreed, but the words "additional restrictions" make no distinction on the magnitude of additional restrictions. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Tom Lane wrote: >What basically bothers me about this is that trying to support both the >OpenSSL and GNUTLS APIs is going to be an enormous investment of >development and maintenance effort, because it's such a nontrivial thing > > Fascinating thread for the holidays. I found it interesting that nobody has mentioned NSS (former Netscape SSL library). It has its own bag of problems of course, but for me is potentially more attractive than GNU TLS. e.g. it has FIPS-140 certification and is actively under development by a software company with significant resources. It's also very widely deployed. I'm not saying that OpenSSL is bad (it'd probably be my first choice), just that there is another option besides GNU TLS. BTW, if I may throw more gas on the licence debate flames -- the OpenLDAP client library depends on OpenSSL, and almost everything depends on OpenLDAP (e.g. PAM, SASL, any LDAP-enabled app). In 2003 Steven Frost submitted patches to the OL code to add GNU TLS support, but as far as I can tell that code is still not in the current OpenLDAP tree. Perhaps Steven could tell us what happened to that effort.
* David Boreham (david_list@boreham.org) wrote:
> Fascinating thread for the holidays. I found it interesting that nobody
> has mentioned
> NSS (former Netscape SSL library). It has its own bag of problems of
> course, but
> for me is potentially more attractive than GNU TLS. e.g. it has FIPS-140
> certification
> and is actively under development by a software company with significant
> resources.
> It's also very widely deployed. I'm not saying that OpenSSL is bad (it'd
> probably be my
> first choice), just that there is another option besides GNU TLS.
Not sure what license that's under, but I don't know of any particular
reason it wouldn't be an option other than the work for GNUTLS has
already been done.
> BTW, if I may throw more gas on the licence debate flames -- the
> OpenLDAP client library
> depends on OpenSSL, and almost everything depends on OpenLDAP (e.g. PAM,
> SASL,
> any LDAP-enabled app). In 2003 Steven Frost submitted patches to the OL
> code to
> add GNU TLS support, but as far as I can tell that code is still not in
> the current OpenLDAP
> tree. Perhaps Steven could tell us what happened to that effort.
OpenLDAP upstream didn't want to accept the patch since it was written
by someone other than the person submitting it (Steve Langasek was the
original author). So Debian applied the patch locally and then it got
out of sync with OpenLDAP over time so now there's an effort underway to
port it to the current OpenLDAP branch (aiui anyway). I forget who's
leading that effort (it's not Steve) but I'm pretty sure the goal is to
have GNUTLS support in the next major version. While there were a few
issues initially with GNUTLS in the OpenLDAP library in Debian it didn't
take long for them to be sorted out and it's been what the OpenLDAP
libraries under Debian have been using for quite some time now...
Thanks,
Stephen
* Bruce Momjian (bruce@momjian.us) wrote:
> Martijn van Oosterhout wrote:
> > Somehow I don't think a statement requiring you to put some guys name
> > in all your advertising material is the same as requiring you to
> > preserve the copyright notice.
>
> Agreed, but the words "additional restrictions" make no distinction on
> the magnitude of additional restrictions.
It's got nothing to do with the magnitude from Debian's perspective.
If you'd like to think of it like that, that's fine, but don't
misunderstand Debian's position.
Thanks,
Stephen
* Bruce Momjian (bruce@momjian.us) wrote:
> Stephen Frost wrote:
> > I appriciate your pedantism but in the end it really doesn't matter very
> > much. This is, aiui anyway, the way Debian interprets the various
> > licenses. You're welcome to your own interpretation.
>
> That was my point --- that it isn't clear what "additional restrictions"
> are, and that an advertizing clause or additional license can be
> interpreted as the same thing.
The point, from Debian's perspective anyway, is that they're *not* the
same thing and one is an 'additional restriction' while the other isn't.
It's pretty clear that the GPL has a clause requiring the distribution
of the license associated with the work while it has no clause which
requires statements in advertising material.
Thanks,
Stephen
On Sat, 2006-12-30 at 22:18 -0500, Stephen Frost wrote:
> * Bruce Momjian (bruce@momjian.us) wrote:
> > Stephen Frost wrote:
> > > I appriciate your pedantism but in the end it really doesn't matter very
> > > much. This is, aiui anyway, the way Debian interprets the various
> > > licenses. You're welcome to your own interpretation.
> >
> > That was my point --- that it isn't clear what "additional restrictions"
> > are, and that an advertizing clause or additional license can be
> > interpreted as the same thing.
>
> The point, from Debian's perspective anyway, is that they're *not* the
> same thing and one is an 'additional restriction' while the other isn't.
> It's pretty clear that the GPL has a clause requiring the distribution
> of the license associated with the work while it has no clause which
> requires statements in advertising material.
Well as has been stated previously by multiple members of this project.
We do not currently see an issue with the licensing and we do not see a
need to further our maintability with GNU TLS.
At this point the argument is just going in circles and is not
productive, secondly at this point it also seems more of an advocacy
discussion than a Hackers discussion. If we wish to continue can we move
it to that list please?
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
On Sat, Dec 30, 2006 at 05:03:23PM -0500, Bruce Momjian wrote:
> Stephen Frost wrote:
> > I appriciate your pedantism but in the end it really doesn't matter very
> > much. This is, aiui anyway, the way Debian interprets the various
> > licenses. You're welcome to your own interpretation.
> That was my point --- that it isn't clear what "additional restrictions"
> are, and that an advertizing clause or additional license can be
> interpreted as the same thing.
Breaking my claim of silence - I think Stephen has presented the Debian
interpretation, but qualified several times that Debian may be incorrect.
I spent quite a lot of thread space on exactly this issue - that forcing
an additional license to be imposed on the user, is indeed an additional
restriction. People either get it or they don't. It would either stand up
in court or it wouldn't. :-)
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/
Hi, I've just read most of that thread and found it rather disappointing. I'd just like to add my 2 (or 3) cents: a) I like to have the freedom to choose what software (under which licenses) I'm using. Thus I'd like to see GNUTLS supported, as it adds an additional feature to PostgreSQL per se: the option to choose between different SSL implementations. b) The other features of Martijn's patch got completely overseen. Can we (can you Martijn?) break up the patch into smaller pieces and discuss single independent features, like querying for parameters of the SSL connection? c) I'm disappointed at the way licenses are threated here. Being a developer myself, I'm looking at licenses as a wish of the author about how to treat his work and how to credit him. I'd like to follow these wishes as good as I can, instead of stepping into the grey-area and playing the 'hopefully-no-one-sues-us' game. In case of the advertising clause, which is very strong, IMO, I think most authors didn't want to be as strict as they made it sound in the license. Or did any of the OpenSSL or libjpeg projects ever try to sue somebody for not having mentioned them in their advertising materials? You can ask the authors how they really meant it, probably they will change the wording or even remove the advertising clause entirely. Or probably they officially state how they meant their advertising clause to be interpreted. (I'm not aware of the OpenSSL project doing so. While the FSF states quite clearly that they don't consider such a restriction to be respectful to their GPL.) Following that 'better-safe-than-sorry' philosophy, one could ask if PostgreSQL shouldn't better include the acknowledgements of OpenSSL (and MIT Kerberos) in all of their advertising materials... I fully understand and support Debian's point of view and I'd wish more people would follow that spirit. We'd have much less cases to fight for in curt and generally live in a better world (TM). Regards Markus
On Sun, Dec 31, 2006 at 03:25:42PM +0100, Markus Schiltknecht wrote: > b) The other features of Martijn's patch got completely overseen. Can we > (can you Martijn?) break up the patch into smaller pieces and discuss > single independent features, like querying for parameters of the SSL > connection? If I got a single ounce of feedback on them, sure. The only responses have involved the licence so far. I won't deny some of the other features were also controversial. > In case of the advertising clause, which is very strong, IMO, I think > most authors didn't want to be as strict as they made it sound in the > license. Or did any of the OpenSSL or libjpeg projects ever try to sue > somebody for not having mentioned them in their advertising materials? Please read the OpenSSL-GPL FAQ. They themselves acknowledge it's a problem, but claim they fall under the "operating system exception", which is fine for everyone except the distributor of the operating system. http://www.openssl.org/support/faq.html#LEGAL2 They recommend that if you want to use OpenSSL, use a licence other than the GPL. Wikipedia also has more information about this. http://en.wikipedia.org/wiki/OpenSSL > You can ask the authors how they really meant it, probably they will > change the wording or even remove the advertising clause entirely. Or > probably they officially state how they meant their advertising clause > to be interpreted. (I'm not aware of the OpenSSL project doing so. While > the FSF states quite clearly that they don't consider such a restriction > to be respectful to their GPL.) The original authors have been asked and apparently can't be found or don't care. I strongly suggest you read the openssl archives before opening this can of worms. Note the authors involved are no longer part of OpenSSL, they have another SSL library, so they're probably not inclined to be nice. > Following that 'better-safe-than-sorry' philosophy, one could ask if > PostgreSQL shouldn't better include the acknowledgements of OpenSSL (and > MIT Kerberos) in all of their advertising materials... AIUI all compiled distributions of postgresql using openssl do actually include such. For example the Windows Installer. > I fully understand and support Debian's point of view and I'd wish more > people would follow that spirit. We'd have much less cases to fight for > in curt and generally live in a better world (TM). We're in the bizarre situation were both Debian and the OpenSSL groups beleive it is a problem, and postgresql does not. Quite odd. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
On Sun, Dec 31, 2006 at 03:59:29PM +0100, Martijn van Oosterhout wrote: > Please read the OpenSSL-GPL FAQ. They themselves acknowledge it's a > problem, but claim they fall under the "operating system exception", > which is fine for everyone except the distributor of the operating > system. > > http://www.openssl.org/support/faq.html#LEGAL2 > > They recommend that if you want to use OpenSSL, use a licence other > than the GPL. I believe this to be a slight misrepresentation. The section before states "The OpenSSL team does not offer legal advice." The section you quote then goes on to contradict this, by stating a position much more conservative than your summary: On many systems including the major Linux and BSD distributions, yes (the GPL does not place restrictions on using librariesthat are part of the normal operating system distribution). On other systems, the situation is less clear. Some GPL software copyright holders claim that you infringe on theirrights if you use OpenSSL with their software on operating systems that don't normally include OpenSSL. If you develop open source software that uses OpenSSL, you may find it useful to choose an other license than the GPL,or state explicitly that "This program is released under the GPL with the additional exemption that compiling, linking,and/or using OpenSSL is allowed." If you are using GPL software developed by others, you may want to ask thecopyright holder for permission to use their software with OpenSSL. It seems your interpretation of the OpenSSL "position" is as questionable as your interpretation of the GPL, and what the GPL can legally require. :-) Nobody has proven an issue exists. The only way to prove it would be for an actual court case to set the precident. 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/
> It seems your interpretation of the OpenSSL "position" is as
> questionable as your interpretation of the GPL, and what the GPL can
> legally require. :-)
>
> Nobody has proven an issue exists. The only way to prove it would be
> for an actual court case to set the precident.
Further, OpenSSL is not saying that an issue exists for them. They are
saying that *some* people *may* have a problem with it.
Can we all talk about things that matter now? Like improving table
partitioning?
At a minimum, please move this thread to -advocacy.
Sincerely,
Joshua D. Drake
>
> Cheers,
> mark
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
Hi, Martijn van Oosterhout wrote: > Please read the OpenSSL-GPL FAQ. They themselves acknowledge it's a > problem, but claim they fall under the "operating system exception", > which is fine for everyone except the distributor of the operating > system. > > http://www.openssl.org/support/faq.html#LEGAL2 Thanks for the link. Unfortunately that FAQ does not say anything about the advertising clause or how they want it to be interpreted. > They recommend that if you want to use OpenSSL, use a licence other > than the GPL. ..which could be seen as a sign that they take their advertising clause serious. I wonder how much of their code is still copyrighted by authors refusing to remove that clause... > Wikipedia also has more information about this. > > http://en.wikipedia.org/wiki/OpenSSL I also found this to be a good description: http://www.gnome.org/~markmc/openssl-and-the-gpl.html [ OT: Generally, I feel that the exceptions which are made to the GPL are very messy and confusing. And again, the exception implicitly states that the OpesSSL Projects wants you to adhere to the advertising clause. ] > The original authors have been asked and apparently can't be found or > don't care. I strongly suggest you read the openssl archives before > opening this can of worms. Note the authors involved are no longer part > of OpenSSL, they have another SSL library, so they're probably not > inclined to be nice. Sure, I've heard about that and won't open that can of worms ;-) >> Following that 'better-safe-than-sorry' philosophy, one could ask if >> PostgreSQL shouldn't better include the acknowledgements of OpenSSL (and >> MIT Kerberos) in all of their advertising materials... > > AIUI all compiled distributions of postgresql using openssl do actually > include such. For example the Windows Installer. The OpenSSL license speaks of "all advertising materials mentioning .. use of this software". IMO, the PostgreSQL website matches that criterion very well, doesn't it? AFAICT, that's why so many people avoid advertising clauses like the plague. (And why it's called 'advertising clause' and not 'compiled distribution clause'.) Probably PostgreSQL should ask for an exception... ;-) > We're in the bizarre situation were both Debian and the OpenSSL groups > beleive it is a problem, and postgresql does not. Quite odd. I somehow don't understand how this could *not* be a problem. My reasoning is that one must not not respect authors wishes (licenses) very much if one feels this is not a problem. Regards Markus
Hi, mark@mark.mielke.cc wrote: >> Nobody has proven an issue exists. The only way to prove it would be >> for an actual court case to set the precident. That's exactly the mentality that I'm questioning. Why always go to legal boundaries and ask for courts? Joshua D. Drake wrote: > Further, OpenSSL is not saying that an issue exists for them. They are > saying that *some* people *may* have a problem with it. Neither do they say that one can simply ignore their advertising clause and that everybody is save from being sued. And further, the OpenSSL license is not violated if OpenSSL in included in GPL software, the GPL license is. Thus it's probably quite irrelevant what the OpenSSL FAQ says about GPL violations. I agree that PostgreSQL (being BSD-like) should not care too much about the GPL. But we should care about the OpenSSL license, as they seem to take their advertising clause quite serious. > At a minimum, please move this thread to -advocacy. I disagree, sorry. IMO, this is an important subject hackers should know about. (And it has nothing to do with "PostgreSQL vs. the rest. Promotional ideas, etc.", what -advocacy is said to be about.) Regards Markus
jd@commandprompt.com ("Joshua D. Drake") writes:
>> The reason I wanted to use PGP is that I already have a PGP key. X.509
>> certificates are far too complicated (a certificate authority is a
>> useless extra step in my case).
>
> Complete side note but one feature that I brought up to my team a
> potentially useful would be to allow the use of ssh keys for
> authentication.
>
> SSH keys are far more prevalent, and they are understood even at the
> medium corporate level.
I haven't discussed this with Afilias folk, but that sure sounds like
an excellent thing to me. ssh keys are already in widespread use for
other forms of authentication; this seems an excellent re-use.
X.509 might be nice, too, eventually; ssh keys would be immediately
useful.
--
"cbbrowne","@","linuxfinances.info"
http://cbbrowne.com/info/sap.html
Evil Overlords tend to get overthrown due to overly baroque plans with
obvious fatal errors. Follow the "Rules of the Evil Overlord," and
you need not fear heroic opposition, whether that hero be James Bond,
Flash Gordon, or a little hobbit named Frodo.
jd@commandprompt.com ("Joshua D. Drake") writes:
>> The reason I wanted to use PGP is that I already have a PGP key. X.509
>> certificates are far too complicated (a certificate authority is a
>> useless extra step in my case).
>
> Complete side note but one feature that I brought up to my team a
> potentially useful would be to allow the use of ssh keys for
> authentication.
>
> SSH keys are far more prevalent, and they are understood even at the
> medium corporate level.
I haven't discussed this with Afilias folk, but that sure sounds like
an excellent thing to me. ssh keys are already in widespread use for
other forms of authentication; this seems an excellent re-use.
X.509 might be nice, too, eventually; ssh keys would be immediately
useful.
--
"cbbrowne","@","linuxfinances.info"
http://cbbrowne.com/info/sap.html
Evil Overlords tend to get overthrown due to overly baroque plans with
obvious fatal errors. Follow the "Rules of the Evil Overlord," and
you need not fear heroic opposition, whether that hero be James Bond,
Flash Gordon, or a little hobbit named Frodo.
Stephen Frost wrote: >* David Boreham (david_list@boreham.org) wrote: > > >>Fascinating thread for the holidays. I found it interesting that nobody >>has mentioned >>NSS (former Netscape SSL library). It has its own bag of problems of >>course, but >>for me is potentially more attractive than GNU TLS. e.g. it has FIPS-140 >>certification >>and is actively under development by a software company with significant >>resources. >>It's also very widely deployed. I'm not saying that OpenSSL is bad (it'd >>probably be my >>first choice), just that there is another option besides GNU TLS. >> >> > >Not sure what license that's under, >From http://www.mozilla.org/projects/security/pki/nss/: 'NSS is available under the Mozilla Public License, the GNU General Public License, and the GNU Lesser General Public License.'
* David Boreham (david_list@boreham.org) wrote: > Stephen Frost wrote: > >Not sure what license that's under, > > > From http://www.mozilla.org/projects/security/pki/nss/: > 'NSS is available under the Mozilla Public License, the GNU General > Public License, and the GNU Lesser General Public License.' Works for me then, and it's already packaged in Debian. The only downside that I can see is that the work isn't done yet and if we want to support both OpenSSL and NSS then the patch will be at least somewhat invasive/large (since I doubt NSS's API is anything like OpenSSL's, please correct me if I'm wrong). Would a patch to implement dual-support for OpenSSL and NSS be acceptable? Would just replacing OpenSSL support with NSS support be better? Thanks, Stephen
David Boreham wrote: > Stephen Frost wrote: > >> * David Boreham (david_list@boreham.org) wrote: >> >> >>> Fascinating thread for the holidays. I found it interesting that >>> nobody has mentioned >>> NSS (former Netscape SSL library). It has its own bag of problems of >>> course, but >>> for me is potentially more attractive than GNU TLS. e.g. it has >>> FIPS-140 certification >>> and is actively under development by a software company with >>> significant resources. >>> It's also very widely deployed. I'm not saying that OpenSSL is bad >>> (it'd probably be my >>> first choice), just that there is another option besides GNU TLS. >>> >> >> Not sure what license that's under, >> > From http://www.mozilla.org/projects/security/pki/nss/: > 'NSS is available under the Mozilla Public License, the GNU General > Public License, and the GNU Lesser General Public License.' > I suspect most postgres developers and companies would like to keep things as BSDish as possible. Dealing with a multitude of licenses might be fun for some, but many of us find it a pain in the neck. Also, do we really want to import the NSPR into Postgres? I suspect not. Of course, the only thing that people are tripping over license-wise is libpq. But I think we would want to keep that as lean and mean as possible, too. cheers andrew
Stephen Frost wrote: >* David Boreham (david_list@boreham.org) wrote: > > >>Stephen Frost wrote: >> >> >>>Not sure what license that's under, >>> >>> >>> >>From http://www.mozilla.org/projects/security/pki/nss/: >>'NSS is available under the Mozilla Public License, the GNU General >>Public License, and the GNU Lesser General Public License.' >> >> > >Works for me then, and it's already packaged in Debian. The only >downside that I can see is that the work isn't done yet and if we want >to support both OpenSSL and NSS then the patch will be at least somewhat >invasive/large (since I doubt NSS's API is anything like OpenSSL's, >please correct me if I'm wrong). > > Unfortunately the NSS and OpenSSL I/O design is quite different. There has been talk over the years (since at least 1996) of adding OpenSSL-like interfaces to NSS, but AFAIK this has never been done. NSS presents a 'layered' I/O model where the application talks to a socket-like API. It also depends on NSPR. For these reasons I would hesitate to recommend it for use in a server vs. OpenSSL.
Andrew Dunstan <andrew@dunslane.net> writes:
> Also, do we really want to import the NSPR into Postgres? I suspect not.
> Of course, the only thing that people are tripping over license-wise is
> libpq. But I think we would want to keep that as lean and mean as
> possible, too.
Yeah, requiring NSPR to be imported into all client applications that
use libpq is an utter non-starter :-(
regards, tom lane
Andrew Dunstan wrote: > I suspect most postgres developers and companies would like to keep > things as BSDish as possible. Right, hence OpenSSL would be the obvious best choice. In respect of licencing however, NSS is no 'worse' than GNU TLS because it may be distributed under the GPL and LGPL.
* Andrew Dunstan (andrew@dunslane.net) wrote:
> I suspect most postgres developers and companies would like to keep
> things as BSDish as possible. Dealing with a multitude of licenses might
> be fun for some, but many of us find it a pain in the neck.
It'd be great if PostgreSQL could use an SSL library with the same
license as PostgreSQL itself has. That'd certainly work for me.
Unfortunately, I'm not sure one exists (if anyone knows of one, please
mention it...). I don't like having to deal with lots of licenses
either but it's pretty much a fact of life in today's OSS world. I hope
you don't think I've gotten any enjoyment out of this, it's just a very
frustrating quagmire that I have to deal with.
> Also, do we really want to import the NSPR into Postgres? I suspect not.
> Of course, the only thing that people are tripping over license-wise is
> libpq. But I think we would want to keep that as lean and mean as
> possible, too.
erm, I'm not really sure what you're saying here but perhaps I can
clarify: I wasn't suggesting to add any serious amount of source code
to PostgreSQL - NSS would be used just as OpenSSL is today, and as
GNUTLS support was proposed, a seperate library which is distributed
independently of PostgreSQL but can be compiled against. I don't know
about the memory footprint of NSS, though if we care about that terribly
much it's my understanding that GNUTLS has a smaller footprint than
OpenSSL...
While somehow changing libpq to remove the issue it's unfortunately not
the only case. There are GPL'd PostgreSQL server extensions
(specifically PostGIS, at least) which are also affected.
Thanks,
Stephen
* David Boreham (david_list@boreham.org) wrote:
> Andrew Dunstan wrote:
>
> >I suspect most postgres developers and companies would like to keep
> >things as BSDish as possible.
>
> Right, hence OpenSSL would be the obvious best choice.
> In respect of licencing however, NSS is no 'worse' than GNU TLS
> because it may be distributed under the GPL and LGPL.
And the MPL, which at least according to the Mozilla FAQ falls somewhere
between the GPL and BSD (though I'm not sure I'd agree...).
Thanks,
Stephen
Stephen Frost wrote: >>Also, do we really want to import the NSPR into Postgres? I suspect not. >>Of course, the only thing that people are tripping over license-wise is >>libpq. But I think we would want to keep that as lean and mean as >>possible, too. >> >> > >erm, I'm not really sure what you're saying here but perhaps I can >clarify: I wasn't suggesting to add any serious amount of source code >to PostgreSQL - NSS would be used just as OpenSSL is today, and as >GNUTLS support was proposed, a seperate library which is distributed >independently of PostgreSQL but can be compiled against. I don't know > > > I suspect that Andrew was concerned about the dependency NSS has on NSPR. NSS dates back to the days before universal support for threads and mutexes. NSPR was (is) a library designed to abstract platform differences in those areas, and to provide its own implementations where none was available in the OS (e.g. old MacOS, 16-bit Windows). So for example if you want to open an SSL connection using NSS you get to hand it an NSPR socket handle, not an OS socket (however, there are functions that allow construction of one from the other). For an application that has otherwise no need for cross-platform service abstraction, or that has already solved the problems NSPR solves in a different way, NSPR looks like a big ball of goo that you don't need. NSS can't exist in an application without NSPR. Having said that, except in the case of cooperative threading environments (do those exist today??), there's no requirement on the application to actually use NSPR for anything other than plumbing underneath NSS. Applications that want to handle their own I/O underneath the SSL library (particularly useful in servers) will often not be happy with NSS due to its layering above NSPR I/O.
* David Boreham (david_list@boreham.org) wrote:
> Stephen Frost wrote:
> >erm, I'm not really sure what you're saying here but perhaps I can
> >clarify: I wasn't suggesting to add any serious amount of source code
> >to PostgreSQL - NSS would be used just as OpenSSL is today, and as
> >GNUTLS support was proposed, a seperate library which is distributed
> >independently of PostgreSQL but can be compiled against. I don't know
> >
> I suspect that Andrew was concerned about the dependency NSS has on NSPR.
[...]
Ah, this does sound rather ugly and not something we'd want. The
particular library doesn't make a whole heck of alot of difference to me
provided it has the general functionality necessary and a compatible
license (where 'compatible' in this case really means 'Debian feels it
is compatible with the GPL'). It'd be wonderful if OpenSSL's license
was the same license PostgreSQL has. Honestly, we'd be happy to stop
pissing off both those who license their code under the GPL (by asking
for exceptions for OpenSSL) and core library maintainers (by asking for
GNUTLS support, though in general I like to have options).
Thanks,
Stephen
Stephen Frost wrote: -- Start of PGP signed section. > * David Boreham (david_list@boreham.org) wrote: > > Stephen Frost wrote: > > >erm, I'm not really sure what you're saying here but perhaps I can > > >clarify: I wasn't suggesting to add any serious amount of source code > > >to PostgreSQL - NSS would be used just as OpenSSL is today, and as > > >GNUTLS support was proposed, a seperate library which is distributed > > >independently of PostgreSQL but can be compiled against. I don't know > > > > > I suspect that Andrew was concerned about the dependency NSS has on NSPR. > [...] > > Ah, this does sound rather ugly and not something we'd want. The > particular library doesn't make a whole heck of alot of difference to me > provided it has the general functionality necessary and a compatible > license (where 'compatible' in this case really means 'Debian feels it > is compatible with the GPL'). It'd be wonderful if OpenSSL's license > was the same license PostgreSQL has. Honestly, we'd be happy to stop > pissing off both those who license their code under the GPL (by asking > for exceptions for OpenSSL) and core library maintainers (by asking for > GNUTLS support, though in general I like to have options). Keep in mind in most cases OpenSSL is already part of the operating system, unless you are using Win32. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Tue, Jan 02, 2007 at 01:29:35PM -0500, Stephen Frost wrote: > Would a patch to implement dual-support for OpenSSL and NSS be > acceptable? Would just replacing OpenSSL support with NSS support be When I was looking into this I looked at NSS, and eventually decided on GnuTLS. Why? Because I read the GnuTLS documentation and I understood it. The basic support for GnuTLS took a whole afternoon, the hard work was leving people with the choice of using OpenSSL. I read the OpenSSL docs too, but I still don't understand how it works properly. IMHO, GnuTLS has the advantage if being designed later which means details like: - Thread safety (GnuTLS is thread-safe by design, no locks needed) - Proper layering (creating your own I/O function is trivial) - Seperate namespace - Non-blocking support from the get-go were taken care of. Since people are citing maintainability as a concern, I think you really have wonder whether NSS is a better choice. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
* Bruce Momjian (bruce@momjian.us) wrote:
> Stephen Frost wrote:
> > Ah, this does sound rather ugly and not something we'd want. The
> > particular library doesn't make a whole heck of alot of difference to me
> > provided it has the general functionality necessary and a compatible
> > license (where 'compatible' in this case really means 'Debian feels it
> > is compatible with the GPL'). It'd be wonderful if OpenSSL's license
> > was the same license PostgreSQL has. Honestly, we'd be happy to stop
> > pissing off both those who license their code under the GPL (by asking
> > for exceptions for OpenSSL) and core library maintainers (by asking for
> > GNUTLS support, though in general I like to have options).
>
> Keep in mind in most cases OpenSSL is already part of the operating
> system, unless you are using Win32.
Debian, at least, doesn't consider it as such (wouldn't really make much
sense since you could claim everything in Debian is part of the OS).
That's my understanding anyway, and goes for pretty much everything in
Debian.
Thanks,
Stephen
Bruce Momjian wrote: > Keep in mind in most cases OpenSSL is already part of the operating > system, unless you are using Win32. > > My understanding is that the Debian people are saying the exception for libraries shipped with the OS does NOT apply to *other* libraries or programs that are shipped with the OS and linked to that library. (No, it doesn't make much sense to me either) cheers andrew
* Andrew Dunstan (andrew@dunslane.net) wrote:
> Bruce Momjian wrote:
> >Keep in mind in most cases OpenSSL is already part of the operating
> >system, unless you are using Win32.
>
> My understanding is that the Debian people are saying the exception for
> libraries shipped with the OS does NOT apply to *other* libraries or
> programs that are shipped with the OS and linked to that library.
This is kind of the flip-side of what I just said but is also correct,
in it's own way. In the end Debian doesn't feel the shipped-with-the-OS
exception in the GPL can apply.
> (No, it doesn't make much sense to me either)
Well, the GPL does say:
---
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 'unless that component itself accompanies the executable' bit would
be the problem for distributors who ship the whole thing as one OS.
Thanks,
Stephen
Martijn van Oosterhout wrote: >- Thread safety (GnuTLS is thread-safe by design, no locks needed) >- Proper layering (creating your own I/O function is trivial) >- Seperate namespace >- Non-blocking support from the get-go > >were taken care of. Since people are citing maintainability as a >concern, I think you really have wonder whether NSS is a better >choice. > > Well...IMO NSS has some things that GNU TLS does not (correct me if wrong on this, since my knowledge of GNU TLS is not extensive): 1. Very widely deployed, hence high level of confidence in its interoperability, higher level of trust by the crypto community. 2. Backed by several large commercial organizations, hence has support for new-fangled ciphers (elliptic curve ciphers for example, Suite B, etc) and also hardware crypto accelerators and hard tokens. 3. Used in a popular web browser, hence subject to a reasonably high level of effort to find and fix security bugs. 4. FIPS-140 certified. Used widely by US gubment. 5. Much work done over the years on crypto performance. BTW NSS is also thread-safe, has layering (perhaps not the kind of layering that everyone needs though) and supports non-blocking sockets. NSS and NSPR functions are sensibly prefixed so naming collisions should not occur. Note that I'm not pushing NSS for PG - my choice would be OpenSSL. Just presenting some info for balance, since I happen to know a something about NSS.
* Stephen Frost: > Ah, this does sound rather ugly and not something we'd want. The > particular library doesn't make a whole heck of alot of difference to me > provided it has the general functionality necessary and a compatible > license (where 'compatible' in this case really means 'Debian feels it > is compatible with the GPL'). And several (L)GPL-incompatible licensses. It wouldn't surprise me if there were a few applications released under licenses which are not GPL-compatible which also link to libpq.
* Florian Weimer (fw@deneb.enyo.de) wrote:
> * Stephen Frost:
> > Ah, this does sound rather ugly and not something we'd want. The
> > particular library doesn't make a whole heck of alot of difference to me
> > provided it has the general functionality necessary and a compatible
> > license (where 'compatible' in this case really means 'Debian feels it
> > is compatible with the GPL').
>
> And several (L)GPL-incompatible licensses. It wouldn't surprise me if
> there were a few applications released under licenses which are not
> GPL-compatible which also link to libpq.
I'd be very curious to know of any which are GPL, or especially LGPL,
incompatible. Please provide specifics (especially if they're part of
Debian) of such applications. If there's specific licenses you know of
I'd like to know too since I might be able to check those pretty easily.
Given that libc is LGPL any software under a license incompatible with
that (which seems like it'd be pretty hard to have...) would probably
not be distributable under Debian.
Thanks,
Stephen