Thread: 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@svana.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.
Attachment
> > 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@svana.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@gmail.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@svana.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.
Attachment
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@svana.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.
Attachment
lmyho <lm_yho@yahoo.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@yi.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@sss.pgh.pa.us> writes: > Tyler MacDonald <tyler@yi.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@mcnaught.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@mcnaught.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@g2switchworks.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
Allow linking against OpenSSL? (Was Re: Debian package for freeradius_postgresql module)
From
Tyler MacDonald
Date:
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@sss.pgh.pa.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@g2switchworks.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@g2switchworks.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
Re: Allow linking against OpenSSL? (Was Re: Debian package for freeradius_postgresql module)
From
Tyler MacDonald
Date:
Alan DeKok <aland@nitros9.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@g2switchworks.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@travelamericas.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
Attachment
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Tyler MacDonald <tyler@yi.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
Attachment
Stephen Frost <sfrost@snowman.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@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.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
Attachment
"Leif B. Kristensen" <leif@solumslekt.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@sss.pgh.pa.us) wrote: > > Stephen Frost <sfrost@snowman.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@g2switchworks.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@g2switchworks.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@g2switchworks.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@svana.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.
Attachment
Tom Lane <tgl@sss.pgh.pa.us> writes: > Stephen Frost <sfrost@snowman.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
Attachment
* Chris Travers (chris@metatrontech.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
Attachment
Stephen Frost <sfrost@snowman.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@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.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
Attachment
Stephen Frost <sfrost@snowman.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@svana.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.
Attachment
Martijn van Oosterhout <kleptog@svana.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@cryptsoft.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@svana.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
Attachment
Chris Travers <chris@metatrontech.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@svana.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@svana.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.
Attachment
Martijn van Oosterhout <kleptog@svana.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
-----Original Message----- From: "Tyler MacDonald"<tyler@yi.org> Sent: 10/04/06 21:08:29 To: "Chris Travers"<chris@verkiel.metatrontech.com>, "Tom Lane"<tgl@sss.pgh.pa.us>, "Chris Travers"<chris@verkiel.metatrontech.com>,"Chris Travers"<chris@travelamericas.com>, "Scott Marlowe"<smarlowe@g2switchworks.com>,"Douglas McNaught"<doug@mcnaught.org>, "lmyho"<lm_yho@yahoo.com>, "pgsql general"<pgsql-general@postgresql.org> Subject: Re: [GENERAL] Debian package for freeradius_postgresql module > GnuTLS is LGPL, which isn't quite as liberal as postgresql's > license, but should still be ubiqutous enough to be worthwhile. The note on the fsf directory (http://directory.fsf.org/gnutls.html) is a little off-putting: "The program is currently in development and at an alpha stage." Not to mention that from what I can see in a brief Google the Windows support is somewhat rudimentary. Regards, Dave -----Unmodified Original Message----- Martijn van Oosterhout <kleptog@svana.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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Dave Page <dpage@vale-housing.co.uk> wrote: > > GnuTLS is LGPL, which isn't quite as liberal as postgresql's > > license, but should still be ubiqutous enough to be worthwhile. > > The note on the fsf directory (http://directory.fsf.org/gnutls.html) is a little off-putting: > > "The program is currently in development and at an alpha stage." > > Not to mention that from what I can see in a brief Google the Windows > support is somewhat rudimentary. I don't think we should drop openssl support... just include gnutls support so that OS vendors that want to be able to link their libpq against GPL software (like debian) have that choice available. Cheers, Tyler
> -----Original Message----- > From: Tyler MacDonald [mailto:tyler@yi.org] > Sent: 10 April 2006 22:59 > To: Dave Page > Cc: chris@verkiel.metatrontech.com; tgl@sss.pgh.pa.us; > chris@travelamericas.com; smarlowe@g2switchworks.com; > doug@mcnaught.org; lm_yho@yahoo.com; pgsql-general@postgresql.org > Subject: Re: [GENERAL] Debian package for freeradius_postgresql module > > > I don't think we should drop openssl support... just > include gnutls support so that OS vendors that want to be > able to link their libpq against GPL software (like debian) > have that choice available. No, I'd be incredibly surprised (and vocal about it) if that were seriously proposed - I'm just pointing out some downsides to GnuTLS. Regards, Dave.
On Mon, Apr 10, 2006 at 02:58:50PM -0700, Tyler MacDonald wrote: > Dave Page <dpage@vale-housing.co.uk> wrote: > > > GnuTLS is LGPL, which isn't quite as liberal as postgresql's > > > license, but should still be ubiqutous enough to be worthwhile. > > > > The note on the fsf directory (http://directory.fsf.org/gnutls.html) is a little off-putting: > > > > "The program is currently in development and at an alpha stage." > > > > Not to mention that from what I can see in a brief Google the Windows > > support is somewhat rudimentary. > > I don't think we should drop openssl support... just include gnutls > support so that OS vendors that want to be able to link their libpq against > GPL software (like debian) have that choice available. Well, for a program in alpha stage it's working quite well. Just examining the Debian archives shows GnuTLS used by a few hundred packages, including apparently everything in Gnome (directly or indirectly). It would be worth looking into, to lay this case to rest, finally... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.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.
Attachment
Dave Page wrote: > The note on the fsf directory (http://directory.fsf.org/gnutls.html) is a little off-putting: > > "The program is currently in development and at an alpha stage." > > Not to mention that from what I can see in a brief Google the Windows support is somewhat rudimentary. > > Regards, Dave Not to mention that the API consists of functions prefixed by "GNUTLS_" (or something similar). GnuTLS is something I always try to prevent to install, there's a very good alternative called openssl :P The only proper fix for this licensing issue IMHO is to fix GPL, not to kludge in some GPL compliant library. The issue at hand obviously is licensing related, the software is not the problem. And the cause of the licensing problem is apparently a restriction in GPL. Fix that, problem solved. Regards, -- Alban Hertroys alban@magproductions.nl magproductions b.v. T: ++31(0)534346874 F: ++31(0)534346876 M: I: www.magproductions.nl A: Postbus 416 7500 AK Enschede // Integrate Your World //
> -----Original Message----- > From: Alban Hertroys [mailto:alban@magproductions.nl] > Sent: 11 April 2006 10:45 > To: Dave Page > Cc: tyler@yi.org; chris@verkiel.metatrontech.com; > tgl@sss.pgh.pa.us; chris@travelamericas.com; > smarlowe@g2switchworks.com; doug@mcnaught.org; > lm_yho@yahoo.com; pgsql-general@postgresql.org > Subject: Re: [GENERAL] Debian package for freeradius_postgresql module > > > The only proper fix for this licensing issue IMHO is to fix > GPL, not to kludge in some GPL compliant library. The issue > at hand obviously is licensing related, the software is not > the problem. And the cause of the licensing problem is > apparently a restriction in GPL. Fix that, problem solved. I was having similar thoughts but restrained from airing them for fear of starting a flamewar. I do find it somewhat ironic that some people seem to be being forced into using GNU software to resolve these issues that almost scream 'vendor lockin' and similar phrases normally aimed at Microsoft et al. by GNU/FSF proponents! Regards, Dave
On Tue, Apr 11, 2006 at 12:02:33PM +0100, Dave Page wrote: > > The only proper fix for this licensing issue IMHO is to fix > > GPL, not to kludge in some GPL compliant library. The issue > > at hand obviously is licensing related, the software is not > > the problem. And the cause of the licensing problem is > > apparently a restriction in GPL. Fix that, problem solved. > > I was having similar thoughts but restrained from airing them for fear > of starting a flamewar. I do find it somewhat ironic that some people > seem to be being forced into using GNU software to resolve these issues > that almost scream 'vendor lockin' and similar phrases normally aimed at > Microsoft et al. by GNU/FSF proponents! The GNU people write a an SSL library and you claim that people are being forced to use it. Perhaps you forgot about the Mozilla NSS library which also implements SSL, available under the MPL, GPL or LGPL? Hardly a vendor lock-in. The licence on OpenSSL clearly says: * 3. All advertising materials mentioning features or use of this * software must display the following acknowledgment: * "This product includes software developed by the OpenSSL Project * for use in the OpenSSL Toolkit. (http://www.openssl.org/)" Which quite clearly indicates that any time anyone mentions the SSL feature of PostgreSQL in "advertising material", they must include that line of text. I imagine at least the following pages on the website might need to be adjusted: http://www.postgresql.org/about/history http://www.postgresql.org/about/advantages One can debate whether they are "advertising meterials" or the enforcability of such a licence, but its intent is crystal clear. We should probably place something on the website warning commercial distributors of this restriction. This is the kind of crap the GPL is against, which is why it's incompatable, to raise awareness with people. See also the pgAdmin list for what they did: http://archives.postgresql.org/pgadmin-hackers/2004-09/msg00357.php Have a nice day, -- Martijn van Oosterhout <kleptog@svana.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.
Attachment
> -----Original Message----- > From: Martijn van Oosterhout [mailto:kleptog@svana.org] > Sent: 11 April 2006 14:02 > To: Dave Page > Cc: Alban Hertroys; tyler@yi.org; > chris@verkiel.metatrontech.com; tgl@sss.pgh.pa.us; > chris@travelamericas.com; smarlowe@g2switchworks.com; > doug@mcnaught.org; lm_yho@yahoo.com; pgsql-general@postgresql.org > Subject: Re: [GENERAL] Debian package for freeradius_postgresql module > > The GNU people write a an SSL library and you claim that > people are being forced to use it. Perhaps you forgot about > the Mozilla NSS library which also implements SSL, available > under the MPL, GPL or LGPL? Hardly a vendor lock-in. I was merely pointing out the similarities and do realise there are alternatives in this case. I have nothing against the GPL itself for those that want to use it. Personally after having to deal with what I can only describe as rude and arrogant fanatics from gnu.org I would never use it again myself though. > See also the pgAdmin list for what they did: > http://archives.postgresql.org/pgadmin-hackers/2004-09/msg00357.php I can only assume you didn't read that too closely, or didn't notice who you were replying to :-) Regards, Dave.
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@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment
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@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment
-----Original Message----- From: "Martijn van Oosterhout"<kleptog@svana.org> Sent: 22/04/06 15:11:38 To: "pgsql-general@postgresql.org"<pgsql-general@postgresql.org> Subject: Re: [GENERAL] Debian package for freeradius_postgresql module > 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. Err, what? It uses PQsocket & PQgetssl, both of which are official, supported functions that may be being used by countlessother apps for all we know. If libpq wasn't designed to allow apps to use the socket & SSL struct directly, whyinclude and document the APIs? Regards, Dave -----Unmodified Original Message----- 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@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
On Sat, Apr 22, 2006 at 04:30:21PM +0100, Dave Page wrote:
> > 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.
>
> Err, what? It uses PQsocket & PQgetssl, both of which are official,
> supported functions that may be being used by countless other apps
> for all we know. If libpq wasn't designed to allow apps to use the
> socket & SSL struct directly, why include and document the APIs?
AIUI, PQsocket was added back in 6.4 to allow users to do asyncronous
operations. ([1] Tom Lane)
int PQsocket (PGconn *conn);
Returns the Unix file descriptor for the socket connection to the
backend, or -1 if there is no open connection. This is a violation
of modularity, of course, but there is no alternative: an
application that needs asynchronous execution needs to be able to
use select() to wait for input from either the backend or any other
input streams it may have. To use select() the underlying socket
must be made visible.
PQgetssl was added in 2000 ([2] Magnus Hagander) with the comment:
* I added accessor function "SSL *PQgetssl(void)" to libpq,
to get the SSL structure. Any functions from OpenSSL can
then be used on this returned structure to get information.
* Made psql use this PQgetssl() function after initial
connection to report SSL status (only if enabled, of course)
It was added so users could "get information" about the connection, not
to read/write to the connection.
I don't disagree that this is proper use of the API, but I don't think
the original creators of the functions really considered this use. And
it makes it difficult to introduce an alternate SSL library. Don't
worry, psqlODBC will still be able to do it's thing...
[1] http://archives.postgresql.org/pgsql-hackers/1998-04/msg00611.php
[2] http://archives.postgresql.org/pgsql-patches/2000-08/msg00019.php
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.
Attachment
-----Original Message-----
From: "Martijn van Oosterhout"<kleptog@svana.org>
Sent: 22/04/06 16:44:33
To: "Dave Page"<dpage@vale-housing.co.uk>
Cc: "pgsql-general@postgresql.org"<pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Debian package for freeradius_postgresql module
> I don't disagree that this is proper use of the API, but I don't think
> the original creators of the functions really considered this use.
Maybe not, but their intent & commit logs are irrelevant as far as end use is concerned - the docs and API are the
onlythings we can reasonably expect users to consider.
> And
> it makes it difficult to introduce an
> alternate SSL library.
Well, hindsight is a wonderful thing :-)
> Don't
worry, psqlODBC will still be able to do it's
> thing...
Yes - 'intended use' or not though, please ensure that a GnuTLS (or implementation agnostic) equivalent to PQgetssl is
availableso we don't have to dictate library choice to people.
Regards, Dave
-----Unmodified Original Message-----
On Sat, Apr 22, 2006 at 04:30:21PM +0100, Dave Page wrote:
> > 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.
>
> Err, what? It uses PQsocket & PQgetssl, both of which are official,
> supported functions that may be being used by countless other apps
> for all we know. If libpq wasn't designed to allow apps to use the
> socket & SSL struct directly, why include and document the APIs?
AIUI, PQsocket was added back in 6.4 to allow users to do asyncronous
operations. ([1] Tom Lane)
int PQsocket (PGconn *conn);
Returns the Unix file descriptor for the socket connection to the
backend, or -1 if there is no open connection. This is a violation
of modularity, of course, but there is no alternative: an
application that needs asynchronous execution needs to be able to
use select() to wait for input from either the backend or any other
input streams it may have. To use select() the underlying socket
must be made visible.
PQgetssl was added in 2000 ([2] Magnus Hagander) with the comment:
* I added accessor function "SSL *PQgetssl(void)" to libpq,
to get the SSL structure. Any functions from OpenSSL can
then be used on this returned structure to get information.
* Made psql use this PQgetssl() function after initial
connection to report SSL status (only if enabled, of course)
It was added so users could "get information" about the connection, not
to read/write to the connection.
I don't disagree that this is proper use of the API, but I don't think
the original creators of the functions really considered this use. And
it makes it difficult to introduce an alternate SSL library. Don't
worry, psqlODBC will still be able to do it's thing...
[1] http://archives.postgresql.org/pgsql-hackers/1998-04/msg00611.php
[2] http://archives.postgresql.org/pgsql-patches/2000-08/msg00019.php
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.
"Dave Page" <dpage@vale-housing.co.uk> writes:
> From: "Martijn van Oosterhout"<kleptog@svana.org>
>> 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.
> Err, what? It uses PQsocket & PQgetssl, both of which are official,
> supported functions that may be being used by countless other apps for
> all we know.
Dave, weren't you paying attention to the recent discussion? GnuTLS
support will break anything using PQgetSSL, because it can't return
an OpenSSL struct if the underlying SSL library is GnuTLS. The current
thought is to return NULL, so as not to have apps actually crash by
trying to pass a GnuTLS struct to OpenSSL routines, but that isn't going
to make psqlODBC *work* in such a situation. You'd need to add code
that knows how to work with GnuTLS.
Martijn is being a bit disingenuous by giving the impression that
acceptance of his patch is a done deal. The compatibility issues
are serious enough that it's quite possible we'll reject it.
regards, tom lane
On Sat, Apr 22, 2006 at 01:23:51PM -0400, Tom Lane wrote: > "Dave Page" <dpage@vale-housing.co.uk> writes: > > Err, what? It uses PQsocket & PQgetssl, both of which are official, > > supported functions that may be being used by countless other apps for > > all we know. > > Dave, weren't you paying attention to the recent discussion? GnuTLS > support will break anything using PQgetSSL, because it can't return > an OpenSSL struct if the underlying SSL library is GnuTLS. The current > thought is to return NULL, so as not to have apps actually crash by > trying to pass a GnuTLS struct to OpenSSL routines, but that isn't going > to make psqlODBC *work* in such a situation. You'd need to add code > that knows how to work with GnuTLS. It's a messy situation. I hope we're not going require users to include both GnuTLS and OpenSSL in their source given you can't actually #include both in the same source easily (namespace issues). Like you say, backward compatability is important. > Martijn is being a bit disingenuous by giving the impression that > acceptance of his patch is a done deal. The compatibility issues > are serious enough that it's quite possible we'll reject it. Ouch. I hope I didn't give anyone that impression, I'd prefer to say I was being optimistic because I don't think the problems are insurmountable. I only wanted to point out that there's no point someone doing this as an SoC project before the associated issues have been sorted out... 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.
Attachment
-----Original Message-----
From: "Tom Lane"<tgl@sss.pgh.pa.us>
Sent: 22/04/06 18:23:58
To: "Dave Page"<dpage@vale-housing.co.uk>
Cc: "kleptog@svana.org"<kleptog@svana.org>, "pgsql-general@postgresql.org"<pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Debian package for freeradius_postgresql module
> Dave, weren't you paying attention to the recent discussion? GnuTLS
> support will break anything using PQgetSSL,
Yes - it was Martijn's implication that we shouldn't be using the API in the way we are that I objected to.
In my last email you'll note that I did ask him to provide an equivalent PQgetssl function in his patch to allow us to
workwith GnuTls in the same way that we do with OpenSSL.
Regards, Dave
-----Unmodified Original Message-----
"Dave Page" <dpage@vale-housing.co.uk> writes:
> From: "Martijn van Oosterhout"<kleptog@svana.org>
>> 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.
> Err, what? It uses PQsocket & PQgetssl, both of which are official,
> supported functions that may be being used by countless other apps for
> all we know.
Dave, weren't you paying attention to the recent discussion? GnuTLS
support will break anything using PQgetSSL, because it can't return
an OpenSSL struct if the underlying SSL library is GnuTLS. The current
thought is to return NULL, so as not to have apps actually crash by
trying to pass a GnuTLS struct to OpenSSL routines, but that isn't going
to make psqlODBC *work* in such a situation. You'd need to add code
that knows how to work with GnuTLS.
Martijn is being a bit disingenuous by giving the impression that
acceptance of his patch is a done deal. The compatibility issues
are serious enough that it's quite possible we'll reject it.
regards, tom lane