Re: Debian package for freeradius_postgresql module

Hello All,

We have a project which is built on postgresql and freeradius on debian system. I
have installed postgresql-8.1 on the Debian system, and lately freeradius-1.1.0
also. Things seems ok, but when we started to test, we found that the postgresql
module of freeradius is missing in the debian distribution!

After desperately checking, we were told that debian doesn't distribute the binary
module of freeradius for postgresql because of the incompatible license of these two
apps! However we can build the debian pkg from the source ourself if we need. So
we did it. But this problem: we got so many...so many warnings during the process
of building the debian packages, tons of the warnings! So although we have the
packages now, we don't know if we can use them with so many so many warnings??!

I want to post some of the warnings here for your advice. Please tell me with such
kind of warnings, will the built packages still usable?? Further more, I am afraid
it is because our system is not purly dev system, so that we got those warnings...
so, if any one of you could possibly help us to get a v1.1.0 postgresql module of
freeradius, I would be so much grateful!! Or, if you can help us to get the newest
v1.1.1 freeradius package set fro debian (include the postgresql module), that will
be great also! I deeply hope to get help from you...

We specifically need this module bacause the codes in postgresql to work with
freeradius have been built, can't imagine all work will be trashed...:(

Please see the warning samples:

radius.c: In function 'make_secret':
radius.c:167: warning: pointer targets in passing argument 2 of 'librad_MD5Update'
differ in signedness
radius.c: In function 'make_passwd':
radius.c:205: warning: pointer targets in passing argument 2 of 'librad_MD5Update'
differ in signedness
radius.c: In function 'make_tunnel_passwd':
radius.c:294: warning: pointer targets in passing argument 2 of 'librad_MD5Update'
differ in signedness

rlm_passwd.c: In function 'build_hash_table':
rlm_passwd.c:218: warning: pointer targets in passing argument 1 of 'hash' differ in
signedness
rlm_passwd.c:232: warning: pointer targets in passing argument 1 of 'hash' differ in
signedness
rlm_passwd.c: In function 'get_pw_nam':
rlm_passwd.c:299: warning: pointer targets in passing argument 1 of 'hash' differ in
signedness
rlm_passwd.c: In function 'passwd_authorize':
rlm_passwd.c:536: warning: pointer targets in assignment differ in signedness
rlm_preprocess.c: In function 'cisco_vsa_hack':
rlm_preprocess.c:126: warning: pointer targets in passing argument 1 of
'__builtin_strchr' differ in signedness
rlm_preprocess.c:144: warning: pointer targets in assignment differ in signedness
rlm_preprocess.c: In function 'rad_mangle':
rlm_preprocess.c:203: warning: pointer targets in passing argument 1 of
'__builtin_strchr' differ in signedness
rlm_preprocess.c:206: warning: pointer targets in passing argument 1 of 'strcpy'
differ in signedness
rlm_preprocess.c: In function 'huntgroup_access':
rlm_preprocess.c:375: warning: pointer targets in passing argument 1 of 'strNcpy'
differ in signedness
rlm_preprocess.c:376: warning: pointer targets in passing argument 1 of 'strlen'
differ in signedness
rlm_preprocess.c: In function 'add_nas_attr':
rlm_preprocess.c:404: warning: pointer targets in passing argument 1 of
'ip_hostname' differ in signedness
rlm_preprocess.c:425: warning: pointer targets in passing argument 1 of
'ip_hostname' differ in signedness
rlm_radutmp.c: In function 'radutmp_checksimul':
rlm_radutmp.c:658: warning: pointer targets in assignment differ in signedness
rlm_realm.c: In function 'check_for_realm':
rlm_realm.c:209: warning: pointer targets in passing argument 1 of 'strcpy' differ
in signedness
rlm_sql.c: In function 'sql_groupcmp':
rlm_sql.c:564: warning: pointer targets in passing argument 1 of 'strlen' differ in
signedness
rlm_sql.c:564: warning: pointer targets in passing argument 2 of '__builtin_strcmp'
differ in signedness
rlm_sql.c:564: warning: pointer targets in passing argument 2 of '__builtin_strcmp'
differ in signedness
rlm_sql.c:564: warning: pointer targets in passing argument 1 of 'strlen' differ in
signedness
rlm_sql.c:564: warning: pointer targets in passing argument 2 of '__builtin_strcmp'
differ in signedness
rlm_sql.c:564: warning: pointer targets in passing argument 2 of '__builtin_strcmp'
differ in signedness
rlm_sql.c: In function 'rlm_sql_authorize':
rlm_sql.c:824: warning: pointer targets in assignment differ in signedness
rlm_sql.c: In function 'rlm_sql_checksimul':
rlm_sql.c:1227: warning: pointer targets in assignment differ in signedness
...

Please advise me if these warnings are serious??

Any help would be greatly appreciated! Thank you!!

Regrads,
leo

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

On Thu, Apr 06, 2006 at 10:27:36AM -0700, lmyho wrote:
> After desperately checking, we were told that debian doesn't distribute the binary
> module of freeradius for postgresql because of the incompatible license of these two
> apps! However we can build the debian pkg from the source ourself if we need. So

Sounds terribly unlikely, PostgreSQLs licence doesn't conflict with any
use anywhere. Can you provide a reference?

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

> > After desperately checking, we were told that debian doesn't distribute the
> binary
> > module of freeradius for postgresql because of the incompatible license of these
> two
> > apps! However we can build the debian pkg from the source ourself if we need.
> So
>
> Sounds terribly unlikely, PostgreSQLs licence doesn't conflict with any
> use anywhere. Can you provide a reference?
>

I wish things are not like this too! so I won't have to go through so much trouble!
But that's what happened:-(

This is the ref was given:
The old / original BSD license is not compatible.
http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses

Anyway to change this?? So debian users can easily use postgresql and freeradius
together...

Thanks!!

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Martijn van Oosterhout <kleptog(at)svana(dot)org> wrote:
> On Thu, Apr 06, 2006 at 10:27:36AM -0700, lmyho wrote:
> > After desperately checking, we were told that debian doesn't distribute the binary
> > module of freeradius for postgresql because of the incompatible license of these two
> > apps! However we can build the debian pkg from the source ourself if we need. So
>
> Sounds terribly unlikely, PostgreSQLs licence doesn't conflict with any
> use anywhere. Can you provide a reference?

This looks like part of the debate:

