LGPL

We already do ... libreadline ...

On Wed, 15 Jun 2005, John Hansen wrote:

Is there any reason why we would not be able to use LGPL code in PG?

... John

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

What about GPL ?
I assume that's out of the question!

Marc G. Fournier wrote:

We already do ... libreadline ...

libreadline is GPL, not LGPL.

---------------------------------------------------------------------------

On Wed, 15 Jun 2005, John Hansen wrote:

Is there any reason why we would not be able to use LGPL code in PG?

... John

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

John Hansen wrote:

What about GPL ?
I assume that's out of the question!

If we add some GPL code, the entire binary becomes GPL, and that
prevents closed-source commercial versions from being produced.

---------------------------------------------------------------------------

-----Original Message-----
From: Marc G. Fournier [mailto:scrappy@postgresql.org]
Sent: Wednesday, June 15, 2005 11:59 AM
To: John Hansen
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] LGPL

We already do ... libreadline ...

On Wed, 15 Jun 2005, John Hansen wrote:

Is there any reason why we would not be able to use LGPL code in PG?

... John

---------------------------(end of
broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org

so that your

message can get through to the mailing list cleanly

----
Marc G. Fournier Hub.Org Networking Services
(http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy
ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Er, no. It's GPL, not LGPL software. My readline.h says:

The GNU Readline Library is free software; you can redistribute it
and/or modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2, or
(at your option) any later version.

see this ancient thread:
http://archives.postgresql.org/pgsql-hackers/2000-12/msg01029.php

cheers

andrew

Marc G. Fournier wrote:

Ooooh....

I got the impression that using GPL libraries was a Bad Thing(tm)

... John

So, what's the story with readline?

Bruce Momjian wrote:

John Hansen wrote:

What about GPL ?
I assume that's out of the question!

If we add some GPL code, the entire binary becomes GPL, and that
prevents closed-source commercial versions from being produced.

When I went searching for some code to make a directory path in initdb,
I carefully avoided all the GPL versions, which is why I picked the code
from NetBSD. Anyone taking code from elsewhere to use in PostgreSQL
should a) acknowledge the source and b) be aware of this issue.

cheers

andrew

Andrew Dunstan wrote:

Bruce Momjian wrote:

John Hansen wrote:

What about GPL ?
I assume that's out of the question!

If we add some GPL code, the entire binary becomes GPL, and that
prevents closed-source commercial versions from being produced.

When I went searching for some code to make a directory path in initdb,
I carefully avoided all the GPL versions, which is why I picked the code
from NetBSD. Anyone taking code from elsewhere to use in PostgreSQL
should a) acknowledge the source and b) be aware of this issue.

Agreed.

With libreadline, we are not taking their code or distributing it, but
merely linking to it if it exists. Now, some say that is enough to make
us GPL, but many don't agree with that interpretation.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Agreed.

With libreadline, we are not taking their code or
distributing it, but merely linking to it if it exists. Now,
some say that is enough to make us GPL, but many don't agree
with that interpretation.

Right,. That's actually exactly what I meant: using GPL/LGPL libraries
by linking to them.

John Hansen wrote:

So, what's the story with readline?

It's only used in psql. If they made a fuss presumably we'd just remove
the hooks and use libedit instead - isn't that the default on some BSD
systems anyway?

But don't plug GPL code into the backend under any circumstances.

cheers

andrew

John Hansen wrote:

So, what's the story with readline?

