Horton

Thread

  1. Re: contrib and licensing

    Dann Corbit <dcorbit@connx.com> — 2003-04-02T23:11:54Z

    [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.

  2. Re: contrib and licensing

    Lamar Owen <lamar.owen@wgcr.org> — 2003-04-03T01:56:54Z

    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

  3. Re: contrib and licensing

    Stephan Szabo <sszabo@megazone23.bigpanda.com> — 2003-04-03T02:59:03Z

    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. ;)

  4. Re: contrib and licensing

    Tom Lane <tgl@sss.pgh.pa.us> — 2003-04-03T03:39:57Z

    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

  5. Re: contrib and licensing

    Lamar Owen <lamar.owen@wgcr.org> — 2003-04-03T04:53:38Z

    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

  6. Re: contrib and licensing

    Tom Lane <tgl@sss.pgh.pa.us> — 2003-04-03T05:04:33Z

    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

  7. Re: contrib and licensing

    Lamar Owen <lamar.owen@wgcr.org> — 2003-04-03T05:24:17Z

    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

  8. Re: contrib and licensing

    Lamar Owen <lamar.owen@wgcr.org> — 2003-04-03T05:35:15Z

    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

  9. Re: contrib and licensing

    Mark Woodward <pgsql@mohawksoft.com> — 2003-04-03T12:50:16Z

    
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') 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.



>
>  
>

  10. Re: contrib and licensing

    Tom Lane <tgl@sss.pgh.pa.us> — 2003-04-03T14:29:39Z

    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
>         libreadline.so.4 => /usr/lib/libreadline.so.4 (0x401c6000)

That's because our build mechanism links *all* needed libraries in *all*
executables, rather than trying to distinguish which ones are actually
used by each executable.  The ldd indication is the only connection to
libreadline --- if it had been a statically-linked situation, you'd find
no trace of readline (nor several other of these libraries, I suspect)
in the backend executable.

			regards, tom lane

  11. Re: contrib and licensing

    Lamar Owen <lamar.owen@wgcr.org> — 2003-04-03T16:38:59Z

    On Thursday 03 April 2003 09:29, 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
> >         libreadline.so.4 => /usr/lib/libreadline.so.4 (0x401c6000)

> That's because our build mechanism links *all* needed libraries in *all*
> executables, rather than trying to distinguish which ones are actually
> used by each executable.  The ldd indication is the only connection to
> libreadline --- if it had been a statically-linked situation, you'd find
> no trace of readline (nor several other of these libraries, I suspect)
> in the backend executable.

As I said, its 'stub' is there.

But it is in (and used by) psql (as of 7.3.2).
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

  12. Re: contrib and licensing

    Tom Lane <tgl@sss.pgh.pa.us> — 2003-04-03T16:47:38Z

    Lamar Owen <lamar.owen@wgcr.org> writes:
> But it is in (and used by) psql (as of 7.3.2).

Certainly.  I don't see a problem with that as far as the source
distribution goes; you can build it with readline, libedit, or neither.
Binary distributions are another matter.  I think a pretty good case
could be made for switching the RPMs to use libedit, if one wants to be
morally pristine about license issues.

			regards, tom lane