http://lists.debian.org/debian-legal/2002/11/msg00254.html

I dont know if this applies to openssl though...

- Tyler

lmyho wrote:
>>>After desperately checking, we were told that debian doesn't distribute the
>>
>>binary
>>
>>>module of freeradius for postgresql because of the incompatible license of these
>>
>>two
>>
>>>apps! However we can build the debian pkg from the source ourself if we need.
>>
>>So
>>
>>Sounds terribly unlikely, PostgreSQLs licence doesn't conflict with any
>>use anywhere. Can you provide a reference?
>>
>
>
> I wish things are not like this too! so I won't have to go through so much trouble!
> But that's what happened:-(
>
> This is the ref was given:
> The old / original BSD license is not compatible.
> http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses
>
> Anyway to change this?? So debian users can easily use postgresql and freeradius
> together...

Changing the postgres license isn't going to happen - it has been
debated many many many times in the past (check the archives).

Those warnings come from freeradius, not postgres - so best ask on their
list whether they are serious or not.

--
Postgresql & php tutorials
http://www.designmagick.com/

Chris <dmagick(at)gmail(dot)com> writes:
>> This is the ref was given:
>> The old / original BSD license is not compatible.
>> http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses
>>
>> Anyway to change this?? So debian users can easily use postgresql and freeradius
>> together...

> Changing the postgres license isn't going to happen - it has been
> debated many many many times in the past (check the archives).

The PG license is *not* the "old" (advertising-clause) BSD license, but
the new one. What I gathered from the other link that was posted is
that Debian's license concern has nothing to do with the Postgres
license, but rather that they think freeradius and openssl have
incompatible licenses. So it's those two projects that you need to talk
to about this. We are just bystanders.

regards, tom lane

On Thu, Apr 06, 2006 at 02:39:44PM -0700, lmyho wrote:
> > Sounds terribly unlikely, PostgreSQLs licence doesn't conflict with any
> > use anywhere. Can you provide a reference?
> >
>
> I wish things are not like this too! so I won't have to go through so much trouble!
> But that's what happened:-(
>
> This is the ref was given:
> The old / original BSD license is not compatible.
> http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses

It's talking about BSD with advertising clause which doesn't apply to
postgresql which has the modified BSD licence. I mean, Debian ships
postgresql fine. Like I said, who said it isn't possible?

Have a ncie day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

On Thu, Apr 06, 2006 at 02:40:03PM -0700, Tyler MacDonald wrote:
> This looks like part of the debate:
>
> http://lists.debian.org/debian-legal/2002/11/msg00254.html
>
> I dont know if this applies to openssl though...

Oh right, they're claiming that they can't distribute freeradius using
postgresql because postgresql links to OpenSSL. freeradius is GPL which
makes for an incompatabilty. Not something PostgreSQL is responsible
for, given Debian could compile without SSL and the problem would be
solved.

About the only thing we could do is support GnuTLS, but that's about
it.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

lmyho <lm_yho(at)yahoo(dot)com> wrote:
> > Oh right, they're claiming that they can't distribute freeradius using
> > postgresql because postgresql links to OpenSSL. freeradius is GPL which
> > makes for an incompatabilty. Not something PostgreSQL is responsible
> > for, given Debian could compile without SSL and the problem would be
> > solved.

OK, I'm kind of confused about how the legal red tape works here.
Debian packages all sorts of GPL code, and both openssl and postgres are
released under more liberal licenses. About the only legal issue I could see
is the legalities surrounding the export of openssl, but I thought debian
had already found it's own way around that.

> > About the only thing we could do is support GnuTLS, but that's about
> > it.

I'm in love with debian, so if that's what it takes to get a package
people find useful in there, I'm all for it.

> It's just a little complicated for a common user like me. But if it can be
> solved by just going a bit harder way, like to make a debian package by
> our own, that's ok too, as long as we don't have to switch the os to make
> the two work together.

You may not even need to do that;

http://www1.apt-get.org/search.php?query=freeradius&submit=Submit+Query&arch%5B%5D=i386&arch%5B%5D=all

The second search result there includes two sets of
/etc/apt/sources.list lines that both provide freeradius-postgresql.

Cheers,
Tyler

Tyler MacDonald <tyler(at)yi(dot)org> writes:
> OK, I'm kind of confused about how the legal red tape works here.
> Debian packages all sorts of GPL code, and both openssl and postgres are
> released under more liberal licenses. About the only legal issue I could see
> is the legalities surrounding the export of openssl, but I thought debian
> had already found it's own way around that.

[ looks in openssl tarball... ] It looks like the openssl license is
essentially old-style BSD (ie, with advertising clause). If Debian is
being anal about refusing to ship old-BSD code linked to GPL code,
there's going to be a whole lot of stuff that doesn't support SSL on
Debian, not only Postgres. Or are they selectively enforcing this
policy against PG?

(FWIW, Red Hat doesn't seem to be worried about this ... you could
always migrate to Fedora ;-))

regards, tom lane

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Tyler MacDonald <tyler(at)yi(dot)org> writes:
>> OK, I'm kind of confused about how the legal red tape works here.
>> Debian packages all sorts of GPL code, and both openssl and postgres are
>> released under more liberal licenses. About the only legal issue I could see
>> is the legalities surrounding the export of openssl, but I thought debian
>> had already found it's own way around that.
>
> [ looks in openssl tarball... ] It looks like the openssl license is
> essentially old-style BSD (ie, with advertising clause). If Debian is
> being anal about refusing to ship old-BSD code linked to GPL code,
> there's going to be a whole lot of stuff that doesn't support SSL on
> Debian, not only Postgres. Or are they selectively enforcing this
> policy against PG?

I don't think so. I got curious and looked at what's on my Ubuntu
system: Courier IMAP is GPL with an additional clause that explicitly
allows linking with OpenSSL; Postfix has an Apache-ish license; Exim
is GPL and also explicitly allows linking with OpenSSL; Cyrus IMAP is
BSDish; Apache is non-GPL... I can't think offhand of anything that
is GPL and links with OpenSSL without an explicit clause permitting
same.

-Doug

Douglas McNaught <doug(at)mcnaught(dot)org> writes:
> I don't think so. I got curious and looked at what's on my Ubuntu
> system: Courier IMAP is GPL with an additional clause that explicitly
> allows linking with OpenSSL; Postfix has an Apache-ish license; Exim
> is GPL and also explicitly allows linking with OpenSSL; Cyrus IMAP is
> BSDish; Apache is non-GPL... I can't think offhand of anything that
> is GPL and links with OpenSSL without an explicit clause permitting
> same.

