Обсуждение: Re: [GENERAL] pg_filedump binary for CentOS
David Boreham wrote: > > As far as I can see there is no pre-built pg_filedump binary for the > PDGD yum repository (8.3.11 for RHEL5). Before I embark on building it > from source I figured I'd ask here if I'm correct that there is no > binary hidden somewhere in the packages. [ CC to hackers.] Should we consider moving pg_filedump into our /contrib? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Thu, Oct 14, 2010 at 12:41 PM, Bruce Momjian <bruce@momjian.us> wrote: > David Boreham wrote: >> >> As far as I can see there is no pre-built pg_filedump binary for the >> PDGD yum repository (8.3.11 for RHEL5). Before I embark on building it >> from source I figured I'd ask here if I'm correct that there is no >> binary hidden somewhere in the packages. > > [ CC to hackers.] > > Should we consider moving pg_filedump into our /contrib? If it's license-compatible, +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Excerpts from Robert Haas's message of jue oct 14 14:10:57 -0300 2010: > On Thu, Oct 14, 2010 at 12:41 PM, Bruce Momjian <bruce@momjian.us> wrote: > > David Boreham wrote: > >> > >> As far as I can see there is no pre-built pg_filedump binary for the > >> PDGD yum repository (8.3.11 for RHEL5). Before I embark on building it > >> from source I figured I'd ask here if I'm correct that there is no > >> binary hidden somewhere in the packages. > > > > [ CC to hackers.] > > > > Should we consider moving pg_filedump into our /contrib? > > If it's license-compatible, +1. It is GPL, which strictly speaking is compatible, but we don't want to ship it to avoid problems for downstream packagers. Could we ask Redhat for a relicense? -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Bruce Momjian <bruce@momjian.us> writes:
> Should we consider moving pg_filedump into our /contrib?
Can't: it's GPL.
regards, tom lane
On Thu, Oct 14, 2010 at 05:53:30PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Should we consider moving pg_filedump into our /contrib? > > Can't: it's GPL. Depends on whether we can get it relicensed. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On Thu, Oct 14, 2010 at 2:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Bruce Momjian <bruce@momjian.us> writes: >> Should we consider moving pg_filedump into our /contrib? > > Can't: it's GPL. > I don't particularly see a problem with having GPL'd contrib modules. It would mean any users hoping to redistribute the package couldn't include those modules except under the GPL. But most repackagers don't include the contrib modules anyways. Even ones that do and want to include those modules would only have to include the source to that module. I can see not wanting to let that camel's nose in for fear of having packagers always be uncertain about the status of each contrib module though. -- greg
On Fri, Oct 15, 2010 at 2:36 AM, Greg Stark <gsstark@mit.edu> wrote: > On Thu, Oct 14, 2010 at 2:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Bruce Momjian <bruce@momjian.us> writes: >>> Should we consider moving pg_filedump into our /contrib? >> >> Can't: it's GPL. >> > > I don't particularly see a problem with having GPL'd contrib modules. > It would mean any users hoping to redistribute the package couldn't > include those modules except under the GPL. But most repackagers don't > include the contrib modules anyways. Even ones that do and want to > include those modules would only have to include the source to that > module. > > I can see not wanting to let that camel's nose in for fear of having > packagers always be uncertain about the status of each contrib module > though. I think that's a bad idea for all kinds of reasons. For one thing, it seems that someone could easily end up copying some of that code into some other place. It would be *nice* to have this available as part of our regular distribution but I don't want to take any risk of GPL contamination. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 10/15/2010 7:24 AM, Robert Haas wrote: > I think that's a bad idea for all kinds of reasons. For one thing, it > seems that someone could easily end up copying some of that code into > some other place. It would be *nice* to have this available as part > of our regular distribution but I don't want to take any risk of GPL > contamination. I think there's a tendency to assume that one license rules them all within a single package, tarball etc. Just wondering what was the motivation to GPL this code ? I mean, if I were to write a utility that was only useful for project X, I'd want to license my code with the same (or a compatible) license as X. I'd need a really good reason to use a different license.
On 10/15/2010 02:36 AM, Greg Stark wrote: > On Thu, Oct 14, 2010 at 2:53 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: >> Bruce Momjian<bruce@momjian.us> writes: >>> Should we consider moving pg_filedump into our /contrib? >> Can't: it's GPL. >> > I don't particularly see a problem with having GPL'd contrib modules. > It would mean any users hoping to redistribute the package couldn't > include those modules except under the GPL. But most repackagers don't > include the contrib modules anyways. Even ones that do and want to > include those modules would only have to include the source to that > module. > > I can see not wanting to let that camel's nose in for fear of having > packagers always be uncertain about the status of each contrib module > though. Didn't we go through the exercise of removing modules that were GPLed a few years ago? Having a plethora of different licenses covering code in our repository seems like a recipe for major confusion, and I think is to be avoided. cheers andrew
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Oct 15, 2010 at 2:36 AM, Greg Stark <gsstark@mit.edu> wrote:
>> I don't particularly see a problem with having GPL'd contrib modules.
> I think that's a bad idea for all kinds of reasons.
Yeah. From my viewpoint as a downstream packager, it creates a mess.
We've spent a great amount of effort and cajolery over the years to make
sure that the Postgres sources, including contrib, are uniformly
licensed. We're not going to abandon that policy.
I have no idea whether Red Hat could be persuaded to relicense
pg_filedump. It might be worth asking though.
regards, tom lane
David Boreham <david_list@boreham.org> writes:
> Just wondering what was the motivation to GPL this code ?
It was written at Red Hat and they have (or at least had at the time)
a company policy of using GPL for any code written in-house.
regards, tom lane
Greg Stark wrote: > On Thu, Oct 14, 2010 at 2:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Bruce Momjian <bruce@momjian.us> writes: > >> Should we consider moving pg_filedump into our /contrib? > > > > Can't: it's GPL. > > > > I don't particularly see a problem with having GPL'd contrib modules. > It would mean any users hoping to redistribute the package couldn't > include those modules except under the GPL. But most repackagers don't > include the contrib modules anyways. Even ones that do and want to > include those modules would only have to include the source to that > module. > > I can see not wanting to let that camel's nose in for fear of having > packagers always be uncertain about the status of each contrib module > though. I think we should just link to the tool from our docs so there is no license complexity. Where do we add it? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +