Thread

  1. GNU readline and BSD license

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-12-23T14:56:07Z

    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 19026
    
    
  2. Re: GNU readline and BSD license

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-12-23T15:44:20Z

    > 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, Pennsylvania 19026
    
    
  3. Re: GNU readline and BSD license

    Peter Eisentraut <peter_e@gmx.net> — 2000-12-23T15:46:12Z

    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/
    
    
    
  4. Re: GNU readline and BSD license

    alex@pilosoft.com — 2000-12-23T15:52:23Z

    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. 
    
    
    
  5. Re: GNU readline and BSD license

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-12-23T15:54:54Z

    > 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 19026
    
    
  6. Re: GNU readline and BSD license

    alex@pilosoft.com — 2000-12-23T16:06:14Z

    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
    
    
    
  7. Re: GNU readline and BSD license

    Alfred Perlstein <bright@wintelcom.net> — 2000-12-23T16:42:43Z

    * 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."
    
    
  8. Re: GNU readline and BSD license

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-12-23T16:48:13Z

    > 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
    
    
  9. Re: GNU readline and BSD license

    Fabrice Scemama <fabrice@scemama.org> — 2000-12-23T17:09:21Z

    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
    
    
  10. Re: GNU readline and BSD license

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-12-23T17:10:38Z

    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
    
    
  11. Re: GNU readline and BSD license

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-12-23T17:14:59Z

    > 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
    
    
  12. Re: GNU readline and BSD license

    Patrick Welche <prlw1@newn.cam.ac.uk> — 2000-12-23T19:42:43Z

    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
    
    
  13. Re: GNU readline and BSD license

    Marc G. Fournier <scrappy@hub.org> — 2000-12-29T22:10:13Z

    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 ...
    
    
    
  14. Re: GNU readline and BSD license

    Alfred Perlstein <bright@wintelcom.net> — 2000-12-29T22:12:58Z

    * 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."
    
    
  15. Re: GNU readline and BSD license

    Dominic J. Eidson <sauron@the-infinite.org> — 2000-12-29T22:15:09Z

    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/
    
    
    
  16. Re: GNU readline and BSD license

    Marc G. Fournier <scrappy@hub.org> — 2000-12-29T22:17:17Z

    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 ...
    
    
    
  17. Re: GNU readline and BSD license

    Lamar Owen <lamar.owen@wgcr.org> — 2000-12-29T22:20:24Z

    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
    
    
  18. Re: GNU readline and BSD license

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-12-29T23:43:38Z

    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
    
    
  19. Re: GNU readline and BSD license

    Marc G. Fournier <scrappy@hub.org> — 2000-12-29T23:49:33Z

    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" ...
    
    
    
  20. Re: GNU readline and BSD license

    Alfred Perlstein <bright@wintelcom.net> — 2000-12-29T23:51:41Z

    * 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."
    
    
  21. Re: GNU readline and BSD license

    Peter Eisentraut <peter_e@gmx.net> — 2000-12-30T00:08:18Z

    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/
    
    
    
  22. Re: GNU readline and BSD license

    Alfred Perlstein <bright@wintelcom.net> — 2000-12-30T00:09:47Z

    * 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 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."
    
    
  23. Re: GNU readline and BSD license

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-12-30T00:15:05Z

    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
    
    
  24. Re: GNU readline and BSD license

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-12-30T00:16:49Z

    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
    
    
  25. Re: GNU readline and BSD license

    Marc G. Fournier <scrappy@hub.org> — 2000-12-30T00:39:57Z

    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
    
    
    
  26. Re: GNU readline and BSD license

    Alfred Perlstein <bright@wintelcom.net> — 2000-12-30T00:41:14Z

    * 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."
    
    
  27. Re: GNU readline and BSD license

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-12-30T01:00:25Z

    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
    
    
  28. Re: GNU readline and BSD license

    Marc G. Fournier <scrappy@hub.org> — 2000-12-30T01:04:56Z

    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?
    
    
    
    
  29. Re: GNU readline and BSD license

    Alfred Perlstein <bright@wintelcom.net> — 2000-12-30T01:09:09Z

    * 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."
    
    
  30. Re: GNU readline and BSD license

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-12-30T01:27:49Z

    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
    
    
  31. Re: GNU readline and BSD license

    Peter Eisentraut <peter_e@gmx.net> — 2000-12-30T01:34:24Z

    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/
    
    
    
  32. Re: GNU readline and BSD license

    Adam Haberlach <adam@newsnipple.com> — 2000-12-30T01:37:41Z

    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.
    
    
  33. Re: GNU readline and BSD license

    Marc G. Fournier <scrappy@hub.org> — 2000-12-30T01:39:51Z

    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
    ...
    
    
    
    
  34. Re: GNU readline and BSD license

    Marc G. Fournier <scrappy@hub.org> — 2000-12-30T01:41:18Z

    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 ...
    
    
    
    
  35. Re: GNU readline and BSD license

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-12-30T01:42:34Z

    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
    
    
  36. Re: GNU readline and BSD license

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-12-30T01:46:40Z

    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
    
    
  37. Re: GNU readline and BSD license

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-12-30T01:48:36Z

    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
    
    
  38. Re: GNU readline and BSD license

    Michael Alan Dorman <mdorman@debian.org> — 2000-12-30T01:51:03Z

    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.
    
    
  39. Re: GNU readline and BSD license

    Adam Haberlach <adam@newsnipple.com> — 2000-12-30T01:58:25Z

    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.
    
    
  40. Re: GNU readline and BSD license

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2000-12-30T02:06:01Z

    > 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
    
    
  41. Re: GNU readline and BSD license

    alex@pilosoft.com — 2000-12-30T02:26:23Z

    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.
    
    
    
  42. Re: GNU readline and BSD license

    mlw <markw@mohawksoft.com> — 2000-12-30T15:17:21Z

    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
    
    
  43. Re: GNU readline and BSD license

    Trond Eivind Glomsrød <teg@redhat.com> — 2000-12-30T20:04:28Z

    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.
    
    
  44. Re: GNU readline and BSD license

    Patrick Welche <prlw1@newn.cam.ac.uk> — 2000-12-30T21:34:16Z

    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
    
    
  45. Re: GNU readline and BSD license

    Peter Bierman <bierman@apple.com> — 2000-12-30T23:35:37Z

    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
    
    
    
    
  46. Re: GNU readline and BSD license

    alex@pilosoft.com — 2000-12-31T03:17:53Z

    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
    
    
    
  47. Re: GNU readline and BSD license

    Peter Eisentraut <peter_e@gmx.net> — 2000-12-31T12:06:40Z

    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/
    
    
    
  48. Re: GNU readline and BSD license

    Patrick Welche <prlw1@newn.cam.ac.uk> — 2000-12-31T14:18:19Z

    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
    
    
  49. Re: GNU readline and BSD license

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-01-02T03:42:58Z

    > > >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 19026
     
    
    
  50. NetBSD libedit (Re: GNU readline and BSD license)

    Peter Eisentraut <peter_e@gmx.net> — 2001-01-02T17:14:01Z

    Patrick 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/
    
    
    
  51. Re: GNU readline and BSD license

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-01-03T02:22:42Z

    > 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 19026
    
    
  52. Re: GNU readline and BSD license

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-01-03T02:24:12Z

    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, Pennsylvania 19026