Hm. So can we lobby freeradius to tweak their license similarly?

regards, tom lane

On Fri, 2006-04-07 at 17:08, Tom Lane wrote:
> Douglas McNaught <doug(at)mcnaught(dot)org> writes:
> > I don't think so. I got curious and looked at what's on my Ubuntu
> > system: Courier IMAP is GPL with an additional clause that explicitly
> > allows linking with OpenSSL; Postfix has an Apache-ish license; Exim
> > is GPL and also explicitly allows linking with OpenSSL; Cyrus IMAP is
> > BSDish; Apache is non-GPL... I can't think offhand of anything that
> > is GPL and links with OpenSSL without an explicit clause permitting
> > same.
>
> Hm. So can we lobby freeradius to tweak their license similarly?

I thought from Douglas' message, it appeared BSD packages didn't need
such a clause...

Scott Marlowe <smarlowe(at)g2switchworks(dot)com> writes:
> I thought from Douglas' message, it appeared BSD packages didn't need
> such a clause...

GPL partisans feel that BSD-with-advertising-clause is not compatible
with the GPL. I think the sticking point here is that openssl is using
an advertising clause.

regards, tom lane

Greetings FreeRadius people,

This discussion started on the postgresql's "pgsql-general" mailing
list. The problem here is that the freeradius-postgresql package needs to
link against libpgsql, which means that it may be indirectly linked against
openssl. There is a conflict between OpenSSL's BSD license and the GPL which
means that it's not legal to distribute a copy of GPL code that is linked in
this way. It appears that several other GPL apps have added a special clause
to their license that allows them to be linked against OpenSSL.

Could this be done for freeradius/freeradius-postgresql as well?
This could pave the way towards enhanced freeradius support in Debian,
specifically the addition of freeradius-postgresql to Debian's mainline.

For your reference, here is the start of the thread on the
pgsql-general list that got us to this point:

http://archives.postgresql.org/pgsql-general/2006-04/msg00247.php

Thanks,
Tyler

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > I don't think so. I got curious and looked at what's on my Ubuntu
> > system: Courier IMAP is GPL with an additional clause that explicitly
> > allows linking with OpenSSL; Postfix has an Apache-ish license; Exim
> > is GPL and also explicitly allows linking with OpenSSL; Cyrus IMAP is
> > BSDish; Apache is non-GPL... I can't think offhand of anything that
> > is GPL and links with OpenSSL without an explicit clause permitting
> > same.
> Hm. So can we lobby freeradius to tweak their license similarly?

On Fri, 2006-04-07 at 17:16, Tom Lane wrote:
> Scott Marlowe <smarlowe(at)g2switchworks(dot)com> writes:
> > I thought from Douglas' message, it appeared BSD packages didn't need
> > such a clause...
>
> GPL partisans feel that BSD-with-advertising-clause is not compatible
> with the GPL. I think the sticking point here is that openssl is using
> an advertising clause.

But the way Douglas' message read, it was only GPL packages that should
be affected, and we're not GPL. Or did I or Douglas misunderstand the
situation?

On Fri, 2006-04-07 at 17:24, Tyler MacDonald wrote:
> Greetings FreeRadius people,
>
> This discussion started on the postgresql's "pgsql-general" mailing
> list. The problem here is that the freeradius-postgresql package needs to
> link against libpgsql, which means that it may be indirectly linked against
> openssl. There is a conflict between OpenSSL's BSD license and the GPL which
> means that it's not legal to distribute a copy of GPL code that is linked in
> this way. It appears that several other GPL apps have added a special clause
> to their license that allows them to be linked against OpenSSL.
>
> Could this be done for freeradius/freeradius-postgresql as well?
> This could pave the way towards enhanced freeradius support in Debian,
> specifically the addition of freeradius-postgresql to Debian's mainline.
>
> For your reference, here is the start of the thread on the
> pgsql-general list that got us to this point:
>
> http://archives.postgresql.org/pgsql-general/2006-04/msg00247.php

Please note that PostgreSQL is NOT GPL, but BSD. Just sayin'

Scott Marlowe <smarlowe(at)g2switchworks(dot)com> wrote:
> > GPL partisans feel that BSD-with-advertising-clause is not compatible
> > with the GPL. I think the sticking point here is that openssl is using
> > an advertising clause.
>
> But the way Douglas' message read, it was only GPL packages that should
> be affected, and we're not GPL. Or did I or Douglas misunderstand the
> situation?

It's freeradius that's GPL. Then we break GPL rules by importing
OpenSSL. Guilt by association. :)

- Tyler

Alan DeKok <aland(at)nitros9(dot)org> wrote:
> > It appears that several other GPL apps have added a special clause
> > to their license that allows them to be linked against OpenSSL.
> >
> > Could this be done for freeradius/freeradius-postgresql as well?
>
> I have no objection to that.
>
> Debian should at least be able to distribute their version of source
> packages, that will build binaries against the distributed binary packages.
>
> Alan DeKok.

Thanks Alan!!! Can we look forward to this clause in the next
version of FreeRadius? Is the next version due to come out anytime soon?

Thanks,
Tyler

Tyler MacDonald wrote:

>Scott Marlowe <smarlowe(at)g2switchworks(dot)com> wrote:
>
>
>>But the way Douglas' message read, it was only GPL packages that should
>>be affected, and we're not GPL. Or did I or Douglas misunderstand the
>>situation?
>>
>>
>
> It's freeradius that's GPL. Then we break GPL rules by importing
>OpenSSL. Guilt by association. :)
>
>
IANAL, but this seems pretty problematic an interpretation of the GPL.

By this interpretation, coding a connector against UNIX ODBC would be
OK, but the user would be forbidden to use ODBC drivers that link
against OpenSSL. I cannot therefore imagine a circumstance where the
parent GPL application could be considered a dirivative work.

Indeed indirect linking is a pretty common GPL dodge, given NVidia's
approach to drivers.

What really seems to be happening here is that the Debian community
seems to be taking a stand which has little to do with the wording of
the GPL and more of an issue of "we don't like what NVidia is doing wrt
Linux drivers, so we are going to implement a policy that prevents it."
We are, unfortunately, caught in the crossfire.

My own opinion is this: The Debian crowd are often technical enough
they can build whatever they want from source. Debian is a niche
distribution and not something we should spend too much time worrying
about whether our software can be indirectly linked with GPL apps on
their site.

BTW, does this also mean that no GNU Readline is available in the Debian
versions of psql? Or am I missing something?

Best Wishes,
Chris Travers
Metatron Technology Consulting

Chris Travers <chris(at)travelamericas(dot)com> wrote:
> My own opinion is this: The Debian crowd are often technical enough
> they can build whatever they want from source. Debian is a niche
> distribution and not something we should spend too much time worrying
> about whether our software can be indirectly linked with GPL apps on
> their site.

Debian a niche distribution? I'd hardly call the defacto standard
GNU Linux distribution a "niche"...

> BTW, does this also mean that no GNU Readline is available in the Debian
> versions of psql? Or am I missing something?

AFAIK psql doesn't have the BSD advertising clause (does it??)...
and that's the piece that's incompatible with the GPL.

Cheers,
Tyler

On Saturday 08 April 2006 01:21, Tyler MacDonald wrote:
>Debian a niche distribution? I'd hardly call the defacto standard
>GNU Linux distribution a "niche"...

Surely, Debian is "niche". Why else should there be a need for
distributions like Gentoo?

I once tried to run Debian, and asked for help on some probably
elementary question on the Debian users list. All I got in the way of
help was "read the f*ing manual". Sure, very helpful indeed. Later, I
installed Gentoo and was positively amazed at the level of help you
would get on the Gentoo-forum. I never looked back to Debian.
--
Leif Biberg Kristensen | Registered Linux User #338009
http://solumslekt.org/ | Cruising with Gentoo/KDE

Tyler MacDonald wrote:

>Greetings FreeRadius people,
>
> This discussion started on the postgresql's "pgsql-general" mailing
>list. The problem here is that the freeradius-postgresql package needs to
>link against libpgsql, which means that it may be indirectly linked against
>openssl. There is a conflict between OpenSSL's BSD license and the GPL which
>means that it's not legal to distribute a copy of GPL code that is linked in
>this way. It appears that several other GPL apps have added a special clause
>to their license that allows them to be linked against OpenSSL.
>
>
IANAL, but I don't think that this argument flies. I don't think that
indirect linking constitutes derivation. Indeed I don't think that
linking constitutes derivation absent other factors. At least in the
9th Circuit, you have the Gates test (Gates Rubber, not Bill Gates),
which might well suggest that linking is *not* derivation at least in
this jurisdiction.

Generally for one work to be a derivative of another, you have to have
some degree of derivation which is evident. This need not be literal
copying. But hte line migh be quite fuzzy-- for example, a program
which makes extensive use of a non-standard Windows API might be argued
to be a derivative work of Windows (MySQL used to make a similar
argument regarding dependance on their client libraries, so this is not
that far fetched).

The direction Debian is taking this seems rediculous in the extreme--
that one might need a license to develop software for Windows, just like
you would if you wanted to use MySQL only via ODBC....

Best WIshes,
Chris Travers
Metatron Technology Consulting

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Tyler MacDonald <tyler(at)yi(dot)org> writes:
> > OK, I'm kind of confused about how the legal red tape works here.
> > Debian packages all sorts of GPL code, and both openssl and postgres are
> > released under more liberal licenses. About the only legal issue I could see
> > is the legalities surrounding the export of openssl, but I thought debian
> > had already found it's own way around that.
>
> [ looks in openssl tarball... ] It looks like the openssl license is
> essentially old-style BSD (ie, with advertising clause). If Debian is
> being anal about refusing to ship old-BSD code linked to GPL code,
> there's going to be a whole lot of stuff that doesn't support SSL on
> Debian, not only Postgres. Or are they selectively enforcing this
> policy against PG?

It's enforced whenever we discover it, really... Alot of applications
are able to be built against GNUTLS which is LGPL and removes the issue
as well. Debian actually worked to port OpenLDAP to GNUTLS to deal with
this problem with all of the (quite a few...) GPL'd LDAP-using
applications we package. I was involved in that effort actually (though
didn't actually do the GNUTLS port, that was mainly done by Steve
Langasek).

I'd like to look into doing this for Postgres, actually... I don't
think it'd hurt for Postgres to support OpenSSL and GNUTLS.

Thanks,

Stephen

Stephen Frost <sfrost(at)snowman(dot)net> writes:
>> Or are they selectively enforcing this
>> policy against PG?

> It's enforced whenever we discover it, really...

I am strongly tempted to pull Debian's chain by pointing out that
libjpeg has an advertising clause (a much weaker one than openssl's,
but nonetheless it wants you to acknowledge you used it) and demanding
they rebuild all their GPL'd desktop apps without JPEG support forthwith.

I'm with Chris Travers on this: it's a highly questionable reading
of the GPL, and I don't see why we should have to jump through extra
hoops (like make-work porting efforts) to satisfy debian-legal. It's
especially stupid because this is GPL code depending on BSD code, not
vice versa.

regards, tom lane

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> >> Or are they selectively enforcing this
> >> policy against PG?
>
> > It's enforced whenever we discover it, really...
>
> I am strongly tempted to pull Debian's chain by pointing out that
> libjpeg has an advertising clause (a much weaker one than openssl's,
> but nonetheless it wants you to acknowledge you used it) and demanding
> they rebuild all their GPL'd desktop apps without JPEG support forthwith.

Feel free to.

> I'm with Chris Travers on this: it's a highly questionable reading
> of the GPL, and I don't see why we should have to jump through extra
> hoops (like make-work porting efforts) to satisfy debian-legal. It's
> especially stupid because this is GPL code depending on BSD code, not
> vice versa.

I don't feel it's a questionable reading of the GPL at all. In fact,
it's pretty clear and I'm about 99% sure the FSF has commented on this
as well. It's true that it's unlikely anyone would actually sue Debian
over it but that doesn't somehow change what the licenses say.
Additionally, I think supporting GNUTLS would be a good thing for
Postgres to do even without this issue. I'd also like to see it support
SASL and a k5login-style user-controllable mapping.

Thanks,

Stephen

"Leif B. Kristensen" <leif(at)solumslekt(dot)org> writes:

