contrib and licensing

mlw <pgsql@mohawksoft.com> writes:

I know nothing in contrib should be GPL, I have no problem with that.
The question is the requirement of a GPL library to build a contrib project.

My SOAP/XML function will probably require my LGPL library as there is a
lot of code I have written that I would need to implement it.

If it won't work without your library then there's not much point in
putting it into contrib. Might as well just put it in your library
and distribute same as you have been doing.

regards, tom lane

Tom Lane wrote:

mlw <pgsql@mohawksoft.com> writes:

I know nothing in contrib should be GPL, I have no problem with that.
The question is the requirement of a GPL library to build a contrib project.

My SOAP/XML function will probably require my LGPL library as there is a
lot of code I have written that I would need to implement it.

If it won't work without your library then there's not much point in
putting it into contrib. Might as well just put it in your library
and distribute same as you have been doing.

I'm a little put off by this attitude, are you saying there are no LGPL
dependencies in PostgreSQL or /contrib?

If that is a real objective, I'm surprised.

On Wed, 2 Apr 2003, mlw wrote:

Tom Lane wrote:

mlw <pgsql@mohawksoft.com> writes:

I know nothing in contrib should be GPL, I have no problem with that.
The question is the requirement of a GPL library to build a contrib project.

My SOAP/XML function will probably require my LGPL library as there is a
lot of code I have written that I would need to implement it.

If it won't work without your library then there's not much point in
putting it into contrib. Might as well just put it in your library
and distribute same as you have been doing.

I'm a little put off by this attitude, are you saying there are no LGPL
dependencies in PostgreSQL or /contrib?

If that is a real objective, I'm surprised.

I think it's more that if the lib is commonly included in most
environments, like say readline is, then someone will have to download the
lib seperately anyway, so you might as well have the soap functions be
there at the same place.

If your LGPL lib and / or an analog in BSD land are common, then including
it in contrib would make perfect sense.

On Wed, 2 Apr 2003, mlw wrote:

Tom Lane wrote:

mlw <pgsql@mohawksoft.com> writes:

I know nothing in contrib should be GPL, I have no problem with that.
The question is the requirement of a GPL library to build a contrib project.

My SOAP/XML function will probably require my LGPL library as there is a
lot of code I have written that I would need to implement it.

If it won't work without your library then there's not much point in
putting it into contrib. Might as well just put it in your library
and distribute same as you have been doing.

I'm a little put off by this attitude, are you saying there are no LGPL
dependencies in PostgreSQL or /contrib?

In fact, yes ... or, at least, if there are any left in /contrib, its only
because we haven't moved them to gborg yet ...

If that is a real objective, I'm surprised.

The base source tree has always been as BSD pure as we can make it ... its
never been kept a secret ...

On Wed, 2 Apr 2003, Marc G. Fournier wrote:

On Wed, 2 Apr 2003, mlw wrote:

Tom Lane wrote:

mlw <pgsql@mohawksoft.com> writes:

I know nothing in contrib should be GPL, I have no problem with that.
The question is the requirement of a GPL library to build a contrib project.

My SOAP/XML function will probably require my LGPL library as there is a
lot of code I have written that I would need to implement it.

If it won't work without your library then there's not much point in
putting it into contrib. Might as well just put it in your library
and distribute same as you have been doing.

I'm a little put off by this attitude, are you saying there are no LGPL
dependencies in PostgreSQL or /contrib?

In fact, yes ... or, at least, if there are any left in /contrib, its only
because we haven't moved them to gborg yet ...

a program in /contrib linking to an LGPL lib has never been an issue.
Linking to LGPL libs doesn't encumber the software linking to it.

If that is a real objective, I'm surprised.

The base source tree has always been as BSD pure as we can make it ... its
never been kept a secret ...

True. But not linking to LGPLd libs would be a bit extreme there.

On Wed, 2 Apr 2003, scott.marlowe wrote:

If that is a real objective, I'm surprised.

The base source tree has always been as BSD pure as we can make it ... its
never been kept a secret ...

True. But not linking to LGPLd libs would be a bit extreme there.

Correct, we've always had libreadline support, as a compile option, but
libreadline is not part of the distribution, only the hooks to it are ...
and, just recently, libedit(?) support was added as well, so that a
non-GPL licensed alternative is available for those wishing to distribute
the software ...