There is a greyish clause in the GPL that says that linking to things
normally distributed with your operating system doesn't incur the
obligations of the GPL. So assuming that readline, which is GPL, is
normally distributed with your operating system, you are at liberty to
use it without being bound to apply the GPL to your code. Another
example is the Linux kernel - you (or at least, many do, even if not you
personally, I don't know your predilections :)) use it all the time, and
it's GPL, but using it doesn't mean that all your apps are subject to
the GPL.

BTW the GPL is all about distribution - for your own private use on your
own computer, you can link whatever you like to whatever you like - the
issues crop up when you try to distribute such a system to anyone else,
you then become obliged to give that someone else the rights that the
GPL requires. So linking to GPL (or LGPL) code is not acceptable for the
PostgreSQL project itself, but might be acceptable for you personally,
depending on what you're doing.

Tim

--
-----------------------------------------------
Tim Allen tim@proximity.com.au
Proximity Pty Ltd http://www.proximity.com.au/

John Hansen wrote:

Agreed.

With libreadline, we are not taking their code or
distributing it, but merely linking to it if it exists. Now,
some say that is enough to make us GPL, but many don't agree
with that interpretation.

Right,. That's actually exactly what I meant: using GPL/LGPL libraries
by linking to them.

Don't confuse these two. LGPL contains an explicit permission to link to
an unmodified library without importing the GPL conditions into your
code. GPL does not. That's why there was all the fuss when MySQL changed
the licence on their libraries from LGPL to GPL (don't even get me
started about the ethics of applying a more restrictive license to your
work after you've been distributing it for years).

cheers

andrew

"John Hansen" <john@geeknet.com.au> writes:

Is there any reason why we would not be able to use LGPL code in PG?

Another point of view on this: it's OK to use LGPL code if it's
available on the local platform, so long as we don't *require* it to be
present. It's even safer if the LGPL code is merely one implementation
of an API that has other implementations under different licenses.
For instance I have no fear at all of linking to glibc, and little of
linking to libreadline (the latter because we can also use the BSD
libedit).

If we could not build without libreadline then we would have a very
big problem. And we certainly aren't going to textually incorporate
any new LGPL (or GPL) code into our distribution.

regards, tom lane

Tom Lane [mailto:tgl@sss.pgh.pa.us] Wrote:

"John Hansen" <john@geeknet.com.au> writes:

Is there any reason why we would not be able to use LGPL code in PG?

Another point of view on this: it's OK to use LGPL code if
it's available on the local platform, so long as we don't
*require* it to be present. It's even safer if the LGPL code
is merely one implementation of an API that has other
implementations under different licenses.
For instance I have no fear at all of linking to glibc, and
little of linking to libreadline (the latter because we can
also use the BSD libedit).

If we could not build without libreadline then we would have
a very big problem. And we certainly aren't going to
textually incorporate any new LGPL (or GPL) code into our
distribution.

Right,... Let me be more specific then,....

What are your thoughts on using the glib
(http://developer.gnome.org/doc/API/2.2/glib/index.html) library for
some functionality in pg?

Additionally,. I came across this fine library
(http://home.gna.org/uri/uri.en.html) which I'd like to use as a base
for a new URI type, unfortunately it's GPL, so based on the above I'm
guessing using it as is, is out of the question?

"John Hansen" <john@geeknet.com.au> writes:

Right,... Let me be more specific then,....

What are your thoughts on using the glib
(http://developer.gnome.org/doc/API/2.2/glib/index.html) library for
some functionality in pg?

Right offhand that seems like a nonstarter. Exactly how would you use
it in a way that didn't turn it into a required component? It looks
to me like a collection of bits that are pretty useful but also very
low-level, and hence not easily separable.

Additionally,. I came across this fine library
(http://home.gna.org/uri/uri.en.html) which I'd like to use as a base
for a new URI type, unfortunately it's GPL, so based on the above I'm
guessing using it as is, is out of the question?

Sure, you can do whatever you like with that ... as long as you're not
expecting us to distribute the combined code as part of Postgres.

It's worth reiterating here that GPL/LGPL code plus BSD code is no
problem whatever for local development and use. It's only if you want
to redistribute the result that you have to worry about what the
licenses require. Since Postgres is a BSD-license project, *we* are not
going to redistribute any GPL or LGPL code, nor any code that
fundamentally depends on code that is so licensed. But you can pretty
much do what you like in your own sandbox. In particular, you could
develop a datatype that requires a GPL/LGPL library, and then distribute
that code by itself as GPL/LGPL, and neither the GPL nor BSD camps would
have any problem with that. Just don't expect us to put such code in a
BSD distribution ...

regards, tom lane

Tom Lane [mailto:tgl@sss.pgh.pa.us] Wrote:

"John Hansen" <john@geeknet.com.au> writes:

Right,... Let me be more specific then,....

What are your thoughts on using the glib
(http://developer.gnome.org/doc/API/2.2/glib/index.html)

library for

some functionality in pg?

Right offhand that seems like a nonstarter. Exactly how
would you use it in a way that didn't turn it into a required
component? It looks to me like a collection of bits that are
pretty useful but also very low-level, and hence not easily separable.

K, that's what confused me as I got the impression it was ok to require
LGPL libraries but not GPL.

Additionally,. I came across this fine library
(http://home.gna.org/uri/uri.en.html) which I'd like to use

as a base

for a new URI type, unfortunately it's GPL, so based on the

above I'm

guessing using it as is, is out of the question?

Sure, you can do whatever you like with that ... as long as
you're not expecting us to distribute the combined code as
part of Postgres.

It's worth reiterating here that GPL/LGPL code plus BSD code
is no problem whatever for local development and use. It's
only if you want to redistribute the result that you have to
worry about what the licenses require. Since Postgres is a
BSD-license project, *we* are not going to redistribute any
GPL or LGPL code, nor any code that fundamentally depends on
code that is so licensed. But you can pretty much do what
you like in your own sandbox. In particular, you could
develop a datatype that requires a GPL/LGPL library, and then
distribute that code by itself as GPL/LGPL, and neither the
GPL nor BSD camps would have any problem with that. Just
don't expect us to put such code in a BSD distribution ...

That's what I was afraid of....

regards, tom lane

... John

John Hansen wrote:

Tom Lane [mailto:tgl@sss.pgh.pa.us] Wrote:

"John Hansen" <john@geeknet.com.au> writes:

Right,... Let me be more specific then,....

What are your thoughts on using the glib
(http://developer.gnome.org/doc/API/2.2/glib/index.html)

library for

some functionality in pg?

Right offhand that seems like a nonstarter. Exactly how
would you use it in a way that didn't turn it into a required
component? It looks to me like a collection of bits that are
pretty useful but also very low-level, and hence not easily separable.

K, that's what confused me as I got the impression it was ok to require
LGPL libraries but not GPL.

I think the answer isn't clear on that one.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Wed, 15 Jun 2005, Bruce Momjian wrote:

K, that's what confused me as I got the impression it was ok to require
LGPL libraries but not GPL.

I think the answer isn't clear on that one.

If that is not clear then what is the difference between a LGPL lib and a
GPL one? To copy code from said lib into pg could never be allowed, but
just linking to it surely can not be a problem.

LGPL libs are used all over by all kinds of closed sorce applications and
that's the whole idea of making things (like glib) into LGPL instead of
GPL. For example Acrobat Reader 7 for unix uses GTK+ and it is LGPL.
Acrobat Reader surely do require GTK+.

--
/Dennis Bj�rklund

Dennis Bjorklund wrote:

On Wed, 15 Jun 2005, Bruce Momjian wrote:

K, that's what confused me as I got the impression it was ok to require
LGPL libraries but not GPL.

I think the answer isn't clear on that one.

If that is not clear then what is the difference between a LGPL lib and a
GPL one? To copy code from said lib into pg could never be allowed, but
just linking to it surely can not be a problem.

LGPL libs are used all over by all kinds of closed sorce applications and
that's the whole idea of making things (like glib) into LGPL instead of
GPL. For example Acrobat Reader 7 for unix uses GTK+ and it is LGPL.
Acrobat Reader surely do require GTK+.

Maybe LGPL is OK, but I think we will try to avoid a dependency on LGPL
code if we can help it.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

LGPL libs are used all over by all kinds of closed sorce applications and
that's the whole idea of making things (like glib) into LGPL instead of
GPL. For example Acrobat Reader 7 for unix uses GTK+ and it is LGPL.
Acrobat Reader surely do require GTK+.

Maybe LGPL is OK, but I think we will try to avoid a dependency on LGPL
code if we can help it.

It can be argued that the LGPL is a "better" license than the GPL or
BSD. For example:

GPL module: programmer releases, second programmer picks up, must also
release under the gpl. If it is a derivative product that product must
be under the GPL. All changes must be released back.

BSD: programmer releases, second programmer can steal it, legally and
do pretty much anything he wants with it, including close source it
and not give changes back.

LGPL: programmer releases, second programmer picks up, must submit
changes back as LGPL BUT second programmer can close source products
around the LGPL code.

LGPL is what makes people be able to create closed source apps on linux
that are derived from gcc.

My understanding is that if libc on Linux was GPL (instead of LGPL) then
PostgreSQL would not legally be able to be compiled on the platform
without it too being GPL.

That is one of the reason why the major corps solidified on Gnome.
Because if you make a Gnome app you don't HAVE to give it away. If
you make a KDE app, you do (Unless you purchase QT).

Sincerely,

Joshua D. Drake

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Bruce Momjian wrote:

Maybe LGPL is OK, but I think we will try to avoid a dependency on LGPL
code if we can help it.

License issues aside, should we not be trying to avoid adding
dependencies on third party libraries, especially those that are not
standard on most operating systems? Also bear in mind that any required
library would need to be supported on Windows as well as on *nix.

cheers

andrew

Andrew Dunstan wrote:

Bruce Momjian wrote:

Maybe LGPL is OK, but I think we will try to avoid a dependency on LGPL
code if we can help it.

License issues aside, should we not be trying to avoid adding
dependencies on third party libraries, especially those that are not
standard on most operating systems? Also bear in mind that any required
library would need to be supported on Windows as well as on *nix.

Yep, that's an issue too.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

John,

What are your thoughts on using the glib
(http://developer.gnome.org/doc/API/2.2/glib/index.html) library for
some functionality in pg?
Additionally,. I came across this fine library
(http://home.gna.org/uri/uri.en.html) which I'd like to use as a base
for a new URI type, unfortunately it's GPL, so based on the above I'm
guessing using it as is, is out of the question?

Both of these would be fine as add-ins to be distributed *separately* through
pgFoundry or even the mirrors if they prove popular. Bundling them in
unified distribution binaries with PostgreSQL would be a significant problem.

You see this in other projects all the time: "Requriements: ______, which is
GPL and can be downloaded from __________ ." We've managed so far to avoid
needing external libraries which are not standard on most POSIX platforms,
and it would be nice to keep it that way instead of doing the "component
easter egg hunt" (which users of Linux multimedia apps are familiar with).

This means that you're unlikely to be able to use glib unless it becomes
standard on POSIX platforms, and someone makes a Windows port. Out of
curiosity, what did you want to use it *for*?

As for a URI type, I don't see the problem with doing that as a PostgreSQL
add-in downloadable from PGFoundry. Given the variety of URI
implementations, I'm not sure we'd want a single URI type as standard anyway.
According to the FSF's junior licensing maven, building in a GPL data type or
other plug-in would make *your instance* of PostgreSQL GPL, but so does PL/R
and PostGIS, so that's nothing new. It just needs to be distributed
separately.

FYI, the reason the GPL "linking" issue is vague is that it depends on local
copyright law, which varies from country to country and in the US from state
to state. This is deliberate by the FSF because an agreement which depends
on local copyright law is stronger in court than one which sets its own
explicit terms. If anyone has nuts-and-bolts questions about GPL/LGPL
issues, I have some friends at the FSF and can get answers from "the horse's
mouth."

--
Josh Berkus
Aglio Database Solutions
San Francisco

Josh,

Both of these would be fine as add-ins to be distributed *separately*

through

pgFoundry or even the mirrors if they prove popular.
Bundling them in unified distribution binaries with PostgreSQL would

be a

significant problem.

You see this in other projects all the time: "Requriements:
______, which is GPL and can be downloaded from __________ ."
We've managed so far to avoid needing external libraries
which are not standard on most POSIX platforms, and it would
be nice to keep it that way instead of doing the "component
easter egg hunt" (which users of Linux multimedia apps are
familiar with).

This means that you're unlikely to be able to use glib unless
it becomes standard on POSIX platforms, and someone makes a
Windows port. Out of curiosity, what did you want to use it *for*?

Ohh,. Just felt like a cleaner interface than ICU,....

As for a URI type, I don't see the problem with doing that as
a PostgreSQL add-in downloadable from PGFoundry. Given the
variety of URI implementations, I'm not sure we'd want a
single URI type as standard anyway.

That I don't know,.... Yet... However what I've come up with so far, has
proven quite useful.

Remember the all famous 'email' type?
This has the same functionality, if not better....

create table email_addresses (email_address text,uri uri);
insert into email_addresses (email_address) VALUES
('john@geeknet.com.au');
update email_addresses set uri = 'mailto:'||email_address::text; <--
could be a rule on insert!
select (uri).username,(uri).host from email_addresses ;
username | host
----------+----------------
john | geeknet.com.au
(1 row)

And here's the really funky bit:

select email_address = 'john@GeekNET.com.au' from email_addresses ;
?column?
----------
f
(1 row)

select uri = 'mailto:john@GeekNET.com.au'::text::uri from
email_addresses ;
?column?
----------
t
(1 row)

As it should, since email sent to the two email addresses would end up
in the same mailbox....
The same applies to other URI formats of course. It appears this uri
library is fully spec compliant.

According to the FSF's junior licensing maven, building in a
GPL data type or other plug-in would make *your instance* of
PostgreSQL GPL, but so does PL/R and PostGIS, so that's
nothing new. It just needs to be distributed separately.

FYI, the reason the GPL "linking" issue is vague is that it
depends on local copyright law, which varies from country to
country and in the US from state to state. This is
deliberate by the FSF because an agreement which depends on
local copyright law is stronger in court than one which sets its own
explicit terms. If anyone has nuts-and-bolts questions
about GPL/LGPL
issues, I have some friends at the FSF and can get answers
from "the horse's mouth."

Thanks for the explanation....

--
Josh Berkus
Aglio Database Solutions
San Francisco

... John

With libreadline, we are not taking their code or distributing it, but
merely linking to it if it exists.

But we are also requiring it. The rpms won't install unless readline is
available.

Now, some say that is enough to make

us GPL, but many don't agree with that interpretation.

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

On Fri, 17 Jun 2005, Joshua D. Drake wrote:

With libreadline, we are not taking their code or distributing it, but
merely linking to it if it exists.

But we are also requiring it. The rpms won't install unless readline is
available.

that isn't a PostgreSQL requirement though, that is a packagers
requirement ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Am Dienstag, den 14.06.2005, 22:59 -0300 schrieb Marc G. Fournier:

We already do ... libreadline ...

Hm. I remember in my source builds I used libedit
which is the BSD replacement IIRC?

Joshua D. Drake wrote:

With libreadline, we are not taking their code or distributing it, but
merely linking to it if it exists.

But we are also requiring it. The rpms won't install unless readline
is available.

Now, some say that is enough to make

us GPL, but many don't agree with that interpretation.

We have been down this road before. You can not be forced to GPL your
code. You can be forced to stop using GPL code if you are in breach of
the GPL. That's according to the FSF themselves (specifically Eblen
Moglen). Some people have chosen to GPL their code rather than stop
their reliance on GPL code. That would would be a no-brainer choice for
us, as there is a simple BSD licensed replacement for libreadline.

So relax ;-) All is well.

cheers

andrew

Marc G. Fournier wrote:

On Fri, 17 Jun 2005, Joshua D. Drake wrote:

With libreadline, we are not taking their code or distributing it, but
merely linking to it if it exists.

But we are also requiring it. The rpms won't install unless readline
is available.

that isn't a PostgreSQL requirement though, that is a packagers
requirement ...

If we link to readline, postgresql won't start without it. Regardless of
the package. That seems pretty much a postgresql requirement ;)

Sincerely,

Joshua D. Drake

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Huh ?

./configure --without-readliine

works just fine, there is no requirement.

Dave
On 17-Jun-05, at 3:04 PM, Joshua D. Drake wrote:

Joshua D. Drake wrote:

If we link to readline, postgresql won't start without it. Regardless
of the package. That seems pretty much a postgresql requirement ;)

If you think you're in danger don't link to it. You don't have to at
all. You can build without readline entirely (it's only needed for psql)
or you can link to libedit instead.

So it's a postgresql option, not a requirement.

But they'll never worry anyway, it would be a complete waste of time and
money to pursue you over it.

cheers

andrew

Dave Cramer wrote:

Huh ?

./configure --without-readliine

works just fine, there is no requirement.

Again:

If we **link** to readline, postgresql won't start without it.
That is a postgresql requirement. Yes we can compile without
it. That isn't what I was talking about.

But as Andrew pointed out, it doesn't really matter.

Sincerely,

Joshua D. Drake

Dave
On 17-Jun-05, at 3:04 PM, Joshua D. Drake wrote:

Marc G. Fournier wrote:

On Fri, 17 Jun 2005, Joshua D. Drake wrote:

With libreadline, we are not taking their code or distributing it,
but
merely linking to it if it exists.

But we are also requiring it. The rpms won't install unless
readline is available.

that isn't a PostgreSQL requirement though, that is a packagers
requirement ...

If we link to readline, postgresql won't start without it. Regardless
of the package. That seems pretty much a postgresql requirement ;)

Sincerely,

Joshua D. Drake

----
Marc G. Fournier Hub.Org Networking Services (http://
www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ:
7615664

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Joshua D. Drake wrote:

Dave Cramer wrote:

Huh ?

./configure --without-readliine

works just fine, there is no requirement.

Again:

If we **link** to readline, postgresql won't start without it.
That is a postgresql requirement. Yes we can compile without
it. That isn't what I was talking about.

But as Andrew pointed out, it doesn't really matter.

The point is the the source does not require it, but specific binaries
might based on how they are built.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

"Joshua D. Drake" <jd@commandprompt.com> writes:

With libreadline, we are not taking their code or distributing it, but
merely linking to it if it exists.

But we are also requiring it. The rpms won't install unless readline is
available.

The RPMs require it --- not our source code. Since the RPMs can only
work atop a GPL OS (Linux), it hardly matters in that context.

What is important is that it is possible, and useful, to build Postgres
in a completely non-GPL environment. If that were not so then I think
we'd have some license issues. But the fact that building PG in a
GPL-ized environment creates a GPL-ized binary is not a problem from my
point of view. You've already bought into the GPL if you're using that
environment.

regards, tom lane

On 6/18/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:

What is important is that it is possible, and useful, to build Postgres
in a completely non-GPL environment. If that were not so then I think
we'd have some license issues. But the fact that building PG in a
GPL-ized environment creates a GPL-ized binary is not a problem from my
point of view. You've already bought into the GPL if you're using that
environment.

Put another way: Linking to a GPLed library creates a gpled result,
but being GPLed is completely and totally irrelevant to *users*
because the GPL places no restrictions on use whatsoever.

... But is it really the case that PostgreSQL developers are being
paid to code because PG is BSDed and proprietary forks are possible?
... There is no harm in being BSDed, but I question that the users of
PostgreSQL are gaining enough advantage that there needs to be so much
paranoia about making sure that the code is as easy as possible to
make propritary forks of...

On Saturday 18 June 2005 01:43, Gregory Maxwell wrote:

On 6/18/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
... But is it really the case that PostgreSQL developers are being
paid to code because PG is BSDed and proprietary forks are possible?
... There is no harm in being BSDed, but I question that the users of
PostgreSQL are gaining enough advantage that there needs to be so much
paranoia about making sure that the code is as easy as possible to
make propritary forks of...

SRA, Greenplumb, and EnterpriseDB are just three of the companies that both
subsidize development and release non-bsd/proprietary versions of PostgreSQL.
You can bet they wouldn't be so quick to work with us if we weren't BSD
licensed. The community benefits greatly from our BSD license, and IMHO it
is the central factor that will eventually allow postgresql to achive total
world domination ;-)

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Tom Lane wrote:

What is important is that it is possible, and useful, to build Postgres
in a completely non-GPL environment. If that were not so then I think
we'd have some license issues. But the fact that building PG in a
GPL-ized environment creates a GPL-ized binary is not a problem from my
point of view. You've already bought into the GPL if you're using that
environment.

So, is there an effort to not require GNU make then ?

Peter

Peter Galbavy <peter.galbavy@knowtion.net> writes:

So, is there an effort to not require GNU make then ?

No, that's not relevant. GNU make is a tool, not part of the end
result.

A more interesting question is Autoconf, which we also depend on
as a build tool, and which does copy parts of itself into the
distributed product. However, Autoconf explicitly releases its
output scripts as entirely free software, not GPL code.

regards, tom lane

On Sat, Jun 18, 2005 at 08:43:01 +0100,
Peter Galbavy <peter.galbavy@knowtion.net> wrote:

Tom Lane wrote:

What is important is that it is possible, and useful, to build Postgres
in a completely non-GPL environment. If that were not so then I think
we'd have some license issues. But the fact that building PG in a
GPL-ized environment creates a GPL-ized binary is not a problem from my
point of view. You've already bought into the GPL if you're using that
environment.

So, is there an effort to not require GNU make then ?

Neither using GNU make or gcc make to buld a binary make the resulting binary
bound by the GPL.

So, is there an effort to not require GNU make then ?

Neither using GNU make or gcc make to buld a binary make the resulting binary
bound by the GPL.

That is correct because all (well most) of the libraries used by GCC are
LGPL not GPL.

Sincerely,

Joshua D. Drake