> On Saturday 08 April 2006 01:21, Tyler MacDonald wrote:
>>Debian a niche distribution? I'd hardly call the defacto standard
>>GNU Linux distribution a "niche"...
>
> Surely, Debian is "niche". Why else should there be a need for
> distributions like Gentoo?
>
> I once tried to run Debian, and asked for help on some probably
> elementary question on the Debian users list. All I got in the way of
> help was "read the f*ing manual". Sure, very helpful indeed. Later, I
> installed Gentoo and was positively amazed at the level of help you
> would get on the Gentoo-forum. I never looked back to Debian.

You can dislike it all you want (and I'm not saying you don't have
reason to), but Debian is *not* "niche". There are a *lot* of servers
out there running it, and it's also the basis for Ubuntu, which by
itself is at least as popular as Gentoo from what I can see.

On the server side, I'd put Debian in the top three along with RH and
SuSE. Even if the mailing lists are unfriendly.

But we're wandering off-topic. :)

-Doug

On Fri, 2006-04-07 at 19:13, Stephen Frost wrote:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > >> Or are they selectively enforcing this
> > >> policy against PG?
> >
> > > It's enforced whenever we discover it, really...
> >
> > I am strongly tempted to pull Debian's chain by pointing out that
> > libjpeg has an advertising clause (a much weaker one than openssl's,
> > but nonetheless it wants you to acknowledge you used it) and demanding
> > they rebuild all their GPL'd desktop apps without JPEG support forthwith.
>
> Feel free to.
>
> > I'm with Chris Travers on this: it's a highly questionable reading
> > of the GPL, and I don't see why we should have to jump through extra
> > hoops (like make-work porting efforts) to satisfy debian-legal. It's
> > especially stupid because this is GPL code depending on BSD code, not
> > vice versa.
>
> I don't feel it's a questionable reading of the GPL at all. In fact,
> it's pretty clear and I'm about 99% sure the FSF has commented on this
> as well. It's true that it's unlikely anyone would actually sue Debian
> over it but that doesn't somehow change what the licenses say.
> Additionally, I think supporting GNUTLS would be a good thing for
> Postgres to do even without this issue. I'd also like to see it support
> SASL and a k5login-style user-controllable mapping.

So, do GPL have this problem linking against OpenSSL as well?

Scott Marlowe <smarlowe(at)g2switchworks(dot)com> writes:

>> I don't feel it's a questionable reading of the GPL at all. In fact,
>> it's pretty clear and I'm about 99% sure the FSF has commented on this
>> as well. It's true that it's unlikely anyone would actually sue Debian
>> over it but that doesn't somehow change what the licenses say.
>> Additionally, I think supporting GNUTLS would be a good thing for
>> Postgres to do even without this issue. I'd also like to see it support
>> SASL and a k5login-style user-controllable mapping.
>
> So, do GPL have this problem linking against OpenSSL as well?

Yes, that's why GPL apps like Exim and Courier have explicit license
clauses permitting it.

-Doug

On Fri, 2006-04-07 at 19:31, Douglas McNaught wrote:
> Scott Marlowe <smarlowe(at)g2switchworks(dot)com> writes:
>
> >> I don't feel it's a questionable reading of the GPL at all. In fact,
> >> it's pretty clear and I'm about 99% sure the FSF has commented on this
> >> as well. It's true that it's unlikely anyone would actually sue Debian
> >> over it but that doesn't somehow change what the licenses say.
> >> Additionally, I think supporting GNUTLS would be a good thing for
> >> Postgres to do even without this issue. I'd also like to see it support
> >> SASL and a k5login-style user-controllable mapping.
> >
> > So, do GPL have this problem linking against OpenSSL as well?
>
> Yes, that's why GPL apps like Exim and Courier have explicit license
> clauses permitting it.

So, it's freeradius that needs the exception then, right?

Scott Marlowe <smarlowe(at)g2switchworks(dot)com> wrote:
> > >> I don't feel it's a questionable reading of the GPL at all. In fact,
> > >> it's pretty clear and I'm about 99% sure the FSF has commented on this
> > >> as well. It's true that it's unlikely anyone would actually sue Debian
> > >> over it but that doesn't somehow change what the licenses say.
> > >> Additionally, I think supporting GNUTLS would be a good thing for
> > >> Postgres to do even without this issue. I'd also like to see it support
> > >> SASL and a k5login-style user-controllable mapping.
> > >
> > > So, do GPL have this problem linking against OpenSSL as well?
> >
> > Yes, that's why GPL apps like Exim and Courier have explicit license
> > clauses permitting it.
>
> So, it's freeradius that needs the exception then, right?

Good morning Scott, would you like some coffee? :-)

- Tyler

On Fri, Apr 07, 2006 at 04:16:18PM -0700, Chris Travers wrote:
> By this interpretation, coding a connector against UNIX ODBC would be
> OK, but the user would be forbidden to use ODBC drivers that link
> against OpenSSL. I cannot therefore imagine a circumstance where the
> parent GPL application could be considered a dirivative work.
>
> Indeed indirect linking is a pretty common GPL dodge, given NVidia's
> approach to drivers.

Please keep in mind that this has nothing to do with what users can or
cannot do. The GPL is a *distribution* licence. It says, in no
uncertain terms, that GPL programs must come with complete source of
themselves and all dependancies under terms compatible with the GPL.
The advertising clause in OpenSSL is not acceptable.

Hence, Debian *as a distribution* cannot distribute precompiled
binaries (freeradius) that would cause a GPL program to depend on code
that cannot be distributed on compatable terms. People are ofcourse
free to download the source themselves, they're just not allowed to
distribute the resulting binaries.

The issue is that installing freeradius-postgresql would install
OpenSSL on the user's machine because libpq requires it. That's what's
wrong with your example, the ODBC connector doesn't depend on OpenSSL
so programs using it don't either.

Did anyone notice the last few lines of the freeradius copyright file?
It lists the modules in freeradius that directly or indirectly depend on
OpenSSL and thus cannot be distributed *in precompiled form*.

http://packages.debian.org/changelogs/pool/main/f/freeradius/freeradius_1.1.0-1.1/freeradius.copyright

> BTW, does this also mean that no GNU Readline is available in the Debian
> versions of psql? Or am I missing something?