mlw writes:

I'm a little put off by this attitude, are you saying there are no LGPL
dependencies in PostgreSQL or /contrib?

No, the point is, why put it in contrib when someone who wants to use it
has to download your library anyway. Then you might as well distribute
the module next to that library.

--
Peter Eisentraut peter_e@gmx.net

On Wed, 2003-04-02 at 18:00, Marc G. Fournier wrote:

On Wed, 2 Apr 2003, scott.marlowe wrote:

True. But not linking to LGPLd libs would be a bit extreme there.

Correct, we've always had libreadline support, as a compile option

Why is that relevant? libreadline is GPL'd, not LGPL'd.

Cheers,

Neil

[snip]

a program in /contrib linking to an LGPL lib has never been
an issue.
Linking to LGPL libs doesn't encumber the software linking to it.

If that is a real objective, I'm surprised.

The base source tree has always been as BSD pure as we can

make it ...

its never been kept a secret ...

True. But not linking to LGPLd libs would be a bit extreme there.

========================================================================
=======
NOTE UP FRONT -- Please email all flames directly to me at
dcorbit@connx.com ...
========================================================================
=======

I disagree. Because of the language in the LGPL:
http://www.gnu.org/copyleft/lesser.txt

I would not use LGPL tools in any finished commercial project. For me,
if PostgreSQL linked against LGPL libraries, it would kill its
usefulness for me completely.

One interpretation of the following:
"For example, if you distribute copies of the library, whether gratis
or for a fee, you must give the recipients all the rights that we gave
you. You must make sure that they, too, receive or can get the source
code. If you link other code with the library, you must provide
complete object files to the recipients, so that they can relink them
with the library after making changes to the library and recompiling
it. And you must show them these terms so they know their rights."

Would be that tools that use LGPL libraries must also be distributed
without cost.

Consider this section:

"However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables."

LGPL is also a virus [IMO-YMMV]. Please send all flames directly to my
email address [dcorbit@connx.com] so we don't fill up the PG list with
advocacy stuff.

Commercial systems can get very paranoid over questionable legal
language. Even if what it says is not "what was intended" -- that is
still what it says and might possibly be enforced at some future time.

Pure opinion of mine says...
The BSD license is a very good license.
The ACE license is a very good license.
http://www.cs.wustl.edu/~schmidt/ACE-copying.html
The MIT license is a very good license.

There are others:
http://www.opensource.org/licenses/

Now, I don't care if PostgreSQL has a TON of GPL stuff in it as long as
it is OPTIONAL. I don't care if you have to use GPL/LGPL tools to build
it, as long as they are not directly linked into it.

mlw <pgsql@mohawksoft.com> writes:

Tom Lane wrote:

If it won't work without your library then there's not much point in
putting it into contrib. Might as well just put it in your library
and distribute same as you have been doing.

I'm a little put off by this attitude, are you saying there are no LGPL
dependencies in PostgreSQL or /contrib?

If that is a real objective, I'm surprised.

The intention is that the entire distribution, including contrib, be under
straight BSD license. This is a real objective --- we're not there yet,
mainly because it's not being pursued vigorously with regard to the
contrib modules already in place, but we think it is a valuable way of
minimizing confusion.

We have no problem at all with offering gborg project space to LGPL or
GPL-licensed code; it's just that we don't want it in the core
distribution, so that people don't have to hunt-and-peck through the
distro to see which parts are under which license.

Although you indicated willingness to provide the SOAP code per se as
BSD license, it seems to me that this is rather pointless if it can't
be used without an LGPL'd associated library. Someone who wanted a
pure-BSD setup would still be unable to use the code. The SOAP code
plus underlying library would be a more sensible distribution unit,
and as such you might as well make it all LGPL.

Of course, if you wanted to make it all BSD and put the whole mess in
contrib, we'd be open to that idea ...

regards, tom lane

On Wednesday 02 April 2003 18:11, Dann Corbit wrote:
[snip]

True. But not linking to LGPLd libs would be a bit extreme there.

I disagree. Because of the language in the LGPL:
http://www.gnu.org/copyleft/lesser.txt

