contrib/pg_filedump - PostgreSQL File Dump Utility

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

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

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

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

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:

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

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

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

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

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