What has this to do with anything? We're talking about libpq depending
on a GPL incompatable library, which GNU Readline obviously isn't.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> >> Or are they selectively enforcing this
> >> policy against PG?
>
> > It's enforced whenever we discover it, really...
>
> I am strongly tempted to pull Debian's chain by pointing out that
> libjpeg has an advertising clause (a much weaker one than openssl's,
> but nonetheless it wants you to acknowledge you used it) and demanding
> they rebuild all their GPL'd desktop apps without JPEG support forthwith.

Except that's the GPL'd applications' licenses that are being violated, not
yours. On the other hand have you checked any of the commercial products based
on Debian to see if they're satisfying your advertising clause?

I thought there was also a separate thread in this story in that the
advertising clause was considered legally unenforceable and hence not really a
problem for the GPL anyways. I'm not sure what happened to that story though
and whether it was ever considered the case outside the US.

> I'm with Chris Travers on this: it's a highly questionable reading
> of the GPL, and I don't see why we should have to jump through extra
> hoops (like make-work porting efforts) to satisfy debian-legal. It's
> especially stupid because this is GPL code depending on BSD code, not
> vice versa.

FWIW in any of the cases like where GPL'd application authors have actually
pursued the issue the alleged infringers have always backed down after
checking with lawyers. The classic example being the Objective-C frontend for
gcc. In that case it was even *more* decoupled in that there wasn't even
shared library linkage. It was purely a command-line and file format
interface.

Note that (as I understand it) nobody is saying Postgres is infringing on
anything. Only that combining postgres with OpenSSL and Freeradius results in
a combination of license restrictions that can't all be met at the same time.
So the resulting binary package (which is useless without those other pieces
of software) can't be legally distributed.

--
greg

As someone who licenses a lot of my code under the GPL, I feel inclined
to correct you. Please note that IANAL.

Martijn van Oosterhout wrote:

>On Fri, Apr 07, 2006 at 04:16:18PM -0700, Chris Travers wrote:
>
>
>>By this interpretation, coding a connector against UNIX ODBC would be
>>OK, but the user would be forbidden to use ODBC drivers that link
>>against OpenSSL. I cannot therefore imagine a circumstance where the
>>parent GPL application could be considered a dirivative work.
>>
>>Indeed indirect linking is a pretty common GPL dodge, given NVidia's
>>approach to drivers.
>>
>>
>
>Please keep in mind that this has nothing to do with what users can or
>cannot do. The GPL is a *distribution* licence.
>
No. It is a copyright license. It gives you the right to distribute
the original work, create and distribute derivative works, etc. If it
didn't give you the right to modify the code, then any code
modifications would be subject to fair use law which doesn't exist in
some places in the world (like Australia, for example).

As for its scope, we may have to agree to disagree, or at least
acknowledge that it may have different scopes in different places.

Nowhere in the license does it say that you cannot link with other
software. The FSF has been pretty clear that they consider linking to
be analogous to derivation (and in many cases, it might be). Indeed the
GPL v2 is no more clear on the matter of derivation than simply to refer
to existing case law in whatever jurisdiction the coder happens to be in.

For example, the FSF convinced Apple that they needed to comply the GPL
when they were distributing binary objective C plugins to the GCC and
then providing information for people to link them themselves. The
result was that the GCC got open source Objective C support thanks to
Apple. Do we know whether these plugins were really derivative works or
not? Not really. But Apple chose not to fight it in court.

However, there are clearly cases where linking would not be derivation
in many jurisdictions. For example, if I create a perfectly
standards-compliant ANSI C library, and I release it under the GPL,
anyone can code ANSI C and use any number of C libraries in their
compilation. The fact that one happens to compile it against my GPL
work instead of any others would seem to be, while possibly an
invitation to litigation, a pretty clear case of standard interfaces
instead of derivation.

At least in the US (IANAL, again), not everything can be copyrighted. I
personally doubt that header files would be copyrightable for the
purpose of making #include statements constitute derivation. Especially
in the 9th Circuit, where you have the Gates Rubber test, I would think
that the filtration step would remove any code copied by the compiler as
a matter of making the program work with standard interfaces. THus with
my ANSI C library, I don't think mere compilation against the GPL'd
version would constitute derivation, but IANAL.

> It says, in no
>uncertain terms, that GPL programs must come with complete source of
>themselves and all dependancies under terms compatible with the GPL.
>The advertising clause in OpenSSL is not acceptable.
>
>
No it doesn't. Otherwise you couldn't release a GPL'd program for
Windows. It actually says that the derivative work as a whole must be
released under the GPL. Whatever this means is up to the courts,
unfortunately. The FSF has their opinion on their web site, but
ultimately the only one who gets to interpret the license
authoritatively is the court. Because nobody wants to fight there is no
clear guidance.

Best Wishes,
Chris Travers
Metatron Technology Consulting

* Chris Travers (chris(at)metatrontech(dot)com) wrote:
> >It says, in no
> >uncertain terms, that GPL programs must come with complete source of
> >themselves and all dependancies under terms compatible with the GPL.
> >The advertising clause in OpenSSL is not acceptable.
> >
> >
> No it doesn't. Otherwise you couldn't release a GPL'd program for
> Windows. It actually says that the derivative work as a whole must be
> released under the GPL. Whatever this means is up to the courts,
> unfortunately. The FSF has their opinion on their web site, but
> ultimately the only one who gets to interpret the license
> authoritatively is the court. Because nobody wants to fight there is no
> clear guidance.

The courts are pretty likely to strongly consider the copyright holder's
opinion of the license when deciding how to interpret it. The fact that
it hasn't been well-tested in court doesn't mean it's not something to
be concerned with. Debian may be a little more cautious about this than
some other Linux distributions but if anything in their case it's
probably sensible since they don't have the funds to fight a court
battle.

Thanks,

Stephen

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> The courts are pretty likely to strongly consider the copyright holder's
> opinion of the license when deciding how to interpret it.

It's worth pointing out here that

1. Debian is not the copyright holder.

2. The copyright holders, in this case the authors of freeradius, saw
no problem with it. They'd hardly have written GPL-licensed software
that depends on a BSD-licensed package if they did, because the strict
intepretation says that their code is undistributable, and obviously
they intend to distribute it.

regards, tom lane

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > The courts are pretty likely to strongly consider the copyright holder's
> > opinion of the license when deciding how to interpret it.
>
> It's worth pointing out here that
>
> 1. Debian is not the copyright holder.

Not sure where you got the idea that I was suggesting they were, I
certainly wasn't.

