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/copyrightAnd 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 bind them...
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 bind them...
* 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
* 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 might have 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 each
direction 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 to
get that fixed)
GNUTLS has better documentation
Actually, from a comparison done for libcurl (which supports both):
GnuTLS vs OpenSSL
While these two libraries offer similar features, they are not equal. Both
libraries have features the other one lacks. libcurl does not (yet) offer a
standardized stable ABI if you decide to switch from using libcurl-openssl to
libcurl-gnutls or vice versa. The GnuTLS support is very recent in libcurl
and it has not been tested nor used very extensively, while the OpenSSL
equivalent 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 functions libcurl 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
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
* 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
