GNU readline and BSD license
Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.
Obviously, we could remove readline hooks and ship a BSD line editing
library, but does this make any sense to you? It doesn't make sense to
me, but he was quite certain.
Our ODBC library is also GNU licensed, but I am told this is not a
problem because it doesn't link into the backend. However, neither does
readline. However, readline does link into psql.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Bruce Momjian writes:
Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.This sort of thing is complete nonsense.
By the same logic you could argue that the system("cp template1 ...")
calls could force us to a GNU license, because 'cp' is from GNU fileutils.
Well, his issue was that 'cp' is not in the binary, while readline
_could_ be in the binary. My issue is that we only optionally link
in the library. We don't actually ship the library with our code.
Honestly, it made no sense to me either, and if it hadn't been Rasmus, I
would have written it off immediately.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Import Notes
Reply to msg id not found: Pine.LNX.4.30.0012231638530.1068-100000@peter.localdomain | Resolved by subject fallback
Bruce Momjian writes:
Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.
This sort of thing is complete nonsense.
By the same logic you could argue that the system("cp template1 ...")
calls could force us to a GNU license, because 'cp' is from GNU fileutils.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Sat, 23 Dec 2000, Bruce Momjian wrote:
Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.Obviously, we could remove readline hooks and ship a BSD line editing
library, but does this make any sense to you? It doesn't make sense to
me, but he was quite certain.
Unfortunately he's right, since GPL software is incompatible with any
non-GPL software. Stallman publically admitted that he intentionally
released readline under GPL, not LGPL, to force more people into GPLing
their code.
On Sat, 23 Dec 2000, Bruce Momjian wrote:
Rasmus Lerdorf, the big PHP developer, told me that the existence of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.Obviously, we could remove readline hooks and ship a BSD line editing
library, but does this make any sense to you? It doesn't make sense to
me, but he was quite certain.
Unfortunately he's right, since GPL software is incompatible with any
non-GPL software. Stallman publicly admitted that he intentionally
released readline under GPL, not LGPL, to force more people into GPLing
their code.
OK, but does shipping our code with hooks obligate us? We don't ship
readline.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026On Sat, 23 Dec 2000, Bruce Momjian wrote:
OK, but does shipping our code with hooks obligate us? We don't ship
readline.
Oh, oops. I didn't know readline wasn't in the postgres tree. Then,
obviously, distribution of .tar.gz does not obligate postgres to anything,
HOWEVER, the problem arises with distribution of binaries (.rpm and
others) which are linked against libreadline _statically_ (basically, we
can't do it). Our RPM distrib is linked dynamically, but I don't know
about other binaries...
From my understanding of GPL, if it is linked dynamically, we are exempt
since it does not constitute a 'derived package'.
-alex
Bruce Momjian wrote:
Bruce Momjian wrote:
Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.Obviously, we could remove readline hooks and ship a BSD line editing
library, but does this make any sense to you? It doesn't make sense to
me, but he was quite certain.Our ODBC library is also GNU licensed, but I am told this is not a
problem because it doesn't link into the backend. However, neither does
readline. However, readline does link into psql.Readline is LGPL is it not? If you are merely linking to a shared
library assumed to be on the system, and do not actually incorporate
readline code within psql, you should be fine.According to him, it is GPL, not LGPL, and looking at the COPYING file
in readline, it seems he is correct.
Wow, I never noticed that, I always assumed it was LGPL.
Anyway, it makes no difference.
Under Terms and conditions:
(1) Postgres does not distribute readline as part of the source, the
user must obtain it themselves.
(2) Postgres does not alter or include the readline library does it? If
so, you would have to share your changes. There is an important
paragraph:
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
(3) Postgres already distributes source, although it does not appear
that is required. pgsql inc's desire to have a two year closed source,
they would have to make sure they made available any changes they make
to GNU source.
(4) Again Postgres does not distribute readline, so no problem.
(5) The postgres team neither modifies or distributes the readline code.
(section 5)
The rest Do not seem to apply.
Import Notes
Reference msg id not found: 200012231505.KAA17538@candle.pha.pa.us | Resolved by subject fallback
* Bruce Momjian <pgman@candle.pha.pa.us> [001223 06:59] wrote:
Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.Obviously, we could remove readline hooks and ship a BSD line editing
library, but does this make any sense to you? It doesn't make sense to
me, but he was quite certain.Our ODBC library is also GNU licensed, but I am told this is not a
problem because it doesn't link into the backend. However, neither does
readline. However, readline does link into psql.
FreeBSD has a freely available library called 'libedit' that could
be shipped with postgresql, it's under the BSD license.
If you have access to a FreeBSD box see the editline(3) manpage,
or go to:
http://www.freebsd.org/cgi/man.cgi?query=editline&apropos=0&sektion=0&manpath=FreeBSD+4.2-RELEASE&format=html
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
FreeBSD has a freely available library called 'libedit' that could
be shipped with postgresql, it's under the BSD license.
Yes, that is our solution if we have a real problem here.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian wrote:
Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.Obviously, we could remove readline hooks and ship a BSD line editing
library, but does this make any sense to you? It doesn't make sense to
me, but he was quite certain.
The sole psql program could be GNU-licenced...
just my 2p.
Fabrice
Bruce Momjian <pgman@candle.pha.pa.us> writes:
OK, but does shipping our code with hooks obligate us?
It does not; if RMS thinks it does, he's full of it.
If push actually comes to shove, I'd simply remove the readline hooks,
but the entire issue is nonsense.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
OK, but does shipping our code with hooks obligate us?
It does not; if RMS thinks it does, he's full of it.
If push actually comes to shove, I'd simply remove the readline hooks,
but the entire issue is nonsense.
That is my opinion too.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Sat, Dec 23, 2000 at 08:42:43AM -0800, Alfred Perlstein wrote:
FreeBSD has a freely available library called 'libedit' that could
be shipped with postgresql, it's under the BSD license.If you have access to a FreeBSD box see the editline(3) manpage,
or go to:
http://www.freebsd.org/cgi/man.cgi?query=editline&apropos=0&sektion=0&manpath=FreeBSD+4.2-RELEASE&format=html
Good plan - AFAIK there isn't anything gnu readline can do that libedit can't..
Patrick
(3) Postgres already distributes source, although it does not appear
that is required. pgsql inc's desire to have a two year closed source,
they would have to make sure they made available any changes they make
to GNU source.
This is a misinterpretation of our intent. As we've said repeatedly in
the past, any restricted distribution of our products would apply to
*layered* products and to other items not considered part of the
PostgreSQL core, and for a period of time allowing cost recovery. No
hard two year limit, and no restricted distro on anything one might
reasonably feel entitled to receiving gratis.
Sorry for any confusion.
- Thomas
Import Notes
Reference msg id not found: 200012231505.KAA17538@candle.pha.pa.us
Thomas Lockhart wrote:
(3) Postgres already distributes source, although it does not appear
that is required. pgsql inc's desire to have a two year closed source,
they would have to make sure they made available any changes they make
to GNU source.This is a misinterpretation of our intent. As we've said repeatedly in
the past, any restricted distribution of our products would apply to
*layered* products and to other items not considered part of the
PostgreSQL core, and for a period of time allowing cost recovery. No
hard two year limit, and no restricted distro on anything one might
reasonably feel entitled to receiving gratis.Sorry for any confusion.
There was no confusion. I understand what pgsql inc. wants to do and I
have no problem with it, in principle. My only concern was, and I think
it was done to death and clarified, was the implication that some core
Postgres code would be released in this way. It was a miscommunication,
a regrettable one. It has been made abundantly clear that this will not
be the case.
I made mention of pgsql in my earlier post because I understood that
they wanted to make add-on projects for Postgres, which were not
immediately open source, and the GPL license may present some
ramifications. In particular, one paragraph seemed to imply that simply
using one or more GPL packages, without modification, did not force an
entire project to require a GPL license.
Import Notes
Reference msg id not found: 200012231505.KAA17538@candle.pha.pa.us
On Sat, 23 Dec 2000, Bruce Momjian wrote:
FreeBSD has a freely available library called 'libedit' that could
be shipped with postgresql, it's under the BSD license.Yes, that is our solution if we have a real problem here.
Is there a reason *not* to move towards that for v7.2 so that the
functions we are making optional with readline are automatic? Since we
could then ship the code, we could make it a standard vs optional
"feature" ...
My thought would be to put 'make history feaure standard using libedit'
onto the TODO list and take it from there ...
* The Hermit Hacker <scrappy@hub.org> [001229 14:11] wrote:
On Sat, 23 Dec 2000, Bruce Momjian wrote:
FreeBSD has a freely available library called 'libedit' that could
be shipped with postgresql, it's under the BSD license.Yes, that is our solution if we have a real problem here.
Is there a reason *not* to move towards that for v7.2 so that the
functions we are making optional with readline are automatic? Since we
could then ship the code, we could make it a standard vs optional
"feature" ...My thought would be to put 'make history feaure standard using libedit'
onto the TODO list and take it from there ...
I doubt I'd have the time to do it, but if you guys want to use
libedit it'd probably be a good idea at least to reduce the amount
of potential GPL tainting in the source code.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
On Fri, 29 Dec 2000, The Hermit Hacker wrote:
On Sat, 23 Dec 2000, Bruce Momjian wrote:
FreeBSD has a freely available library called 'libedit' that could
be shipped with postgresql, it's under the BSD license.Yes, that is our solution if we have a real problem here.
Is there a reason *not* to move towards that for v7.2 so that the
functions we are making optional with readline are automatic? Since we
could then ship the code, we could make it a standard vs optional
"feature" ...
Also, it might be beneficial to _not_ link postmaster/postgres against
libreadline - I don't see where either of those programs need it - sure,
psql, but the backends? ...
morannon:~>ldd `which postgres`
libz.so.1 => /usr/lib/libz.so.1 (0x40019000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40028000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40055000)
libdl.so.2 => /lib/libdl.so.2 (0x4006c000)
libm.so.6 => /lib/libm.so.6 (0x40070000)
libreadline.so.3 => /lib/libreadline.so.3 (0x4008d000)
libtermcap.so.2 => /usr/lib/libtermcap.so.2 (0x400b5000)
libncurses.so.4 => /lib/libncurses.so.4 (0x400b9000)
libc.so.6 => /lib/libc.so.6 (0x400ff000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
morannon:~>ldd `which psql`
libpq.so.2.1 => /usr/lib/libpq.so.2.1 (0x40019000)
libz.so.1 => /usr/lib/libz.so.1 (0x40028000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40037000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40064000)
libdl.so.2 => /lib/libdl.so.2 (0x4007b000)
libm.so.6 => /lib/libm.so.6 (0x4007f000)
libreadline.so.3 => /lib/libreadline.so.3 (0x4009d000)
libtermcap.so.2 => /usr/lib/libtermcap.so.2 (0x400c4000)
libncurses.so.4 => /lib/libncurses.so.4 (0x400c8000)
libc.so.6 => /lib/libc.so.6 (0x4010e000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
postgres/postmaster very likely don't need either libreadline, nor
libncurses... Unless there's something I'm missing.
--
Dominic J. Eidson
"Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/
On Fri, 29 Dec 2000, Alfred Perlstein wrote:
* The Hermit Hacker <scrappy@hub.org> [001229 14:11] wrote:
On Sat, 23 Dec 2000, Bruce Momjian wrote:
FreeBSD has a freely available library called 'libedit' that could
be shipped with postgresql, it's under the BSD license.Yes, that is our solution if we have a real problem here.
Is there a reason *not* to move towards that for v7.2 so that the
functions we are making optional with readline are automatic? Since we
could then ship the code, we could make it a standard vs optional
"feature" ...My thought would be to put 'make history feaure standard using libedit'
onto the TODO list and take it from there ...I doubt I'd have the time to do it, but if you guys want to use
libedit it'd probably be a good idea at least to reduce the amount
of potential GPL tainting in the source code.
I'm all for trying to take it on ... Bruce, put me down for it ...
Alfred Perlstein wrote:
* The Hermit Hacker <scrappy@hub.org> [001229 14:11] wrote:
On Sat, 23 Dec 2000, Bruce Momjian wrote:
FreeBSD has a freely available library called 'libedit' that could
be shipped with postgresql, it's under the BSD license.Yes, that is our solution if we have a real problem here.
Is there a reason *not* to move towards that for v7.2 so that the
functions we are making optional with readline are automatic? Since we
could then ship the code, we could make it a standard vs optional
"feature" ...My thought would be to put 'make history feaure standard using libedit'
onto the TODO list and take it from there ...I doubt I'd have the time to do it, but if you guys want to use
libedit it'd probably be a good idea at least to reduce the amount
of potential GPL tainting in the source code.
How different is the feature set? Otherwise, sounds like a great idea
to me, and reduces the dependencies substantially -- and makes history
available to all the supported platforms without requiring libreadline
already installed.
Consider that a 'vote' of 'aye'.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