> 2. The copyright holders, in this case the authors of freeradius, saw
> no problem with it. They'd hardly have written GPL-licensed software
> that depends on a BSD-licensed package if they did, because the strict
> intepretation says that their code is undistributable, and obviously
> they intend to distribute it.

GPL-licensed software depending on a BSD-licensed package *isn't* a
problem. If we didn't link Postgres w/ OpenSSL this wouldn't be any
issue at all. If the freeradius authors explicitly say they don't have
a problem linking against a BSD-with-advertising-clause license
(or even explicitly exempt OpenSSL) then it's all fine. Saying that
because they wrote freeradius to support Postgres that they implicitly
approve of the OpenSSL license is a more than a bit of a stretch.

Thanks,

Stephen

Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> GPL-licensed software depending on a BSD-licensed package *isn't* a
> problem. If we didn't link Postgres w/ OpenSSL this wouldn't be any
> issue at all. If the freeradius authors explicitly say they don't have
> a problem linking against a BSD-with-advertising-clause license
> (or even explicitly exempt OpenSSL) then it's all fine. Saying that
> because they wrote freeradius to support Postgres that they implicitly
> approve of the OpenSSL license is a more than a bit of a stretch.

Well, Alan DeKok, the creator of freeradius, has said that he has no
problem altering the license, but other contributors to the project have
raised some concerns. I guess we'll just wait and see how it all pans out.
One interesting point came up on the freeradius-users list; we should also
be discussing this with the OpenSSL people to see if they're willing to
remove the advertising clause from their license. I've subscribed to the
OpenSSL list to ask about this but havent posted anything yet.

Cheers,
Tyler

On Sun, Apr 09, 2006 at 10:26:35AM -0700, Tyler MacDonald wrote:
> Well, Alan DeKok, the creator of freeradius, has said that he has no
> problem altering the license, but other contributors to the project have
> raised some concerns. I guess we'll just wait and see how it all pans out.
> One interesting point came up on the freeradius-users list; we should also
> be discussing this with the OpenSSL people to see if they're willing to
> remove the advertising clause from their license. I've subscribed to the
> OpenSSL list to ask about this but havent posted anything yet.

To save you some time: this has been rehashed on the OpenSSL lists and
the conclusion is basically:

1. It's not a problem, it's the GPLs problem
2. It doesn't appear they can change the licence for some reason

We are not the first people to run into this, nor will we be the last.
The only long term solution is to use GnuTLS instead which doesn't have
these issues (it's straight LGPL). This is something postgresql can and
would solve the problem entirely.

These links may be helpful.

[1] http://marc.theaimsgroup.com/?l=openssl-users&m=97417764222228&w=2
[2] http://www.openssl.org/support/faq.html#LEGAL2
[3] http://www.ethereal.com/lists/ethereal-dev/200108/msg00120.html

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Martijn van Oosterhout <kleptog(at)svana(dot)org> wrote:
> To save you some time: this has been rehashed on the OpenSSL lists and
> the conclusion is basically:
>
> 1. It's not a problem, it's the GPLs problem
> 2. It doesn't appear they can change the licence for some reason
>
> We are not the first people to run into this, nor will we be the last.
> The only long term solution is to use GnuTLS instead which doesn't have
> these issues (it's straight LGPL). This is something postgresql can and
> would solve the problem entirely.

I'd call that the short term solution, with the long term solution
being to finally convince the right people to remove that clause from
OpenSSL's license.

> [1] http://marc.theaimsgroup.com/?l=openssl-users&m=97417764222228&w=2

That one definately helped, thanks. :-) Following that thread, I got
here:

http://marc.theaimsgroup.com/?l=openssl-users&m=97419073107910&w=2

Which seems to indicate that the people that need to be pestered are
Eric Young and Tim Hudson.

I've got to wonder how legal the SSLeay clause is though;

* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* "This product includes cryptographic software written by
* Eric Young (eay(at)cryptsoft(dot)com)"
* The word 'cryptographic' can be left out if the rouines from the library
* being used are not cryptographic related :-).

"rouines"? ;-)

Cheers,
Tyler

Tyler MacDonald wrote:

>Martijn van Oosterhout <kleptog(at)svana(dot)org> wrote:
>
>
>>
>>
>
> I'd call that the short term solution, with the long term solution
>being to finally convince the right people to remove that clause from
>OpenSSL's license.
>
>
>
As I have said before, I think it is Debian's problem at least from the
perspective of an American (I don't know if other countries might have
different views of derivation).

What about getting those who wrote the FreeRadius module that support
PostgreSQL to add the exception? Would that be sufficient? Or are we
about to sue nVidia over their failure to release the code for their
drivers?

Best Wishes,
Chris Travers
Metatron Technology Consulting

Chris Travers <chris(at)metatrontech(dot)com> wrote:
> > I'd call that the short term solution, with the long term solution
> >being to finally convince the right people to remove that clause from
> >OpenSSL's license.

> As I have said before, I think it is Debian's problem at least from the
> perspective of an American (I don't know if other countries might have
> different views of derivation).
>
> What about getting those who wrote the FreeRadius module that support
> PostgreSQL to add the exception? Would that be sufficient? Or are we
> about to sue nVidia over their failure to release the code for their
> drivers?

The creator of FreeRadius has said he has no problem adding an
exemption.. at lease one freeradius developer questions the action. I'm
hoping that this exemption gets put into freeradius, but what would be ideal
is if everybody in GPL land could link to OpenSSL without adding exemptions.
I've sent this mail to the OpenSSL list in the hope that it will help:

http://marc.theaimsgroup.com/?l=openssl-users&m=114460613316150&w=2

Cheers,
Tyler

On Sun, Apr 09, 2006 at 02:48:33PM -0700, Chris Travers wrote:
> Tyler MacDonald wrote:
>
> >Martijn van Oosterhout <kleptog(at)svana(dot)org> wrote:
> > I'd call that the short term solution, with the long term solution
> >being to finally convince the right people to remove that clause from
> >OpenSSL's license.
> >
> >
> >
> As I have said before, I think it is Debian's problem at least from the
> perspective of an American (I don't know if other countries might have
> different views of derivation).

Well, it's a Debian problem that possibly applies to Linux distrubutors
in general. Here is a good write up:

http://www.gnome.org/~markmc/openssl-and-the-gpl.html

The issue is that while anybody else can take advantage of the
"components usually part of the OS" clause, Debian as a distributor of
both, can't.