I would not use LGPL tools in any finished commercial project. For me,
if PostgreSQL linked against LGPL libraries, it would kill its
usefulness for me completely.

"However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables."

<stifles ROTFL>

Everyone does realize that on Linux PostgreSQL binaries link against glibc,
which is LGPL......
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Wed, 2 Apr 2003, Lamar Owen wrote:

On Wednesday 02 April 2003 18:11, Dann Corbit wrote:
[snip]

True. But not linking to LGPLd libs would be a bit extreme there.

I disagree. Because of the language in the LGPL:
http://www.gnu.org/copyleft/lesser.txt

I would not use LGPL tools in any finished commercial project. For me,
if PostgreSQL linked against LGPL libraries, it would kill its
usefulness for me completely.

"However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables."

<stifles ROTFL>

Everyone does realize that on Linux PostgreSQL binaries link against glibc,
which is LGPL......

I assume the standard dynamic linker counts as "a suitable shared library
mechanism for linking with the Library" as per LGPL 6b. ;)

Lamar Owen <lamar.owen@wgcr.org> writes:

<stifles ROTFL>

Everyone does realize that on Linux PostgreSQL binaries link against glibc,
which is LGPL......

And your point is?

On other Unixoid systems you can link against BSD-license libc code, or
some-random-proprietary-license code from HP or Sun or whomever. glibc
doesn't have a monopoly in that sphere. But mlw is offering code that
will *only* run against a single implementation that is LGPL licensed.
That makes it effectively LGPL.

regards, tom lane

On Wednesday 02 April 2003 22:39, Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

<stifles ROTFL>

Everyone does realize that on Linux PostgreSQL binaries link against
glibc, which is LGPL......

And your point is?

That everyone is being entirely too picky. Hey, we link against other things,
too. Some aren't LGPL. The readline example is a good one, incidentally:
it's GPL. And its stubs are in the backend, of all places. At least on
Linux.

Gotta watch any 'static builds' then.

On other Unixoid systems you can link against BSD-license libc code, or
some-random-proprietary-license code from HP or Sun or whomever. glibc
doesn't have a monopoly in that sphere. But mlw is offering code that
will *only* run against a single implementation that is LGPL licensed.
That makes it effectively LGPL.

One could clean-room reimplement if the demand is enough.

But, if one wants to get picky, let's talk about the license issue of
PL/Python. The PSF looks like a rat's nest.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:

And your point is?

That everyone is being entirely too picky. Hey, we link against other
things, too. Some aren't LGPL. The readline example is a good one,
incidentally: it's GPL.

Yeah, it's an excellent example: there is an alternative implementation
under a different license (libedit).

And its stubs are in the backend, of all places.

Really? I must have missed that.

One could clean-room reimplement if the demand is enough.

Certainly, any of this stuff *could* be reimplemented. But for stuff
that's being proposed for contrib, what's theoretically possible given
enough demand isn't the important real-world issue. Contrib stuff is,
by definition, stuff that hasn't yet had all that much work put into it.
So it's appropriate to ask where it can really run *right now*.

regards, tom lane

On Wednesday 02 April 2003 21:59, Stephan Szabo wrote:

On Wed, 2 Apr 2003, Lamar Owen wrote:

"However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables."

Everyone does realize that on Linux PostgreSQL binaries link against
glibc, which is LGPL......

I assume the standard dynamic linker counts as "a suitable shared library
mechanism for linking with the Library" as per LGPL 6b. ;)

Then I guess we had better not make any static linked builds, no?

The whole thread just got ridiculous, that's all. So I attempted to
illuminate the 'ridiculosity' of the whole matter. Speaking of 'ridiculous'
reminds me:

Readline is full-bore GPL. There's no 6b exception there. We dynamically
link readline, on most Linux distributions. Of course, Tom has a point;
there are alternatives available. None are as good as readline, though.
Which is one of the reasons it's GPL'd in the first place, according the the
GPL FAQ.

In fact, the GPL FAQ contains this little tidbit:

'If a library is released under the GPL (not the LGPL), does that mean that
any program which uses it has to be under the GPL?
Yes, because the program as it is actually run includes the library.'

:-O

Hmmm..... 'as it is actually run' means with the library embedded in the
resulting dynamically linked program -- just because it's dynamically linked
doesn't mean that code isn't part of the program. Should we say 'bye bye' to
readline?

