Обсуждение: contrib/pg_filedump - PostgreSQL File Dump Utility
Hi, Coded up a utility, pg_filedump, to dump out PostgreSQL heap/index/control files in a human-readable form (hex, ascii, interpreted). The attached tarball contains the source, makefile and readme. I've found the utility quite handy when you have to go digging in the raw blocks for information. pg_filedump has been tested on: 1. Red Hat Linux 7.2 / 7.1 2. SunOS 5.7 Generic_106541-17 3. FreeBSD 4.2-RELEASE #0 4. CYGWIN_NT-4.0 1.2.0(0.26/3/2) Cheers, Patrick ----------------- Patrick Macdonald Red Hat Database
Вложения
Patrick Macdonald writes: > Coded up a utility, pg_filedump, to dump out PostgreSQL > heap/index/control files in a human-readable form (hex, > ascii, interpreted). Wrong license. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > > Patrick Macdonald writes: > > > Coded up a utility, pg_filedump, to dump out PostgreSQL > > heap/index/control files in a human-readable form (hex, > > ascii, interpreted). > > Wrong license. Hmmm... I was under the impression that contributed code that resides in the /contrib directory could be licensed under GPL. Patrick
Patrick Macdonald <patrickm@redhat.com> writes:
> Hmmm... I was under the impression that contributed code
> that resides in the /contrib directory could be licensed
> under GPL.
We'd prefer BSD, though. The existing contrib modules that are
GPL-licensed snuck in there by virtue of people not paying attention.
I'd kinda like to see us go back to the contributors and get them
all relicensed as BSD (or at the very least LGPL). I think that
distributing these as we do is only marginally legit --- it's
debatable whether this is "mere aggregation" under the terms
of the GPL, given that the contrib modules are fairly closely
bound to the rest of the distribution.
regards, tom lane
Tom Lane wrote: > > Patrick Macdonald <patrickm@redhat.com> writes: > > Hmmm... I was under the impression that contributed code > > that resides in the /contrib directory could be licensed > > under GPL. > > We'd prefer BSD, though. The existing contrib modules that are > GPL-licensed snuck in there by virtue of people not paying attention. Understood and from a Steering Committee perspective it makes sense to attempt to have all code associated with the project under one license. However this contribution is part of another project, the Red Hat Database Project, that uses GPL as its license. All tools and utilities that we are developing including the Administrator, Browser and Visual Explain will be issued under GPL (where possible). All work performed by the RHDB development team on PostgreSQL proper falls under the existing PostgreSQL license(s). Cheers, Patrick ----------------- Patrick Macdonald Red Hat Database
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> A larger issue is that this code wants to be in contrib. I don't see
> any other GPL code in contrib.
You didn't look very hard then; a grep for 'General Public License' finds
contrib/array/README.array_iterator: This software is distributed under the GNU General Public License
contrib/array/array_iterator.c: * This software is distributed under the GNU General Public License
contrib/miscutil/misc_utils.c: * This file is distributedunder the GNU General Public License
contrib/miscutil/README.misc_utils: This software is distributed under the GNU General Public License
contrib/miscutil/misc_utils.sql.in: -- This file is distributed under the GNU General Public License
contrib/string/string_io.c: * This software is distributed under the GNU General Public License
contrib/string/README.string_io: This software is distributed under the GNU General Public License
contrib/string/string_io.sql.in: -- This file is distributed under the GNU General Public License
contrib/tools/find-sources: # it under the terms of the GNU General Public License as published by
contrib/tools/find-sources: # GNU General Public License for more details.
contrib/tools/find-sources: # You should have received a copy of the GNU General Public License
contrib/tsearch/dict/porter_english.dct: * modify it under the terms of the GNU General Public License as
contrib/tsearch/dict/porter_english.dct: * GNU General Public License for more details.
contrib/tsearch/dict/porter_english.dct: * You should have received a copy of the GNU General Public License
contrib/userlock/user_locks.c: * This software is distributed under the GNU General Public License
contrib/userlock/README.user_locks: This software is distributed under the GNU General Public License
contrib/userlock/user_locks.sql.in: -- This file is distributed under the GNU General Public License
as well as hits in ODBC, some autoconf input files, and flex and bison
output files. The autoconf/flex/bison hits are not a problem because
those have special exemption clauses in their licenses. And ODBC uses
LGPL, which doesn't have the "viral" properties of GPL, so it's not a
threat to the rest of our distribution.
I do have concerns about including these six contrib modules in our
distribution, however. It could be argued that the terms of the GPL
forbid that.
regards, tom lane
> > We'd prefer BSD, though. The existing contrib modules that are > > GPL-licensed snuck in there by virtue of people not paying attention. > > Understood and from a Steering Committee perspective it makes > sense to attempt to have all code associated with the project > under one license. > > However this contribution is part of another project, the Red Hat > Database Project, that uses GPL as its license. All tools and > utilities that we are developing including the Administrator, > Browser and Visual Explain will be issued under GPL (where possible). > > All work performed by the RHDB development team on PostgreSQL > proper falls under the existing PostgreSQL license(s). At first I thought this linked into the main PostgreSQL backend code, but actually it just reads tuple lengths, and optionally dumps out the data in hex. There doesn't seem to be any _smarts_ in reading the tuple information, so its linkage to the backend its limited to pg_crc.c. I don't see an issue with that linkage because if Patrick's code is GPL anyway, linking to a BSD file doesn't change the nature of GPL at all. I is only BSD linking to GPL code that changes the code to GPL. If it is already GPL, I don't see an issue. A larger issue is that this code wants to be in contrib. I don't see any other GPL code in contrib. I see pgcrypto using an LGPL library(?), and our odbc is LGPL'ed, and I can even find a mention of Peter Mount not including retepPDF because it was LGPL'ed. Now, I don't think it is an issue because retepPDF had other questionable issues Peter mentioned, but it does show that contributors have tried to be consistent with our current license. I guess I am concerned about going down the slippery slope where people have to scour the source tree and study every licensed piece. I know we have LGPL in our code. I don't know how different that is from the BSD license, and whether adding pure-GPL code into our tree is a wise move. Patrick, are the other projects you mentioned destined for our source tree too? --- Administrator, Browser and Visual Explain One unusual issue is that our python interface library is described as GPL-like. What does that mean? I don't see any actual license description. I am CC'ing the author. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > A larger issue is that this code wants to be in contrib. I don't see > > any other GPL code in contrib. > > You didn't look very hard then; a grep for 'General Public License' finds > Yea, I looked only for GPL, not the longer string. Good find. > as well as hits in ODBC, some autoconf input files, and flex and bison > output files. The autoconf/flex/bison hits are not a problem because > those have special exemption clauses in their licenses. And ODBC uses > LGPL, which doesn't have the "viral" properties of GPL, so it's not a > threat to the rest of our distribution. > > I do have concerns about including these six contrib modules in our > distribution, however. It could be argued that the terms of the GPL > forbid that. Yes, I see your point. We better figure out what we need to do, if anything, and do it. I don't see any key pieces in that listing. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Tom Lane writes: > I do have concerns about including these six contrib modules in our > distribution, however. It could be argued that the terms of the GPL > forbid that. That is one thing. Another concern is that it confuses the general public. People have certain expectations when it comes to PostgreSQL code, and if every little subdirectory has its own license it just becomes annoying. -- Peter Eisentraut peter_e@gmx.net
Hi Peter, Do you mind re-licensing this with the BSD license for us? :-) Regards and best wishes, Justin Clift Peter Eisentraut wrote: > > Tom Lane writes: > > > I do have concerns about including these six contrib modules in our > > distribution, however. It could be argued that the terms of the GPL > > forbid that. > > That is one thing. Another concern is that it confuses the general > public. People have certain expectations when it comes to PostgreSQL > code, and if every little subdirectory has its own license it just becomes > annoying. > > -- > Peter Eisentraut peter_e@gmx.net > > ---------------------------(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 -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
> If you want to produce something based on PG, under another license, please > distribute it separately. If it's sufficiently useful (like a full suite > from RH), then I'll make my standard policy to validate a PG version, > then validate your suite, then make it the standard for my organization. One bizarre idea is to create a /contrib/GPL and put the GPL stuff in there. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
In following this thread, one question that was raised in my mind is what is the intended purpose of the contrib directory? I had thought that the purpose was as a place to put code that was experimental, or not stable enough to be in the main tree, but would someday when it matures get included into the main tree. Obviousely if there are different licenses this code couldn't ever be in the main tree. Is contrib then just a dumping ground of code related to the postgresql server (a kind of sourceforge for postgres)? I am sure the answer to that question is no. But then I really don't understand what should or should not be in contrib. thanks, --Barry Peter Eisentraut wrote: > Tom Lane writes: > > >>I do have concerns about including these six contrib modules in our >>distribution, however. It could be argued that the terms of the GPL >>forbid that. >> > > That is one thing. Another concern is that it confuses the general > public. People have certain expectations when it comes to PostgreSQL > code, and if every little subdirectory has its own license it just becomes > annoying. > >
On Wed, 2002-02-06 at 21:20, Barry Lind wrote: > I had thought > that the purpose was as a place to put code that was experimental, or > not stable enough to be in the main tree, but would someday when it > matures get included into the main tree. If by "main tree" you mean the main CVS repository, then that is where contrib/ is currently. If by "main tree" you mean "the core PostgreSQL install", then no -- because the contents of contrib/ are typically add-ons, extensions or utilities relating to the core function of an RDBMS. I'm not aware of any plans to install any of the contrib/ stuff by default -- if you inspect the contents of contrib/, this should be pretty obvious. > Is > contrib then just a dumping ground of code related to the postgresql > server (a kind of sourceforge for postgres)? Somewhat (AFAIK): contrib/ is user-contributed software relating to PostgreSQL. It's not like Sourceforge, though. > I am sure the answer to that question is no. I'm not :-) Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
Neil Conway wrote: > On Wed, 2002-02-06 at 21:20, Barry Lind wrote: > > I had thought > > that the purpose was as a place to put code that was experimental, or > > not stable enough to be in the main tree, but would someday when it > > matures get included into the main tree. > > If by "main tree" you mean the main CVS repository, then that is where > contrib/ is currently. > > If by "main tree" you mean "the core PostgreSQL install", then no -- > because the contents of contrib/ are typically add-ons, extensions or > utilities relating to the core function of an RDBMS. I'm not aware of > any plans to install any of the contrib/ stuff by default -- if you > inspect the contents of contrib/, this should be pretty obvious. /contrib is for porting tools, analysis tools, and stuff the plugs into the database, like user-defined types; at least that is the rule we have used in the past. It is sometimes for stuff that will eventually be moved into the main tree, but not exclusively. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Oops,
I meant Patrick. Sorry about that guys.
Not enough coffee.
:(
Regards and best wishes,
Justin Clift
Justin Clift wrote:
>
> Hi Peter,
>
> Do you mind re-licensing this with the BSD license for us?
>
> :-)
>
> Regards and best wishes,
>
> Justin Clift
>
> Peter Eisentraut wrote:
> >
> > Tom Lane writes:
> >
> > > I do have concerns about including these six contrib modules in our
> > > distribution, however. It could be argued that the terms of the GPL
> > > forbid that.
> >
> > That is one thing. Another concern is that it confuses the general
> > public. People have certain expectations when it comes to PostgreSQL
> > code, and if every little subdirectory has its own license it just becomes
> > annoying.
> >
> > --
> > Peter Eisentraut peter_e@gmx.net
> >
> > ---------------------------(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
>
> --
> "My grandfather once told me that there are two kinds of people: those
> who work and those who take the credit. He told me to try to be in the
> first group; there was less competition there."
> - Indira Gandhi
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Bruce Momjian wrote: > <snip> > Yes, I see your point. We better figure out what we need to do, if > anything, and do it. I don't see any key pieces in that listing. If we ask each of the authors (there doesn't seem to be very many) of these GPL'd modules to please either change to BSD or to grant PostgreSQL a special BSD licensed version, and they agree, would we have a problem still? :-) Regards and best wishes, Justin Clift > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Justin Clift wrote: > Bruce Momjian wrote: > > > <snip> > > Yes, I see your point. We better figure out what we need to do, if > > anything, and do it. I don't see any key pieces in that listing. > > If we ask each of the authors (there doesn't seem to be very many) of > these GPL'd modules to please either change to BSD or to grant > PostgreSQL a special BSD licensed version, and they agree, would we have > a problem still? That certainly would be an ideal solution. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Hi All, Seems that I opened up a interesting can of worms with my little submission. I guess sooner or later it was going to happen. Anyway... as I mentioned before, the utility is part of the RHDB Tools/Utility component. Red Hat's preferred license is GPL and as such, the utility is licensed under GPL as it is not part of PostgreSQL proper. I found the utility handy while looking at data problems and thought other developers would too. When looking at the contrib directory, I noted that there where GPL contributions and I couldn't find a disclaimer that all contributions had to be BSD. So, I sent it in for consideration. For what it's worth, I think the best route to take is as follows: . Reject/withdraw my contrib request (I will make it available to the community at http://sources.redhat.com/rhdb) . Have the Steering Committee decide whether all contrib packages have to adhere to the BSD license. . If they do, ask the contributors to re-license under BSD. For those that refuse, remove them from the contrib directory. . If contrib doesn't require BSD, I'll resubmit. . Display the decision on the contrib section of the website so we don't have to spend time spinning on this issue again. Cheers, Patrick Justin Clift wrote: > > Hi Peter, > > Do you mind re-licensing this with the BSD license for us? > > :-) > > Regards and best wishes, > > Justin Clift > > Peter Eisentraut wrote: > > > > Tom Lane writes: > > > > > I do have concerns about including these six contrib modules in our > > > distribution, however. It could be argued that the terms of the GPL > > > forbid that. > > > > That is one thing. Another concern is that it confuses the general > > public. People have certain expectations when it comes to PostgreSQL > > code, and if every little subdirectory has its own license it just becomes > > annoying. > > > > -- > > Peter Eisentraut peter_e@gmx.net > > > > ---------------------------(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 > > -- > "My grandfather once told me that there are two kinds of people: those > who work and those who take the credit. He told me to try to be in the > first group; there was less competition there." > - Indira Gandhi > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Patrick Patrick Macdonald Red Hat Canada
Barry Lind <barry@xythos.com> writes:
> In following this thread, one question that was raised in my mind is
> what is the intended purpose of the contrib directory?
In my mind it's stuff that's not ready for prime time, but might be
useful as-is to at least some people.
> I had thought
> that the purpose was as a place to put code that was experimental, or
> not stable enough to be in the main tree, but would someday when it
> matures get included into the main tree.
Make that "if it matures". There's no implication that contrib stuff
will ever reach that state; in fact, if it seemed close to being ready
it'd very likely have got put in the main tree to begin with...
regards, tom lane
On Thu, 7 Feb 2002, Justin Clift wrote: > Bruce Momjian wrote: > > > <snip> > > Yes, I see your point. We better figure out what we need to do, if > > anything, and do it. I don't see any key pieces in that listing. > > If we ask each of the authors (there doesn't seem to be very many) of > these GPL'd modules to please either change to BSD or to grant > PostgreSQL a special BSD licensed version, and they agree, would we have > a problem still? Would such a special BSD licensed version be usable by all? One of the nice things about the BSD license is that a company can come along and build products based off of it. If there is a special exception given to Postgres, would it apply to such companies coming along and using the code? If not, is it really that much better than the code being GPL'd? Take care, Bill
On Wed, 6 Feb 2002, Tom Lane wrote: > I'd kinda like to see us go back to the contributors and get them > all relicensed as BSD (or at the very least LGPL). I think that > distributing these as we do is only marginally legit --- it's > debatable whether this is "mere aggregation" under the terms > of the GPL, given that the contrib modules are fairly closely > bound to the rest of the distribution. I think the big question is, "does the main distribution (backend, libpq, etc.) depend on the GPL'd bits being there?" As I think the anser is no, then there is no GPL issue. The GPL'd code can be tied to non-GPL'd code in other programs. As another example, it is specifically ok for the *BSDs to ship GPL'd kernel modules, as the bound result (dynamic linking) doesn't get distributed. A niggle might be if libpq or one of the other libraries had a GPL-incompatable license (like BSD with advertizing clause) and was statically linked into a binary produced from contrib. Such a resulting binary would probably be in the you-can't-distribute category. But the COPYRIGHT at the top of the source tree doesn't have an advertizing clause, so this problem really isn't. :-) Take care, Bill
Bill Studenmund writes: > > If we ask each of the authors (there doesn't seem to be very many) of > > these GPL'd modules to please either change to BSD or to grant > > PostgreSQL a special BSD licensed version, and they agree, would we have > > a problem still? > > Would such a special BSD licensed version be usable by all? One of the > nice things about the BSD license is that a company can come along and > build products based off of it. If there is a special exception given to > Postgres, would it apply to such companies coming along and using the > code? If not, is it really that much better than the code being GPL'd? Actually, I have a mildly amusing theory about this: Open-source licenses are mainly about what you can distribute and how. So if party A gives party B a "special exception" to the license of product P produced by A, then A has really lost all control, because B now has been given the right to distribute P under open-source terms. Concrete case: The config.guess script contained in the PostgreSQL source tree contains this notice: # As a special exception to the GNU General Public License, if you # distribute this file as part of a program that contains a # configuration script generated by Autoconf, you may include it under # the same distribution terms that you use for the rest of that program. Since the premise of this condition is fulfilled, we may include config.guess under the BSD license. The BSD license says, "Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted", which means that *anyone* obtaining a copy of the PostgreSQL source tree can take the config.guess and redistribute it under BSD-compatible terms. So, exceptions work, but just not the way the grantor and the recipient think. -- Peter Eisentraut peter_e@gmx.net
On Fri, 8 Feb 2002, Peter Eisentraut wrote: > Actually, I have a mildly amusing theory about this: > > Open-source licenses are mainly about what you can distribute and how. So > if party A gives party B a "special exception" to the license of product P > produced by A, then A has really lost all control, because B now has been > given the right to distribute P under open-source terms. I think it would depend on the wording of the exception. > Concrete case: The config.guess script contained in the PostgreSQL source > tree contains this notice: > > # As a special exception to the GNU General Public License, if you > # distribute this file as part of a program that contains a > # configuration script generated by Autoconf, you may include it under > # the same distribution terms that you use for the rest of that program. > > Since the premise of this condition is fulfilled, we may include > config.guess under the BSD license. The BSD license says, "Permission to > use, copy, modify, and distribute this software and its documentation for > any purpose, without fee, and without a written agreement is hereby > granted", which means that *anyone* obtaining a copy of the PostgreSQL > source tree can take the config.guess and redistribute it under > BSD-compatible terms. > > So, exceptions work, but just not the way the grantor and the recipient > think. Heh. I definitly agree with you here. If the exceptions looked like the one above, there would be no problem. :-) Take care, Bill