Derivation has nothing to do with it. Read the GPL, it says "complete
source code" includes "any associated interface definition files".
OpenSSL has header files which are necessary to compile libpq, right? I
know ssl support is optional, but Debian has to distribute the source
that produces what it distributes. Anybody they distribute to must be
able to produce executables functionally equivalent to what they
produce themselves.

So in fact it might be sufficient if OpenSSL relicenced their header
files only. Not that that helps.

BTW, here[1] states the issue is that one of the developers you'd have
to convince is Eric Young, who went off to work on a competitor to
OpenSSL. He's unlikely to make it any easier for people to use OpenSSL.

[1] http://www.winehq.com/hypermail/wine-license/2002/03/0161.html

> What about getting those who wrote the FreeRadius module that support
> PostgreSQL to add the exception? Would that be sufficient? Or are we
> about to sue nVidia over their failure to release the code for their
> drivers?

Not, sure. The postgresql module is part of the freeradius package. You
could only relicence it if all the writers of code in that module
(including code copied from other modules) agree. I doubt this would be
any less difficult.

The nvidia question is different. The Linux kernel licence
specifically allows binary kernel modules already.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Martijn van Oosterhout <kleptog(at)svana(dot)org> wrote:
> Well, it's a Debian problem that possibly applies to Linux distrubutors
> in general. Here is a good write up:
>
> http://www.gnome.org/~markmc/openssl-and-the-gpl.html
>
> The issue is that while anybody else can take advantage of the
> "components usually part of the OS" clause, Debian as a distributor of
> both, can't.

Thanks Martijn! I've forwarded that URL to the freeradius people.

> BTW, here[1] states the issue is that one of the developers you'd have
> to convince is Eric Young, who went off to work on a competitor to
> OpenSSL. He's unlikely to make it any easier for people to use OpenSSL.
>
> [1] http://www.winehq.com/hypermail/wine-license/2002/03/0161.html

Yup. I've tried to get an email out to him... Tim Hudson also works
with RSA and I've sent a comment to his blog and an email to the openssl
list, but I can't find any current email address for Eric himself.

> Not, sure. The postgresql module is part of the freeradius package. You
> could only relicence it if all the writers of code in that module
> (including code copied from other modules) agree. I doubt this would be
> any less difficult.

I think it will be less difficult, only because the instigators of
the licensing there are available for comment. :-)

I see this continuining to be a problem for the postgresql community
given how many GPLed projects use libpq. freeradius might be fixable with a
change in their license, but for postgresql to continue to be reasonably
usable by GPLed projects, either OpenSSL's license needs to change, or we
need to support an alternative secure socket api like GnuTLS.

GnuTLS is LGPL, which isn't quite as liberal as postgresql's
license, but should still be ubiqutous enough to be worthwhile.

Cheers,
Tyler

Tyler MacDonald wrote:

> I see this continuining to be a problem for the postgresql community
> given how many GPLed projects use libpq. freeradius might be fixable with a
> change in their license, but for postgresql to continue to be reasonably
> usable by GPLed projects, either OpenSSL's license needs to change, or we
> need to support an alternative secure socket api like GnuTLS.
>
> GnuTLS is LGPL, which isn't quite as liberal as postgresql's
> license, but should still be ubiqutous enough to be worthwhile.

As PostgreSQL is participating in Google Summer of Code 2006, perhaps
the GnuTLS support could be a student's project.

--
Nicolas Baradakis

On Sat, Apr 22, 2006 at 01:10:34AM +0200, Nicolas Baradakis wrote:
> Tyler MacDonald wrote:
>
> > I see this continuining to be a problem for the postgresql community
> > given how many GPLed projects use libpq. freeradius might be fixable with a
> > change in their license, but for postgresql to continue to be reasonably
> > usable by GPLed projects, either OpenSSL's license needs to change, or we
> > need to support an alternative secure socket api like GnuTLS.
> >
> > GnuTLS is LGPL, which isn't quite as liberal as postgresql's
> > license, but should still be ubiqutous enough to be worthwhile.
>
> As PostgreSQL is participating in Google Summer of Code 2006, perhaps
> the GnuTLS support could be a student's project.
>

Before someone runs off to consider this, I've already done it. My
preliminary patch is here:

http://svana.org/kleptog/temp/gnutls.patch

There are some issues with it, but nothing major. I plan on cleaning it
up and submitting it soon.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Martijn van Oosterhout wrote:

> On Sat, Apr 22, 2006 at 01:10:34AM +0200, Nicolas Baradakis wrote:
> > As PostgreSQL is participating in Google Summer of Code 2006, perhaps
> > the GnuTLS support could be a student's project.
>
> Before someone runs off to consider this, I've already done it. My
> preliminary patch is here:
>
> http://svana.org/kleptog/temp/gnutls.patch

I'm speechless. Everything is mostly done already: many, many thanks
for the good work.

> There are some issues with it, but nothing major. I plan on cleaning it
> up and submitting it soon.

Please ping me when the patch is completed. I'll talk to the Debian
maintainers of the PostgreSQL and FreeRADIUS packages: if they accept
to add GnuTLS support in a dpatch, the freeradius-postgresql module
can enter in the Debian repository in a short time.

--
Nicolas Baradakis

On Sat, Apr 22, 2006 at 03:47:51PM +0200, Nicolas Baradakis wrote:
> Martijn van Oosterhout wrote:
> > Before someone runs off to consider this, I've already done it. My
> > preliminary patch is here:
> >
> > http://svana.org/kleptog/temp/gnutls.patch
>
> I'm speechless. Everything is mostly done already: many, many thanks
> for the good work.

No problem.

> > There are some issues with it, but nothing major. I plan on cleaning it
> > up and submitting it soon.
>
> Please ping me when the patch is completed. I'll talk to the Debian
> maintainers of the PostgreSQL and FreeRADIUS packages: if they accept
> to add GnuTLS support in a dpatch, the freeradius-postgresql module
> can enter in the Debian repository in a short time.

Well, you need to be careful here. Just installing GnuTLS support as is
will break the latest release of psqlODBC, because they do things with
libpq that it wasn't really designed for. Now, I've added an interface
to propose a "proper" way for psqlODBC to do its stuff, but to have the
Debian package have an API change not present in upstream is a big
issue.

That, more than GnuTLS itself, is the issue holding it up.

OTOH, psqlODBC doesn't appear to be packaged in debian, so that may not
be relevent to you.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.