Of course, there's the issue of the BSD license being 'compatible' with the
GPL. Then it gets hairy. And picky. Fun fun fun.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Thursday 03 April 2003 00:04, Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

And its stubs are in the backend, of all places.

Really? I must have missed that.

On Linux as compiled in Red Hat 9, at least:
[lowen@localhost lowen]$ ldd /usr/bin/postgres
libpam.so.0 => /lib/libpam.so.0 (0x4002c000)
libssl.so.4 => /lib/libssl.so.4 (0x40034000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0x40069000)
libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x4015a000)
libz.so.1 => /usr/lib/libz.so.1 (0x401b8000)
libreadline.so.4 => /usr/lib/libreadline.so.4 (0x401c6000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0x401f3000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x401f7000)
libresolv.so.2 => /lib/libresolv.so.2 (0x40224000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40236000)
libdl.so.2 => /lib/libdl.so.2 (0x4024b000)
libm.so.6 => /lib/tls/libm.so.6 (0x4024e000)
libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x40271000)
libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2
(0x40273000)
libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0x40286000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[lowen@localhost lowen]$ /usr/bin/postgres --version
postgres (PostgreSQL) 7.3.2
[lowen@localhost lowen]$

Certainly, any of this stuff *could* be reimplemented. But for stuff
that's being proposed for contrib, what's theoretically possible given
enough demand isn't the important real-world issue. Contrib stuff is,
by definition, stuff that hasn't yet had all that much work put into it.
So it's appropriate to ask where it can really run *right now*.

FWIW, very few things in contrib use anything beyond libc. The dblink stuff
is a notable exception. It needs an SSL and a Kerberos 5 library.

If the library is reasonably popular (meaning it's in at least one major OS
distribution, including Debian) then 'what's the harm?' If the lib isn't
that popular, then, regardless of license the question 'should something that
uses it even be here' should be asked. The issue of a straight GPL library
is serious for us; a LGPL one less so.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

"Marc G. Fournier" wrote:

On Wed, 2 Apr 2003, scott.marlowe wrote:

If that is a real objective, I'm surprised.

The base source tree has always been as BSD pure as we can make it ... its
never been kept a secret ...

True. But not linking to LGPLd libs would be a bit extreme there.

Correct, we've always had libreadline support, as a compile option, but
libreadline is not part of the distribution, only the hooks to it are ...
and, just recently, libedit(?) support was added as well, so that a
non-GPL licensed alternative is available for those wishing to distribute
the software ...

GPL vs. LGPL vs. BSD vs. MyFu**inLicense the next round ... man is this
annoying. I think with this new incarnation of the License war it's a
good time to give a real example what dragging our attention to
licensing leads to. Libedit might not be as good ... so be it. Who cares
about people who choose their database system by the color of the splash
screen? We have a pure BSD alternative that we could even ship with our
distro, time to retire the libreadline hooks.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Tom Lane wrote:

On other Unixoid systems you can link against BSD-license libc code, or
some-random-proprietary-license code from HP or Sun or whomever. glibc
doesn't have a monopoly in that sphere. But mlw is offering code that
will *only* run against a single implementation that is LGPL licensed.
That makes it effectively LGPL.

Here is my "vision" for lack of a better term.

Server 'A' runs a "web services" version of a PostgreSQL server, (or any
soap server) I have a working prototype that works.
Server 'B' runs a different instance of PostgreSQL.

With the ability to return multiple columns in a set of rows from a
function, it should be possible to do this:

select foo.a, bar.b from foo,
soapexec('http://somehost/pgsql?query=select+b+from+bar&#39;) as bar where
foo.b = bar.b;

(or something to that effect, the SQL may not be perfect.)

To be able to do that, we need:

some HTTP request code
a solid XML/SOAP parser.
The "soapexec" function needs to be able to do a few things:
Return more than one column in a multirow set.
Find out the field names that are expected.
Find out the datatypes that are expected to be returned to the query.

Tom, when one creates a function, can the function tell, in an efficient
way, what data types and names may be expected?

I have been talking about adding this feature to a few developers not
involved with PostgreSQL, and they are finatic about the idea. As far as
I can tell no other DB does this.