Thread: contrib and licensing
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. Is there any sort of philosophical problem with that?
On Tue, 2003-04-01 at 16:31, mlw wrote: > 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. > > Is there any sort of philosophical problem with that? There is a big difference between an LGPL'd library and a GPL'd library. The latter may have problems as I believe your code should be GPL'd, but the former should be fine. -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc
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? 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, 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, 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.
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, 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 ...
[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.
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
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') 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.
>
>
>
Jan Wieck wrote: >"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. > > I certainly didn't want to open up this can of worms, that's for sure. I have an amount of code that is LGPL, I would rather use it than write the bits again or try to extract them from the whole. The actual extension would be BSD, but it would need to link with my library. I made the library LGPL (from GPL) for the PHP group who have similar restrictions. Thus this discussion. I don't know what the answer is, but to say "NO LGPL" seems a bit extream, especially if you already have such dependencies. Then if you conclude you do allow LGPL libraries, but then only allow some libraries, not all, then what is the criteria for choosing which libraries get blessed. Is it purely "popularity?" Do you guys really think that a contrib function should not be allowed to require code which may not be on a common UNIX/BSD/Linux box?
mlw wrote: > > Jan Wieck wrote: > >[...] > >screen? We have a pure BSD alternative that we could even ship with our > >distro, time to retire the libreadline hooks. > > > > > I certainly didn't want to open up this can of worms, that's for sure. > > I have an amount of code that is LGPL, I would rather use it than write > the bits again or try to extract them from the whole. The actual > extension would be BSD, but it would need to link with my library. I > made the library LGPL (from GPL) for the PHP group who have similar > restrictions. > > Thus this discussion. If it is "your" library as you've said multiple times now, there is nothing that can stop you from relicensing it. Give me one good reason why you have to keep your library under the LGPL, or better why it cannot be relicensed under BSD. > I don't know what the answer is, but to say "NO LGPL" seems a bit > extream, especially if you already have such dependencies. Then if you > conclude you do allow LGPL libraries, but then only allow some > libraries, not all, then what is the criteria for choosing which > libraries get blessed. Is it purely "popularity?" Not more extreme than "I am the only true license, you shall not have any other licenses beside me", which is my personal interpretation of the entire FSF attempt. > Do you guys really think that a contrib function should not be allowed > to require code which may not be on a common UNIX/BSD/Linux box? Your library does appear in what Unix distributions? And in which of them is it installed by default like the libreadline? Yes, that certainly has to do with popularity. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
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
> mlw wrote: >> >> Jan Wieck wrote: >> >[...] >> >screen? We have a pure BSD alternative that we could even ship with >> >our distro, time to retire the libreadline hooks. >> > >> > >> I certainly didn't want to open up this can of worms, that's for sure. >> >> I have an amount of code that is LGPL, I would rather use it than >> write the bits again or try to extract them from the whole. The >> actual extension would be BSD, but it would need to link with my >> library. I made the library LGPL (from GPL) for the PHP group who have >> similar restrictions. >> >> Thus this discussion. > > If it is "your" library as you've said multiple times now, there is > nothing that can stop you from relicensing it. Give me one good reason > why you have to keep your library under the LGPL, or better why it > cannot be relicensed under BSD. I do not want to get in to a "my license theology is better or more correct than yours" discussion. Can we not do that? I have chosen to make the library open source and LGPL. Respect that. I respect that the PG group wants BSD, and everything that I would contribute to PG will be BSD. This issue is the requirement of a third party LGPL library. Ignore for the moment that it is mine. If I find a wiz-bang library that allows me to do something cool very easily, and I write a some code that would be good for postgresql's contrib, are you saying that it would not be usable because of the requirement of the library that is not included on standard system installations? > >> I don't know what the answer is, but to say "NO LGPL" seems a bit >> extream, especially if you already have such dependencies. Then if you >> conclude you do allow LGPL libraries, but then only allow some >> libraries, not all, then what is the criteria for choosing which >> libraries get blessed. Is it purely "popularity?" > > Not more extreme than "I am the only true license, you shall not have > any other licenses beside me", which is my personal interpretation of > the entire FSF attempt. Let's not bring this into an argument about BSD vs [L]GPL, it isn't about that. > >> Do you guys really think that a contrib function should not be allowed >> to require code which may not be on a common UNIX/BSD/Linux box? > > Your library does appear in what Unix distributions? And in which of > them is it installed by default like the libreadline? Yes, that > certainly has to do with popularity. Did the tools required to build PostgreSQL *always* come standard on systems? Could I currently build all the contrib directories on a RH 6.2 system without any extra libraries? The issue is: Is the requirement of an LGPL library that is more than likely not already on your system a disqualification for a contrib function? This is NOT a BSD vs [L]GPL argument, so lets not make it one. The actual code for the function *will* be BSD or any license you want.
pgsql@mohawksoft.com writes:
> If I find a wiz-bang library that allows me to do something cool very
> easily, and I write a some code that would be good for postgresql's contrib,
> are you saying that it would not be usable because of the requirement of the
> library that is not included on standard system installations?
The issue here is whether PG's contrib directory is the most appropriate
distribution mechanism for such code. There are at least two other
paths for distribution of PG add-ons: you can make a gborg project, or
you can distribute the add-on along with the wiz-bang library it depends
on (assuming you can interest the developers of libwizbang, which in
this case is presumably not a problem). In either of those cases
there's no problem at all with LGPL or GPL license terms.
We have taken a policy decision to keep the PG core distribution
(including contrib) straight BSD license --- and in my mind that
definitely includes not depending on any outside functionality that is
both (a) essential and (b) not available anywhere as BSD-license code.
It should be possible to build a PG installation that is pure BSD.
Whether people actually choose to do so is not the point.
regards, tom lane
pgsql@mohawksoft.com wrote: > The issue is: > Is the requirement of an LGPL library that is more than likely not already > on your system a disqualification for a contrib function? Yes. Because the requirement of something that is more likely not found on "usual" installations TOGETHER WITH that it cannot be included per se in a (not necessarily our) PostgreSQL distribution IMNSVHO disqualifies from being added to the official PostgreSQL release. As Tom pointed out, we aren't there yet with the cleanup. But we certainly don't want to add more candidates of that category to contrib. Everything that falls out of contrib can be added to gborg. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
> pgsql@mohawksoft.com writes: > We have taken a policy decision to keep the PG core distribution > (including contrib) straight BSD license --- and in my mind that > definitely includes not depending on any outside functionality that is > both (a) essential and (b) not available anywhere as BSD-license code. > It should be possible to build a PG installation that is pure BSD. > Whether people actually choose to do so is not the point. OK, that is more or less the answer to the question I originally posed. Thanks.
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
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
On Thu, 3 Apr 2003 pgsql@mohawksoft.com wrote: > If I find a wiz-bang library that allows me to do something cool very > easily, and I write a some code that would be good for postgresql's > contrib, are you saying that it would not be usable because of the > requirement of the library that is not included on standard system > installations? My two-bits here, but we're trying to *move* things out of contrib to gborg, like we have for most of the language interfaces ... why is/should this be any different? I don't care what licence it falls under, new contrib's should be going into gborg, not into the distribution itself ...
Tom Lane wrote: > pgsql@mohawksoft.com writes: > > If I find a wiz-bang library that allows me to do something cool very > > easily, and I write a some code that would be good for postgresql's contrib, > > are you saying that it would not be usable because of the requirement of the > > library that is not included on standard system installations? > > The issue here is whether PG's contrib directory is the most appropriate > distribution mechanism for such code. There are at least two other > paths for distribution of PG add-ons: you can make a gborg project, or > you can distribute the add-on along with the wiz-bang library it depends > on (assuming you can interest the developers of libwizbang, which in > this case is presumably not a problem). In either of those cases > there's no problem at all with LGPL or GPL license terms. > > We have taken a policy decision to keep the PG core distribution > (including contrib) straight BSD license --- and in my mind that > definitely includes not depending on any outside functionality that is > both (a) essential and (b) not available anywhere as BSD-license code. > It should be possible to build a PG installation that is pure BSD. > Whether people actually choose to do so is not the point. But if both of these paragraphs are simultaneously true, then why put *anything* in contrib? Why not, instead, put everything that is currently in contrib (and is BSD licensed) either on gborg, or in the main source tree itself? If it's code that we eventually intend to include in the main source tree but which isn't mature enough yet, then it's probably more appropriate to add a config switch to enable/disable compilation of that bit of code, rather than putting it into a "contrib" directory. But aside from such code, anyone who wants to create a binary distribution can grab the source for interesting packages from gborg. Debian does this, for instance. Nothing prevents us from putting the source tarballs for the most important gborg projects on the main ftp site, either. The theory behind putting things in contrib is that they will be useful to a great many people who run PG, but how useful something may be to the population at large is for the most part independent of the licensing of that something (at least, when you restrict yourself to GPL, LGPL, BSD, MIT, etc., licenses) -- Gnome, for instance, is very useful to a great many people, yet it is licensed under the GPL. The argument of whether or not something belongs in contrib is therefore independent of these licenses. If you're concerned about the distribution problems someone may run into when building and distributing binary versions of the code, there's an easy solution to that: don't build anything in contrib by default! Force the person building the code to make the decision whether or not to build the stuff in contrib, and inform him that licensing issues may be involved. People who are building binary distributions of PG for wide dissemination are already very much aware of the licensing issues involved in building any piece of software, especially one which comes with a bunch of "extras", so for them dealing with the licensing issues is simply not an issue. For almost everyone else, the licensing issues are not an issue at all because they don't intend to distribute the binaries to the rest of the world, only within their group or company -- something that, if I'm not mistaken, doesn't require them to adhere to the "viral" part of the license (since they're acting as an agent of the group or company, and the license applies to that group or company as a whole). I can understand the desire to keep the licensing of the PG package "clean", but if your concern is that great then perhaps you should go a little further and keep the *code* of the PG package "clean" as well, and remove contrib entirely (there is nothing at all that would prevent us from packaging up contrib as a separate tarball if we want to distribute its contents far and wide). There is some merit to that: it would force us to finally decide what really belongs in the main source tree (I'd argue that items such as the auto vacuum daemon belong there because it's functionality that should have been there from the beginning), rather than deferring the decision by putting it in contrib. Otherwise, perhaps you're more concerned about the licensing issues in contrib than you need to be? -- Kevin Brown kevin@sysexperts.com
Kevin Brown <kevin@sysexperts.com> writes:
> But if both of these paragraphs are simultaneously true, then why put
> *anything* in contrib?
Don't say that too loudly, or Marc may take it upon himself to make it
happen ;-).
There are a number of reasons to keep things in contrib. One is that
the code may be too tightly tied to backend innards to be appropriate to
maintain separately (the GIST extension modules are a good example, and
most of the modules that include server-side code are easier to maintain
with the server than not). Another is that small modules may not have
enough critical mass to get maintained at all, if they're kicked out to
live or die on their own.
> Otherwise, perhaps you're more concerned about the licensing issues in
> contrib than you need to be?
The way I see it, the "only BSD stuff in contrib" rule is designed
precisely to save us from having to think too hard about licensing
issues. I'm not interested in getting into lawyeristic arguments
about how it's okay to distribute something with a different license
if only we don't do XYZ with it.
regards, tom lane
Tom Lane wrote: > Kevin Brown <kevin@sysexperts.com> writes: > > But if both of these paragraphs are simultaneously true, then why put > > *anything* in contrib? > > Don't say that too loudly, or Marc may take it upon himself to make it > happen ;-). Well, I hope he's not so eager to do so that he does it before this licensing thing is hammered out. :-) I think having contrib is a very good idea, but that's only *because* it currently allows non-BSD licenses. Take that away, and I think you've taken away the entire purpose for contrib (versus simply including something in the main source tree with a configure switch to enable/disable it). > There are a number of reasons to keep things in contrib. One is that > the code may be too tightly tied to backend innards to be appropriate to > maintain separately (the GIST extension modules are a good example, and > most of the modules that include server-side code are easier to maintain > with the server than not). Shouldn't this stuff (if we decide to make contrib BSD-only) become part of the main source tree, then, with a configure option to enable/disable it at compile time? > Another is that small modules may not have > enough critical mass to get maintained at all, if they're kicked out to > live or die on their own. That's certainly a problem, but only if the modules are also tightly tied to the backend. But then, does that mean that anything which is strongly tied to the backend must be included in contrib, no matter how unpopular? Aside from that and licensing, what other criteria would you use to decide on such inclusion? > > Otherwise, perhaps you're more concerned about the licensing issues in > > contrib than you need to be? > > The way I see it, the "only BSD stuff in contrib" rule is designed > precisely to save us from having to think too hard about licensing > issues. I'm not interested in getting into lawyeristic arguments > about how it's okay to distribute something with a different license > if only we don't do XYZ with it. Yeah, but what I'm saying is that *we* don't have to think about this lawyeristic stuff regardless. All we have to care about is whether or not the contrib item in question has a license that allows source distribution. The rest of it is a problem for whoever wants to build binary distributions, and such people *already* know what the issues are and know that they have to think about them. The only case where that might not be true is the case of the individual who is building a binary distribution for use within his own group. But such a person is easily covered by simply disabling compilation of contrib by default. If he has to go to the trouble of enabling that explicitly, then he can be warned that the stuff in contrib might be covered by a different license. But such a person is likely to be in a role where he's had to deal with licensing issues elsewhere, so it's more likely than not that he'll be aware of such things. The only thing he needs to be made aware of is that contrib contains items that fall under different licenses. That alone isn't, IMO, justification for removing non-BSD items from contrib. So in the end, keeping contrib BSD-only doesn't help *us*, it only helps the people who build binary distributions. But because they're already used to dealing with the problem, they don't need our help on this. And that means that kicking non-BSD stuff out of contrib doesn't really help anyone very much, if any...but it does hurt us in that some potentially very valuable things will no longer be considered for inclusion in the distribution. So from here it looks like there's more (perhaps much more) to be lost by making contrib BSD-only than there is to be gained. It would be one thing if we had a lot of people clamoring for removal of non-BSD stuff from contrib because they'd actually been burned by licensing issues. But I haven't seen anything to that effect on this list, at least, and we've had at least one GPL item in there (pgcrypto) since late 2000. -- Kevin Brown kevin@sysexperts.com
Kevin Brown wrote: > So in the end, keeping contrib BSD-only doesn't help *us*, it only > helps the people who build binary distributions. But because they're > already used to dealing with the problem, they don't need our help on > this. Well, professional distributers are used to deal with licensing issues. What about all those nice guys who just build unofficial RPM's of software for their favorite plattform, so other's don't have to? Now they whould have a problem with including contrib stuff. Just a thought. Regards, Michael Paesold
Kevin Brown kirjutas E, 07.04.2003 kell 04:39: > > And that means that kicking non-BSD stuff out of contrib doesn't > really help anyone very much, if any...but it does hurt us in that > some potentially very valuable things will no longer be considered for > inclusion in the distribution. So from here it looks like there's > more (perhaps much more) to be lost by making contrib BSD-only than > there is to be gained. The current move-everything-possible-out-of-contrib seems to be motivated by "less is more" philosophy, i.e. the standard tarball / cvs update is considered too big. Licensing is used as additional guideline, partly because of fear of some licenses being viral. > > > It would be one thing if we had a lot of people clamoring for removal > of non-BSD stuff from contrib because they'd actually been burned by > licensing issues. If licensing is a non-issue then it is be easy to change the license ;) > > But I haven't seen anything to that effect on this > list, at least, and we've had at least one GPL item in there > (pgcrypto) since late 2000. I guess this is also being moved to gborg. ------------- Hannu