GNU readline and BSD license
Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.
Obviously, we could remove readline hooks and ship a BSD line editing
library, but does this make any sense to you? It doesn't make sense to
me, but he was quite certain.
Our ODBC library is also GNU licensed, but I am told this is not a
problem because it doesn't link into the backend. However, neither does
readline. However, readline does link into psql.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Bruce Momjian writes:
Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.This sort of thing is complete nonsense.
By the same logic you could argue that the system("cp template1 ...")
calls could force us to a GNU license, because 'cp' is from GNU fileutils.
Well, his issue was that 'cp' is not in the binary, while readline
_could_ be in the binary. My issue is that we only optionally link
in the library. We don't actually ship the library with our code.
Honestly, it made no sense to me either, and if it hadn't been Rasmus, I
would have written it off immediately.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Import Notes
Reply to msg id not found: Pine.LNX.4.30.0012231638530.1068-100000@peter.localdomain | Resolved by subject fallback
Bruce Momjian writes:
Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.
This sort of thing is complete nonsense.
By the same logic you could argue that the system("cp template1 ...")
calls could force us to a GNU license, because 'cp' is from GNU fileutils.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Sat, 23 Dec 2000, Bruce Momjian wrote:
Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.Obviously, we could remove readline hooks and ship a BSD line editing
library, but does this make any sense to you? It doesn't make sense to
me, but he was quite certain.
Unfortunately he's right, since GPL software is incompatible with any
non-GPL software. Stallman publically admitted that he intentionally
released readline under GPL, not LGPL, to force more people into GPLing
their code.
On Sat, 23 Dec 2000, Bruce Momjian wrote:
Rasmus Lerdorf, the big PHP developer, told me that the existence of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.Obviously, we could remove readline hooks and ship a BSD line editing
library, but does this make any sense to you? It doesn't make sense to
me, but he was quite certain.
Unfortunately he's right, since GPL software is incompatible with any
non-GPL software. Stallman publicly admitted that he intentionally
released readline under GPL, not LGPL, to force more people into GPLing
their code.
OK, but does shipping our code with hooks obligate us? We don't ship
readline.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026On Sat, 23 Dec 2000, Bruce Momjian wrote:
OK, but does shipping our code with hooks obligate us? We don't ship
readline.
Oh, oops. I didn't know readline wasn't in the postgres tree. Then,
obviously, distribution of .tar.gz does not obligate postgres to anything,
HOWEVER, the problem arises with distribution of binaries (.rpm and
others) which are linked against libreadline _statically_ (basically, we
can't do it). Our RPM distrib is linked dynamically, but I don't know
about other binaries...
From my understanding of GPL, if it is linked dynamically, we are exempt
since it does not constitute a 'derived package'.
-alex
Bruce Momjian wrote:
Bruce Momjian wrote:
Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.Obviously, we could remove readline hooks and ship a BSD line editing
library, but does this make any sense to you? It doesn't make sense to
me, but he was quite certain.Our ODBC library is also GNU licensed, but I am told this is not a
problem because it doesn't link into the backend. However, neither does
readline. However, readline does link into psql.Readline is LGPL is it not? If you are merely linking to a shared
library assumed to be on the system, and do not actually incorporate
readline code within psql, you should be fine.According to him, it is GPL, not LGPL, and looking at the COPYING file
in readline, it seems he is correct.
Wow, I never noticed that, I always assumed it was LGPL.
Anyway, it makes no difference.
Under Terms and conditions:
(1) Postgres does not distribute readline as part of the source, the
user must obtain it themselves.
(2) Postgres does not alter or include the readline library does it? If
so, you would have to share your changes. There is an important
paragraph:
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
(3) Postgres already distributes source, although it does not appear
that is required. pgsql inc's desire to have a two year closed source,
they would have to make sure they made available any changes they make
to GNU source.
(4) Again Postgres does not distribute readline, so no problem.
(5) The postgres team neither modifies or distributes the readline code.
(section 5)
The rest Do not seem to apply.
Import Notes
Reference msg id not found: 200012231505.KAA17538@candle.pha.pa.us | Resolved by subject fallback
* Bruce Momjian <pgman@candle.pha.pa.us> [001223 06:59] wrote:
Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.Obviously, we could remove readline hooks and ship a BSD line editing
library, but does this make any sense to you? It doesn't make sense to
me, but he was quite certain.Our ODBC library is also GNU licensed, but I am told this is not a
problem because it doesn't link into the backend. However, neither does
readline. However, readline does link into psql.
FreeBSD has a freely available library called 'libedit' that could
be shipped with postgresql, it's under the BSD license.
If you have access to a FreeBSD box see the editline(3) manpage,
or go to:
http://www.freebsd.org/cgi/man.cgi?query=editline&apropos=0&sektion=0&manpath=FreeBSD+4.2-RELEASE&format=html
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
FreeBSD has a freely available library called 'libedit' that could
be shipped with postgresql, it's under the BSD license.
Yes, that is our solution if we have a real problem here.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian wrote:
Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.Obviously, we could remove readline hooks and ship a BSD line editing
library, but does this make any sense to you? It doesn't make sense to
me, but he was quite certain.
The sole psql program could be GNU-licenced...
just my 2p.
Fabrice
Bruce Momjian <pgman@candle.pha.pa.us> writes:
OK, but does shipping our code with hooks obligate us?
It does not; if RMS thinks it does, he's full of it.
If push actually comes to shove, I'd simply remove the readline hooks,
but the entire issue is nonsense.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
OK, but does shipping our code with hooks obligate us?
It does not; if RMS thinks it does, he's full of it.
If push actually comes to shove, I'd simply remove the readline hooks,
but the entire issue is nonsense.
That is my opinion too.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Sat, Dec 23, 2000 at 08:42:43AM -0800, Alfred Perlstein wrote:
FreeBSD has a freely available library called 'libedit' that could
be shipped with postgresql, it's under the BSD license.If you have access to a FreeBSD box see the editline(3) manpage,
or go to:
http://www.freebsd.org/cgi/man.cgi?query=editline&apropos=0&sektion=0&manpath=FreeBSD+4.2-RELEASE&format=html
Good plan - AFAIK there isn't anything gnu readline can do that libedit can't..
Patrick
(3) Postgres already distributes source, although it does not appear
that is required. pgsql inc's desire to have a two year closed source,
they would have to make sure they made available any changes they make
to GNU source.
This is a misinterpretation of our intent. As we've said repeatedly in
the past, any restricted distribution of our products would apply to
*layered* products and to other items not considered part of the
PostgreSQL core, and for a period of time allowing cost recovery. No
hard two year limit, and no restricted distro on anything one might
reasonably feel entitled to receiving gratis.
Sorry for any confusion.
- Thomas
Import Notes
Reference msg id not found: 200012231505.KAA17538@candle.pha.pa.us
Thomas Lockhart wrote:
(3) Postgres already distributes source, although it does not appear
that is required. pgsql inc's desire to have a two year closed source,
they would have to make sure they made available any changes they make
to GNU source.This is a misinterpretation of our intent. As we've said repeatedly in
the past, any restricted distribution of our products would apply to
*layered* products and to other items not considered part of the
PostgreSQL core, and for a period of time allowing cost recovery. No
hard two year limit, and no restricted distro on anything one might
reasonably feel entitled to receiving gratis.Sorry for any confusion.
There was no confusion. I understand what pgsql inc. wants to do and I
have no problem with it, in principle. My only concern was, and I think
it was done to death and clarified, was the implication that some core
Postgres code would be released in this way. It was a miscommunication,
a regrettable one. It has been made abundantly clear that this will not
be the case.
I made mention of pgsql in my earlier post because I understood that
they wanted to make add-on projects for Postgres, which were not
immediately open source, and the GPL license may present some
ramifications. In particular, one paragraph seemed to imply that simply
using one or more GPL packages, without modification, did not force an
entire project to require a GPL license.
Import Notes
Reference msg id not found: 200012231505.KAA17538@candle.pha.pa.us
On Sat, 23 Dec 2000, Bruce Momjian wrote:
FreeBSD has a freely available library called 'libedit' that could
be shipped with postgresql, it's under the BSD license.Yes, that is our solution if we have a real problem here.
Is there a reason *not* to move towards that for v7.2 so that the
functions we are making optional with readline are automatic? Since we
could then ship the code, we could make it a standard vs optional
"feature" ...
My thought would be to put 'make history feaure standard using libedit'
onto the TODO list and take it from there ...
* The Hermit Hacker <scrappy@hub.org> [001229 14:11] wrote:
On Sat, 23 Dec 2000, Bruce Momjian wrote:
FreeBSD has a freely available library called 'libedit' that could
be shipped with postgresql, it's under the BSD license.Yes, that is our solution if we have a real problem here.
Is there a reason *not* to move towards that for v7.2 so that the
functions we are making optional with readline are automatic? Since we
could then ship the code, we could make it a standard vs optional
"feature" ...My thought would be to put 'make history feaure standard using libedit'
onto the TODO list and take it from there ...
I doubt I'd have the time to do it, but if you guys want to use
libedit it'd probably be a good idea at least to reduce the amount
of potential GPL tainting in the source code.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
On Fri, 29 Dec 2000, The Hermit Hacker wrote:
On Sat, 23 Dec 2000, Bruce Momjian wrote:
FreeBSD has a freely available library called 'libedit' that could
be shipped with postgresql, it's under the BSD license.Yes, that is our solution if we have a real problem here.
Is there a reason *not* to move towards that for v7.2 so that the
functions we are making optional with readline are automatic? Since we
could then ship the code, we could make it a standard vs optional
"feature" ...
Also, it might be beneficial to _not_ link postmaster/postgres against
libreadline - I don't see where either of those programs need it - sure,
psql, but the backends? ...
morannon:~>ldd `which postgres`
libz.so.1 => /usr/lib/libz.so.1 (0x40019000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40028000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40055000)
libdl.so.2 => /lib/libdl.so.2 (0x4006c000)
libm.so.6 => /lib/libm.so.6 (0x40070000)
libreadline.so.3 => /lib/libreadline.so.3 (0x4008d000)
libtermcap.so.2 => /usr/lib/libtermcap.so.2 (0x400b5000)
libncurses.so.4 => /lib/libncurses.so.4 (0x400b9000)
libc.so.6 => /lib/libc.so.6 (0x400ff000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
morannon:~>ldd `which psql`
libpq.so.2.1 => /usr/lib/libpq.so.2.1 (0x40019000)
libz.so.1 => /usr/lib/libz.so.1 (0x40028000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40037000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40064000)
libdl.so.2 => /lib/libdl.so.2 (0x4007b000)
libm.so.6 => /lib/libm.so.6 (0x4007f000)
libreadline.so.3 => /lib/libreadline.so.3 (0x4009d000)
libtermcap.so.2 => /usr/lib/libtermcap.so.2 (0x400c4000)
libncurses.so.4 => /lib/libncurses.so.4 (0x400c8000)
libc.so.6 => /lib/libc.so.6 (0x4010e000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
postgres/postmaster very likely don't need either libreadline, nor
libncurses... Unless there's something I'm missing.
--
Dominic J. Eidson
"Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/
On Fri, 29 Dec 2000, Alfred Perlstein wrote:
* The Hermit Hacker <scrappy@hub.org> [001229 14:11] wrote:
On Sat, 23 Dec 2000, Bruce Momjian wrote:
FreeBSD has a freely available library called 'libedit' that could
be shipped with postgresql, it's under the BSD license.Yes, that is our solution if we have a real problem here.
Is there a reason *not* to move towards that for v7.2 so that the
functions we are making optional with readline are automatic? Since we
could then ship the code, we could make it a standard vs optional
"feature" ...My thought would be to put 'make history feaure standard using libedit'
onto the TODO list and take it from there ...I doubt I'd have the time to do it, but if you guys want to use
libedit it'd probably be a good idea at least to reduce the amount
of potential GPL tainting in the source code.
I'm all for trying to take it on ... Bruce, put me down for it ...
Alfred Perlstein wrote:
* The Hermit Hacker <scrappy@hub.org> [001229 14:11] wrote:
On Sat, 23 Dec 2000, Bruce Momjian wrote:
FreeBSD has a freely available library called 'libedit' that could
be shipped with postgresql, it's under the BSD license.Yes, that is our solution if we have a real problem here.
Is there a reason *not* to move towards that for v7.2 so that the
functions we are making optional with readline are automatic? Since we
could then ship the code, we could make it a standard vs optional
"feature" ...My thought would be to put 'make history feaure standard using libedit'
onto the TODO list and take it from there ...I doubt I'd have the time to do it, but if you guys want to use
libedit it'd probably be a good idea at least to reduce the amount
of potential GPL tainting in the source code.
How different is the feature set? Otherwise, sounds like a great idea
to me, and reduces the dependencies substantially -- and makes history
available to all the supported platforms without requiring libreadline
already installed.
Consider that a 'vote' of 'aye'.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
How different is the feature set?
I was going to ask the same thing. If it's an exact replacement then
OK, but I do not want to put up with non-Emacs-compatible keybindings,
to mention just one likely issue.
The whole thing really strikes me as make-work anyway. Linux is GPL'd;
does anyone want to argue that we shouldn't run on Linux? Since we
are not including libreadline in our distribution, there is NO reason
to worry about using it when it's available. Wanting to find a
replacement purely because of the license amounts to license bigotry,
IMHO.
regards, tom lane
On Fri, 29 Dec 2000, Tom Lane wrote:
Lamar Owen <lamar.owen@wgcr.org> writes:
How different is the feature set?
I was going to ask the same thing. If it's an exact replacement then
OK, but I do not want to put up with non-Emacs-compatible keybindings,
to mention just one likely issue.The whole thing really strikes me as make-work anyway. Linux is GPL'd;
does anyone want to argue that we shouldn't run on Linux? Since we
are not including libreadline in our distribution, there is NO reason
to worry about using it when it's available. Wanting to find a
replacement purely because of the license amounts to license bigotry,
IMHO.
Actually, IMHO, the pro to moving to libedit is that we could include it
as part of the distribution and make history a *standard* feature
... licensing started the thread, but I think its gone beyond that were we
have a way of providing an feature that is currently option as part of the
system as a whole ...
"one less package that you need to install" ...
* Tom Lane <tgl@sss.pgh.pa.us> [001229 15:43] wrote:
Lamar Owen <lamar.owen@wgcr.org> writes:
How different is the feature set?
I was going to ask the same thing. If it's an exact replacement then
OK, but I do not want to put up with non-Emacs-compatible keybindings,
to mention just one likely issue.The whole thing really strikes me as make-work anyway. Linux is GPL'd;
does anyone want to argue that we shouldn't run on Linux? Since we
are not including libreadline in our distribution, there is NO reason
to worry about using it when it's available. Wanting to find a
replacement purely because of the license amounts to license bigotry,
IMHO.
Rasmus Lerdorf warned one of you guys that simply linking to GNU
readline can contaminate code with the GPL.
Readline isn't LGPL which permits linking without lincense issues,
it is GPL which means that if you link to it, you must be GPL as
well.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
The Hermit Hacker writes:
Is there a reason *not* to move towards that for v7.2 so that the
functions we are making optional with readline are automatic? Since we
could then ship the code, we could make it a standard vs optional
"feature" ...My thought would be to put 'make history feaure standard using libedit'
onto the TODO list and take it from there ...
In my mind this is a pointless waste of developer time because there is no
problem to solve here. I'm sure we all have better things to do than
porting libedit to a dozen systems and then explaining to users why the
tarball is bloated and their carefully composed readline configuration
doesn't work anymore.
If there is something functionally wrong with Readline then let's talk
about it, but let's not replace it with something because some PHP dude
said that RMS said something.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
* Peter Eisentraut <peter_e@gmx.net> [001229 16:01] wrote:
The Hermit Hacker writes:
Is there a reason *not* to move towards that for v7.2 so that the
functions we are making optional with readline are automatic? Since we
could then ship the code, we could make it a standard vs optional
"feature" ...My thought would be to put 'make history feaure standard using libedit'
onto the TODO list and take it from there ...In my mind this is a pointless waste of developer time because there is no
problem to solve here. I'm sure we all have better things to do than
porting libedit to a dozen systems and then explaining to users why the
tarball is bloated and their carefully composed readline configuration
doesn't work anymore.If there is something functionally wrong with Readline then let's talk
about it, but let's not replace it with something because some PHP dude
said that RMS said something.
This General Public License does not permit incorporating your
program into proprietary programs. If your program is a subroutine
library, you may consider it more useful to permit linking
proprietary applications with the library. If this is what you
want to do, use the GNU Library General Public License instead
of this License.
My understanding (from the recent discussion) is that Postgresql
has certain dependancies on libreadline and won't compile/work
without it, if true this effectively forces anyone wishing to derive
a viable commercial product based on Postgresql to switch to the
GPL or port to libedit anyway.
If readline is completely optional then there's really no problem.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
Alfred Perlstein <bright@wintelcom.net> writes:
Rasmus Lerdorf warned one of you guys that simply linking to GNU
readline can contaminate code with the GPL.
Readline isn't LGPL which permits linking without lincense issues,
it is GPL which means that if you link to it, you must be GPL as
well.
I do not believe that. In fact, I'll go further and say "Horsepucky!"
The GPL applies to works that "contain or are derived from" a GPL'd
program. Linking to a separately distributed library does not cause
psql either to contain or to be derived from libreadline.
If we distributed binary executables that contained statically linked
copies of libreadline, then indeed we'd have a problem. We do not,
AFAIK, and we have no intention of doing so in the future.
regards, tom lane
The Hermit Hacker <scrappy@hub.org> writes:
Actually, IMHO, the pro to moving to libedit is that we could include it
as part of the distribution and make history a *standard* feature
How big is libedit? If it's tiny, that might be a good argument ...
but I don't want to see us bulking up our distro with something that
people could and should get directly from its source.
regards, tom lane
thelab# du -sk libedit
402 libedit
thelab# ls
Makefile el.h map.c refresh.h tokenizer.c
TEST emacs.c map.h search.c tokenizer.h
chared.c hist.c parse.c search.h tty.c
chared.h hist.h parse.h sig.c tty.h
common.c history.c prompt.c sig.h vi.c
editline.3 key.c prompt.h sys.h
editrc.5 key.h read.c term.c
el.c makelist refresh.c term.h
its tiny ...
we'd be adding a whole 79k to the 6meg distribution:
ls -lt /tmp/libedit.tar.gz
-rw-r--r-- 1 scrappy wheel 79025 Dec 29 20:38 /tmp/libedit.tar.gz
and providing all the functionality that ppl who don't have libreadline
already installed don't get ...
On Fri, 29 Dec 2000, Tom Lane wrote:
The Hermit Hacker <scrappy@hub.org> writes:
Actually, IMHO, the pro to moving to libedit is that we could include it
as part of the distribution and make history a *standard* featureHow big is libedit? If it's tiny, that might be a good argument ...
but I don't want to see us bulking up our distro with something that
people could and should get directly from its source.regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
* Tom Lane <tgl@sss.pgh.pa.us> [001229 16:38] wrote:
The Hermit Hacker <scrappy@hub.org> writes:
Actually, IMHO, the pro to moving to libedit is that we could include it
as part of the distribution and make history a *standard* featureHow big is libedit? If it's tiny, that might be a good argument ...
but I don't want to see us bulking up our distro with something that
people could and should get directly from its source.
~350k
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
Alfred Perlstein <bright@wintelcom.net> writes:
My understanding (from the recent discussion) is that Postgresql
has certain dependancies on libreadline and won't compile/work
without it,
Then you're working from a misconception.
regards, tom lane
On Fri, 29 Dec 2000, Tom Lane wrote:
Alfred Perlstein <bright@wintelcom.net> writes:
My understanding (from the recent discussion) is that Postgresql
has certain dependancies on libreadline and won't compile/work
without it,Then you're working from a misconception.
I think the misconception that he might be working on here is the point
someone brought up that when configure runs, it is adding -lreadline to
the backend compile, even though that I don't think there is any reason
for doing such?
* The Hermit Hacker <scrappy@hub.org> [001229 17:06] wrote:
On Fri, 29 Dec 2000, Tom Lane wrote:
Alfred Perlstein <bright@wintelcom.net> writes:
My understanding (from the recent discussion) is that Postgresql
has certain dependancies on libreadline and won't compile/work
without it,Then you're working from a misconception.
I think the misconception that he might be working on here is the point
someone brought up that when configure runs, it is adding -lreadline to
the backend compile, even though that I don't think there is any reason
for doing such?
I thought psql required libreadline, I'm not sure who said it.
If nothing requires it then there's not much point in moving to
libedit from a devel cost/benifit analysis.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
The Hermit Hacker <scrappy@hub.org> writes:
someone brought up that when configure runs, it is adding -lreadline to
the backend compile, even though that I don't think there is any reason
for doing such?
There isn't --- configure is just sloppy in that it supplies the same
library list for all programs we build. (This might be a fair amount
of work to change; never looked at it.)
However, I don't see what that has to do with the licensing argument.
We stand or fall on psql's use of libreadline, and having useless
dependencies from other executables doesn't alter anything that I can
see.
regards, tom lane
The Hermit Hacker writes:
Actually, IMHO, the pro to moving to libedit is that we could include it
as part of the distribution and make history a *standard* feature
History already is a standard feature, you just need to have readline
installed. In a world of source code users need to cope with package
dependencies, and it's not like readline is the most esoteric package in
the world. Gradually adding operating system level things into a package
purely to convenience some users is a way to piss of the users at large
because you're overriding their operating system setup.
If libedit could be used as an alternative to readline depending on your
operating system setup then there's nothing wrong with that. NetBSD
already went the other way around and made libedit compatible with
readline.
But given that readline availability during the last five years was
apparently just fine I don't understand this discussion at all.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Fri, Dec 29, 2000 at 07:15:05PM -0500, Tom Lane wrote:
Alfred Perlstein <bright@wintelcom.net> writes:
Rasmus Lerdorf warned one of you guys that simply linking to GNU
readline can contaminate code with the GPL.Readline isn't LGPL which permits linking without lincense issues,
it is GPL which means that if you link to it, you must be GPL as
well.I do not believe that. In fact, I'll go further and say "Horsepucky!"
The GPL applies to works that "contain or are derived from" a GPL'd
program. Linking to a separately distributed library does not cause
psql either to contain or to be derived from libreadline.
RMS already made a big stink about this, claiming that BeOS's use
of an emulation layer to link to some GPL'ed network drivers was enough
to force the GPL'ing of the kernel. Be backed down (and re-licensed
the code from the source, IIRC). Sun recently released a "driver
porting kit" that allowed similar drivers to be used in Solaris. There
was some outcry on Slashdot, but I'm not sure how it ended up.
I wouldn't mind having someone tell RMS to fuck off, though.
--
Adam Haberlach |A cat spends her life conflicted between a
adam@newsnipple.com |deep, passionate, and profound desire for
http://www.newsnipple.com |fish and an equally deep, passionate, and
'88 EX500 |profound desire to avoid getting wet.
On Fri, 29 Dec 2000, Alfred Perlstein wrote:
* The Hermit Hacker <scrappy@hub.org> [001229 17:06] wrote:
On Fri, 29 Dec 2000, Tom Lane wrote:
Alfred Perlstein <bright@wintelcom.net> writes:
My understanding (from the recent discussion) is that Postgresql
has certain dependancies on libreadline and won't compile/work
without it,Then you're working from a misconception.
I think the misconception that he might be working on here is the point
someone brought up that when configure runs, it is adding -lreadline to
the backend compile, even though that I don't think there is any reason
for doing such?I thought psql required libreadline, I'm not sure who said it.
Purely optional feature(s) .. if readline isn't found, they aren't enabled
...
On Sat, 30 Dec 2000, Peter Eisentraut wrote:
The Hermit Hacker writes:
Actually, IMHO, the pro to moving to libedit is that we could include it
as part of the distribution and make history a *standard* featureHistory already is a standard feature, you just need to have readline
installed.
So, history is optional depending on whether or not readline is installed
... if it was standard, it would be enabled regardless of any other
dependencies ...
Peter Eisentraut <peter_e@gmx.net> writes:
But given that readline availability during the last five years was
apparently just fine I don't understand this discussion at all.
Indeed. You could make a better case that we shouldn't be including
in our distro the ODBC driver (LGPL) or the several contrib modules
that are GPL'd than that psql's optional use of libreadline means
we are in violation of GPL.
I'm okay with including those things because of the GPL's "mere
aggregation" exception --- none of the rest of the system uses any
of those modules, so our inclusion of them in the distro looks like
mere aggregation to me. But it's a much closer judgment call than
the readline situation.
regards, tom lane
Adam Haberlach <adam@newsnipple.com> writes:
RMS already made a big stink about this, claiming that BeOS's use
of an emulation layer to link to some GPL'ed network drivers was enough
to force the GPL'ing of the kernel.
Did BeOS make distributions that included the GPL'd code?
Was the GPL'd code essential for useful use of their system?
We can answer "no" to both of those points for Postgres vs. readline,
so the Be case doesn't look like precedent to me.
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
If libedit could be used as an alternative to readline depending on your
operating system setup then there's nothing wrong with that.
I have no objection to being able to work with either one, if someone's
excited about making that happen. I'd still think it a waste of effort,
but as long as it's not my effort I can hardly complain...
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
If there is something functionally wrong with Readline then let's talk
about it, but let's not replace it with something because some PHP dude
said that RMS said something.
ncftp used to be for non-commercial use only and had hooks to be
linked against readline. RMS threatened legal action, which caused
the developer to change the license to GPL, which was what RMS wanted.
So, whatever your opinion of his reasoning and motives, etc., it is
undoubtedly RMS's intention to use readline as a point of leverage to
get projects to go GPL.
Personally, I agree with him. Many don't.
Mike.
Import Notes
Reply to msg id not found: PeterEisentrautsmessageofSat30Dec2000010818+0100CET
On Fri, Dec 29, 2000 at 08:46:40PM -0500, Tom Lane wrote:
Adam Haberlach <adam@newsnipple.com> writes:
RMS already made a big stink about this, claiming that BeOS's use
of an emulation layer to link to some GPL'ed network drivers was enough
to force the GPL'ing of the kernel.Did BeOS make distributions that included the GPL'd code?
Yes. IIRC (this happened about the time I got here more then two years
ago), Be released binary versions of the drivers with the standard
distribution as well as source to them as sample code. RMS's main claim
was that although the GPL'ed source was released as source, it had to
link to the kernel to be useful, and therefore could not be distributed
without source to the kernel.
Was the GPL'd code essential for useful use of their system?
No.
--
Adam Haberlach |A cat spends her life conflicted between a
adam@newsnipple.com |deep, passionate, and profound desire for
http://www.newsnipple.com |fish and an equally deep, passionate, and
'88 EX500 |profound desire to avoid getting wet.
But given that readline availability during the last five years was
apparently just fine I don't understand this discussion at all.
I agree with Peter and others on this topic, though the occasional
discussion helps to clarify things...
- Thomas
On 29 Dec 2000, Michael Alan Dorman wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
If there is something functionally wrong with Readline then let's talk
about it, but let's not replace it with something because some PHP dude
said that RMS said something.ncftp used to be for non-commercial use only and had hooks to be
linked against readline. RMS threatened legal action, which caused
the developer to change the license to GPL, which was what RMS wanted.
Problem with ncftp was developers distributing binaries commercially which
were linked to libreadline.
As I said before, postgres doesn't have this problem since neither RPMs
nor other binaries do that.
Adam Haberlach wrote:
On Fri, Dec 29, 2000 at 08:46:40PM -0500, Tom Lane wrote:
Adam Haberlach <adam@newsnipple.com> writes:
RMS already made a big stink about this, claiming that BeOS's use
of an emulation layer to link to some GPL'ed network drivers was enough
to force the GPL'ing of the kernel.Did BeOS make distributions that included the GPL'd code?
Yes. IIRC (this happened about the time I got here more then two years
ago), Be released binary versions of the drivers with the standard
distribution as well as source to them as sample code. RMS's main claim
was that although the GPL'ed source was released as source, it had to
link to the kernel to be useful, and therefore could not be distributed
without source to the kernel.Was the GPL'd code essential for useful use of their system?
No.
I can't believe this thread continues. No portion of Postgres is derived
from readline, and no modifications are made to readline. "readline" is
not distributed with the source. If you read the COPYING supplied with
readline, look at the last paragraph of section 2 under "Terms and
Conditions"
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
I think it can safely be said that there is no readline issue.
Lamar Owen <lamar.owen@wgcr.org> writes:
How different is the feature set? Otherwise, sounds like a great idea
to me, and reduces the dependencies substantially -- and makes history
available to all the supported platforms without requiring libreadline
already installed.
It bloats on platforms having readline but not libedit.
As long as it isn't necesarry for postgresql to function, I don't see
any risk of tainting.
--
Trond Eivind Glomsr�d
Red Hat, Inc.
On Sat, Dec 30, 2000 at 02:34:24AM +0100, Peter Eisentraut wrote:
If libedit could be used as an alternative to readline depending on your
operating system setup then there's nothing wrong with that. NetBSD
already went the other way around and made libedit compatible with
readline.
I had an attempt at fooling configure to look in libedit rather than
readline, and all was OK except our libedit doesn't have "rl_special_prefixes"
so tab-complete:105 is unhappy - I don't know what it is meant to do...
Re licence business, one could argue hooks are there to use NetBSD libedit ;)
Cheers,
Patrick
At 7:15 PM -0500 12/29/00, Tom Lane wrote:
Alfred Perlstein <bright@wintelcom.net> writes:
Rasmus Lerdorf warned one of you guys that simply linking to GNU
readline can contaminate code with the GPL.Readline isn't LGPL which permits linking without lincense issues,
it is GPL which means that if you link to it, you must be GPL as
well.I do not believe that. In fact, I'll go further and say "Horsepucky!"
The GPL applies to works that "contain or are derived from" a GPL'd
program. Linking to a separately distributed library does not cause
psql either to contain or to be derived from libreadline.
Some very highly paid lawyers disagree with you.
That doesn't make them right, but keep in mind that no one has defined "derivitive work" in a court of law. And RMS isn't a lawyer.
I agree readline doesn't taint PG, but IMHO, the more distance between the GPL and PG, the better.
-pmb
--
"Every time you provide an option, you're asking the user to make a decision.
That means they will have to think about something and decide about it.
It's not necessarily a bad thing, but, in general, you should always try to
minimize the number of decisions that people have to make."
http://joel.editthispage.com/stories/storyReader$51
On Sat, 30 Dec 2000, Peter Bierman wrote:
At 7:15 PM -0500 12/29/00, Tom Lane wrote:
Alfred Perlstein <bright@wintelcom.net> writes:
Rasmus Lerdorf warned one of you guys that simply linking to GNU
readline can contaminate code with the GPL.Readline isn't LGPL which permits linking without lincense issues,
it is GPL which means that if you link to it, you must be GPL as
well.I do not believe that. In fact, I'll go further and say "Horsepucky!"
The GPL applies to works that "contain or are derived from" a GPL'd
program. Linking to a separately distributed library does not cause
psql either to contain or to be derived from libreadline.Some very highly paid lawyers disagree with you.
That doesn't make them right, but keep in mind that no one has defined "derivitive work" in a court of law. And RMS isn't a lawyer.
I agree readline doesn't taint PG, but IMHO, the more distance between the GPL and PG, the better.
OK. For the last time, here's the story about linking, as agreed upon by
almost damn everyone:
a) dynamic linking is kosher, as of GPL2
b) static linking is OK, but you may NOT redistribute resulting libraries.
I hope the above will put the discussion about readline to an end, as
Postgres does not distribute statically linked binaries.
-alex
Patrick Welche writes:
I had an attempt at fooling configure to look in libedit rather than
readline, and all was OK except our libedit doesn't have "rl_special_prefixes"
so tab-complete:105 is unhappy - I don't know what it is meant to do...
I've removed the statement for now, since it was being used incorrectly
anyway, but for the future I suggest that NetBSD catch up, if it wants to
stay compatible.
- Variable: char * rl_special_prefixes
The list of characters that are word break characters, but should
be left in TEXT when it is passed to the completion function.
Programs can use this to help determine what kind of completing to
do. For instance, Bash sets this variable to "$@" so that it can
complete shell variables and hostnames.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Sun, Dec 31, 2000 at 01:06:40PM +0100, Peter Eisentraut wrote:
I've removed the statement for now, since it was being used incorrectly
anyway, but for the future I suggest that NetBSD catch up, if it wants to
stay compatible.
Thank you, and Jaromir tells me he'll commit a fix to NetBSD within days!
Happy New Year,
Patrick
I do not believe that. In fact, I'll go further and say "Horsepucky!"
The GPL applies to works that "contain or are derived from" a GPL'd
program. Linking to a separately distributed library does not cause
psql either to contain or to be derived from libreadline.Some very highly paid lawyers disagree with you.
That doesn't make them right, but keep in mind that no one has defined "derivitive work" in a court of law. And RMS isn't a lawyer.
I agree readline doesn't taint PG, but IMHO, the more distance between the GPL and PG, the better.
OK. For the last time, here's the story about linking, as agreed upon by
almost damn everyone:a) dynamic linking is kosher, as of GPL2
b) static linking is OK, but you may NOT redistribute resulting libraries.I hope the above will put the discussion about readline to an end, as
Postgres does not distribute statically linked binaries.
I read through this large thread, and it is good to see that readline
is not an issue for us. Only binary distributions that statically link
in libreadline are a problem.
If people feel that this is a significant restriction, we can start
distributing libedit, or the binary packager can link libedit into their
binary.
I hesitate to add the libedit code to our already large distribution,
and I think several others agreed.
I am concerned about RMS's heavy-handed agenda in regards to the GPL,
but it appears he is not irrational in his requirements.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Patrick Welche writes:
On Sun, Dec 31, 2000 at 01:06:40PM +0100, Peter Eisentraut wrote:
I've removed the statement for now, since it was being used incorrectly
anyway, but for the future I suggest that NetBSD catch up, if it wants to
stay compatible.Thank you, and Jaromir tells me he'll commit a fix to NetBSD within days!
Btw., what would be involved in using NetBSD's libedit transparently for
PostgreSQL? In particular these questions arise:
* What library name to look for
* What header files to look for
* Is history automatically included with line editing?
* How to avoid using an old or non-NetBSD libedit
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Sat, Dec 30, 2000 at 02:34:24AM +0100, Peter Eisentraut wrote:
If libedit could be used as an alternative to readline depending on your
operating system setup then there's nothing wrong with that. NetBSD
already went the other way around and made libedit compatible with
readline.I had an attempt at fooling configure to look in libedit rather than
readline, and all was OK except our libedit doesn't have "rl_special_prefixes"
so tab-complete:105 is unhappy - I don't know what it is meant to do...Re licence business, one could argue hooks are there to use NetBSD libedit ;)
Agreed. It would be nice to have configure look for libedit or
libreadline, and use either automatically.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Added to TODO:
* Allow libedit to be used in place of libreadline
On Sun, Dec 31, 2000 at 01:06:40PM +0100, Peter Eisentraut wrote:
I've removed the statement for now, since it was being used incorrectly
anyway, but for the future I suggest that NetBSD catch up, if it wants to
stay compatible.Thank you, and Jaromir tells me he'll commit a fix to NetBSD within days!
Happy New Year,
Patrick
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026