Обсуждение: 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, Pennsylvania19026
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/
> 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.
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,
Pennsylvania19026
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, Pennsylvania19026
On 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: > > 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 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. -- http://www.mohawksoft.com
* 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, Pennsylvania19026
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, Pennsylvania19026
> (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
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. -- http://www.mohawksoft.com
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
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
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/
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
* 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 <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
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" ...
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* 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
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
* 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. From http://www.gnu.org/copyleft/gpl.html This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutinelibrary, you may consider it more useful to permit linking proprietary applications with the library. If this iswhat 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
* 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* 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. ~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
* 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."
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?
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.
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
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 ...
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/
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
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* feature > > History 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:
> 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
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
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 thentwo 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.
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.
> 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. -- http://www.mohawksoft.com
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.
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'ta 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 somethingand decide about it.It's not necessarily a bad thing, but, in general, you should always try tominimize the numberof 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'ta 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 inTEXT 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/
> > >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'ta 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, Pennsylvania19026
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
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
Added 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, Pennsylvania19026
> 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, Pennsylvania19026