Re: [CORE] GPL Source and Copyright Questions

item #2: Is dllinit.c GPL code?
The file dllinit.c, located in the src/utils directory

documents the

author as Mumit Khan. Did Mumit Khan contribute this code

and did he

contribute it for distribution under the PostgreSQL license? If I
read correctly, the name stamp in CVS does not indicate that Mumit
Khan directly contributed this file. I ask because this

question has

surfaced as a forum item for a different project and Mumit Khan
directly answered their forum posting

(http://curl.haxx.se/mail/lib-2002-11/0061.html).

Per the comments in that thread, it would be pretty trivial
to either rewrite or remove this file. I don't think there
is anything there that amounts to protectable content (and
Mumit evidently agrees, see link) but let's do something
about it anyway. Can some of the Windows folk check whether
we can just remove it?

I don't think it's needed on Win32. It's not included in my VC++ build,
because I forgot it :-), and it works just fine.

The point is that as long as we don't do anything in it (which we
don't), the runtime supplied default should be just fine.

I can't speak for cygwin, just standard win32.

//Magnus

Tom,

Augh. Does this mean that we need to "backpatch" earlier versions to remove
the possible GPL links?

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

"Magnus Hagander" <mha@sollentuna.net> writes:

item #2: Is dllinit.c GPL code?

I don't think it's needed on Win32. It's not included in my VC++ build,
because I forgot it :-), and it works just fine.
The point is that as long as we don't do anything in it (which we
don't), the runtime supplied default should be just fine.
I can't speak for cygwin, just standard win32.

The part of it that seems not to be a no-op is

#ifdef __CYGWIN__
__hDllInstance_base = hInst;
#endif /* __CYGWIN__ */

#ifdef __CYGWIN__
_impure_ptr = __imp_reent_data;
#endif

and the whole thing is wrapped in

#if CYGWIN_VERSION_DLL_MAJOR < 1001

so presumably this is only needed for old Cygwin versions. Can anyone
say how old "1001" is and whether we still ought to care about it?

regards, tom lane

Josh Berkus <josh@agliodbs.com> writes:

Augh. Does this mean that we need to "backpatch" earlier versions to remove
the possible GPL links?

[ shrug... ] I'm not planning to panic; we've still got explicit GPL
code that's not been cleaned out of contrib/ yet. (Um, weren't you on
the hook to move those modules to pgfoundry projects?)

I think we should endeavor to clean up any license questions going
forward, but it's useless to worry about the back branches; they are
what they are, and anyone who actually wants to sue us could do so
anyway on the strength of releases already out there.

regards, tom lane

Tom,

[ shrug... ] I'm not planning to panic; we've still got explicit GPL
code that's not been cleaned out of contrib/ yet. (Um, weren't you on
the hook to move those modules to pgfoundry projects?)

Yeah, thanks for reminding me. Will do before feature freeze. As soon as
I can figure out how to generate a patch that removes directories.

I think we should endeavor to clean up any license questions going
forward, but it's useless to worry about the back branches; they are
what they are, and anyone who actually wants to sue us could do so
anyway on the strength of releases already out there.

Hmmm ... I don't know. I'd be in favor of providing patches in case people
care enough to fix the issue. Maybe not until the next general patch
release, but with that.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

so presumably this is only needed for old Cygwin versions. Can anyone
say how old "1001" is and whether we still ought to care about it?

IIRC, I've been on 1.5.x for at least three years. 1.0/1.1 seems to be
around 2000/2001, based on a quick Google. So it's definitely older than
PG 7.3.

Regards,
Paul Bort

Josh Berkus <josh@agliodbs.com> writes:

Yeah, thanks for reminding me. Will do before feature freeze. As soon as
I can figure out how to generate a patch that removes directories.

Don't worry about that; CVS never deletes directories. But anyway,
I can easily handle removing the code. I just want someone else to
stuff it into pgfoundry, because I'm not up to speed on pgfoundry.

I believe the current hit-list for modules to move to pgfoundry is

adddepend
dbase
dbmirror
fulltextindex
mSQL-interface
mac
oracle
tips
userlock

regards, tom lane

Tom,

adddepend
dbase
dbmirror
fulltextindex
mSQL-interface
mac
oracle
tips
userlock

I think you're right. I will do this before I leave town on the 30th.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

Tom Lane wrote:

Josh Berkus <josh@agliodbs.com> writes:

Yeah, thanks for reminding me. Will do before feature freeze. As soon as
I can figure out how to generate a patch that removes directories.

Don't worry about that; CVS never deletes directories. But anyway,
I can easily handle removing the code. I just want someone else to
stuff it into pgfoundry, because I'm not up to speed on pgfoundry.

I believe the current hit-list for modules to move to pgfoundry is

adddepend
dbase
dbmirror
fulltextindex
mSQL-interface
mac
oracle
tips
userlock

one thing to note is that at least on IRC we are still getting a notable
number of questions about fixing up constraint triggers left over from
importing dumps of old pg versions.
The usual answer to that is "try contrib/adddepend" - but i guess
redirecting them to pgfoundry will work too.

Stefan

Bort, Paul wrote:

so presumably this is only needed for old Cygwin versions. Can anyone
say how old "1001" is and whether we still ought to care about it?

IIRC, I've been on 1.5.x for at least three years. 1.0/1.1 seems to be
around 2000/2001, based on a quick Google. So it's definitely older than
PG 7.3.

1.3 was announced in May 2001 according to the cygwin announce mailing
list archives, so I think we can safely ignore the section in question.
If anyone hasn't upgraded their cygwin since then they probably have
more problems than this would give them.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Bort, Paul wrote:

so presumably this is only needed for old Cygwin versions. Can anyone
say how old "1001" is and whether we still ought to care about it?

IIRC, I've been on 1.5.x for at least three years. 1.0/1.1 seems to be
around 2000/2001, based on a quick Google. So it's definitely older than
PG 7.3.

1.3 was announced in May 2001 according to the cygwin announce mailing
list archives, so I think we can safely ignore the section in question.

OK, so let's yank the file altogether and see what happens.

I can make a cut at fixing the makefiles based on removing references to
DLLINIT, but it might be better if someone who's in a position to test
the results on Windows did the patch ...

regards, tom lane

Tom Lane wrote:

Charles Comiskey <comiskey@us.ibm.com> writes:

item #3: Carsten Wolff copyright in informix.c file
The file informix.c contains a copyright from Carsten Wolff. Did Carsten
directly contribute this file to the PostgreSQL project?

Wow, I see what mess we would be into if we had retained the per-person
copyright message on each file.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Josh Berkus wrote:

Tom,

adddepend
dbase
dbmirror
fulltextindex
mSQL-interface
mac
oracle
tips
userlock

I think you're right. I will do this before I leave town on the 30th.

before anyone asks, the files I wrote in contrib/mac are free to be licensed
any way the
project sees fit.

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: ler@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893

Tom Lane wrote:

OK, so let's yank the file altogether and see what happens.

I can make a cut at fixing the makefiles based on removing references to
DLLINIT, but it might be better if someone who's in a position to test
the results on Windows did the patch ...

Something has broken Cygwin in the last 18 days ;-(

See
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gibbon&amp;dt=2006-06-22%2021:59:16

I will have a look to see if 8.1 works with ripping this out.

cheers

andrew

Andrew Dunstan wrote:

Tom Lane wrote:

OK, so let's yank the file altogether and see what happens.

I can make a cut at fixing the makefiles based on removing references to
DLLINIT, but it might be better if someone who's in a position to test
the results on Windows did the patch ...

Something has broken Cygwin in the last 18 days ;-(

See
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gibbon&amp;dt=2006-06-22%2021:59:16

I will have a look to see if 8.1 works with ripping this out.

On REL8_1_STABLE sources commenting out the DLLINIT definition in
Makefile.cygwin works just fine. Same goes for
Win32/HEAD/Makefile.win32. I just did complete (unreported) buildfarm
run with these changes made, so I think ripping that out should work.

Meanwhile, I'd like to know how to fix the Cygwin build on HEAD. I
suspect it was the MSVC "improvements" that did it.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

On REL8_1_STABLE sources commenting out the DLLINIT definition in
Makefile.cygwin works just fine. Same goes for
Win32/HEAD/Makefile.win32. I just did complete (unreported) buildfarm
run with these changes made, so I think ripping that out should work.

OK, I'll do that.

Meanwhile, I'd like to know how to fix the Cygwin build on HEAD. I
suspect it was the MSVC "improvements" that did it.

Probably. This is the commit:

2006-06-07 18:24 momjian

* configure, configure.in, src/backend/libpq/ip.c,
src/backend/port/dynloader/win32.c,
src/backend/port/win32/Makefile,
src/backend/postmaster/postmaster.c,
src/backend/postmaster/syslogger.c, src/backend/utils/adt/float.c,
src/backend/utils/fmgr/dfmgr.c, src/backend/utils/mb/encnames.c,
src/bin/initdb/initdb.c, src/bin/pg_controldata/pg_controldata.c,
src/bin/pg_ctl/pg_ctl.c, src/bin/pg_dump/pg_backup_archiver.c,
src/bin/pg_dump/pg_backup_db.c, src/bin/pg_dump/pg_backup_null.c,
src/bin/pg_dump/pg_backup_tar.c, src/bin/pg_dump/pg_dump.c,
src/bin/pg_dump/pg_dumpall.c, src/bin/pg_dump/pg_restore.c,
src/bin/pg_resetxlog/pg_resetxlog.c, src/bin/psql/command.c,
src/bin/psql/copy.c, src/bin/psql/print.c, src/bin/psql/win32.mak,
src/include/c.h, src/include/getaddrinfo.h,
src/include/pg_config.h.win32, src/include/port.h,
src/include/libpq/pqcomm.h, src/include/port/win32.h,
src/include/port/win32_msvc/dirent.h,
src/include/port/win32_msvc/unistd.h,
src/include/port/win32_msvc/utime.h,
src/include/port/win32_msvc/sys/file.h,
src/include/port/win32_msvc/sys/param.h,
src/include/port/win32_msvc/sys/time.h,
src/include/storage/s_lock.h, src/interfaces/libpq/fe-connect.c,
src/interfaces/libpq/fe-misc.c, src/interfaces/libpq/win32.c,
src/interfaces/libpq/win32.mak, src/port/dirent.c, src/port/exec.c,
src/port/getaddrinfo.c, src/port/inet_aton.c, src/port/thread.c,
src/port/win32error.c, src/timezone/localtime.c: Prepare code to be
built by MSVC:

o remove many WIN32_CLIENT_ONLY defines
o add WIN32_ONLY_COMPILER define
o add 3rd argument to open() for portability
o add include/port/win32_msvc directory for
system includes

Magnus Hagander

regards, tom lane

Tom Lane wrote:

Meanwhile, I'd like to know how to fix the Cygwin build on HEAD. I
suspect it was the MSVC "improvements" that did it.

Probably. This is the commit:

2006-06-07 18:24 momjian

[file list snipped]

Prepare code to be
built by MSVC:

o remove many WIN32_CLIENT_ONLY defines
o add WIN32_ONLY_COMPILER define
o add 3rd argument to open() for portability
o add include/port/win32_msvc directory for
system includes

Magnus Hagander

Yes.

Frankly this patch has significant infelicities. For example, what is
the reason for removing the standard protection against double inclusion
that header files should usually have from pg_config.h.win32?

I assume that no test was done to see if this broke Cygwin, despite the
fact that if you have a Windows box to test on, checking that you
haven't broken Cygwin should not be too difficult.. And why do win32 and
cygwin now not include at all pg_config_os.h?

I am not sure I know where to begin to look to find out how to fix
things, and I don't have the time to do it either.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Meanwhile, I'd like to know how to fix the Cygwin build on HEAD. I
suspect it was the MSVC "improvements" that did it.

The patch to c.h certainly had no compunction about possibly changing
the behavior for Cygwin:

***************
*** 82,94 ****
#endif

#if defined(WIN32) || defined(__CYGWIN__)
! #ifndef WIN32_CLIENT_ONLY
! /* We have to redefine some system functions after they are included above */
! #include "pg_config_os.h"
! #else
! #include "port/win32.h" /* We didn't run configure, but this is our
! * port file */
! #endif
#endif

  /* Must be before gettext() games below */
--- 80,90 ----
  #endif

#if defined(WIN32) || defined(__CYGWIN__)
! /* We have to redefine some system functions after they are included above.
! *
! * use port/win32.h directly to work on both mingw and non-mingw.
! */
! #include "port/win32.h"
#endif

/* Must be before gettext() games below */

I'm not too sure about the changes in getaddrinfo.c, either.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Meanwhile, I'd like to know how to fix the Cygwin build on HEAD. I
suspect it was the MSVC "improvements" that did it.

The patch to c.h certainly had no compunction about possibly changing
the behavior for Cygwin:

[snip]

I'm not too sure about the changes in getaddrinfo.c, either.

Maybe we need to divorce Cygwin and Win32.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Tom Lane wrote:

The patch to c.h certainly had no compunction about possibly changing
the behavior for Cygwin:

Maybe we need to divorce Cygwin and Win32.

That seems like probably an overreaction. The impression I got was that
this patch had actually moved the MSVC port quite a long way towards
being like the Cygwin port. It was just sloppy :-(.

Magnus, this was your patch, can you see about fixing the collateral
damage to the Cygwin build?

regards, tom lane

1) Is any John Franks code really in this file?

Possibly, maybe probably. I don't remember the details (9 years is a
long time!) but almost certainly any code or algorithms were
specifically for the "inside" or "outside" routines.

2) Did John provide a separate license for PostgreSQL to license it under
the BSD license?

Not explicitly that I can recall.

This code seems to have been inserted by Tom Lockhart on 1997-07-29
(geo_ops.c rev 1.13). Tom, any info on the copyright status?

None, beyond the info you already resurrected. I vaguely recall that I
did take the LJ letter as an invitation to reuse algorithms. I would
guess that I had possible licensing conflicts in mind so would have
tried to avoid them, but it would probably be best for someone to
evaluate that from the current code bases. I may have preserved the
Franks info for attribution of concepts to a specific person and version.

My (also vague) recollection is that the original Postgres algorithm was
just broken. I would suggest looking at the code, contacting J. Franks
if there are questions or a need for license clarification or
authorization, and finding an alternative algorithm if necessary.

hth

- Tom

Thomas Lockhart <lockhart@fourpalms.org> writes:

This code seems to have been inserted by Tom Lockhart on 1997-07-29
(geo_ops.c rev 1.13). Tom, any info on the copyright status?

None, beyond the info you already resurrected. I vaguely recall that I
did take the LJ letter as an invitation to reuse algorithms. I would
guess that I had possible licensing conflicts in mind so would have
tried to avoid them, but it would probably be best for someone to
evaluate that from the current code bases. I may have preserved the
Franks info for attribution of concepts to a specific person and version.

Thanks for answering, Tom. Charles, since you were the one interested,
maybe you could compare the geo_ops.c code to the Franks code and see
if it looks like Tom borrowed code or just the algorithms?

My (also vague) recollection is that the original Postgres algorithm was
just broken.

Yeah, I saw while tracing the CVS history that the code you replaced
defined "overlaps" as "bounding boxes overlap", which is surely not good
enough for polygons ;-)

I would suggest looking at the code, contacting J. Franks
if there are questions or a need for license clarification or
authorization, and finding an alternative algorithm if necessary.

The algorithms are probably public-domain, but we might need a
clean-room implementation :-(

regards, tom lane

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of
Andrew Dunstan
Sent: 22 June 2006 23:09
To: Tom Lane
Cc: Bort, Paul; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [CORE] GPL Source and Copyright Questions

Something has broken Cygwin in the last 18 days ;-(

Is there any real reason to continue to support Cygwin? We've always
said it's not a first class port, and now we have the native port which
is it seems somewhat pointless expending further effort on it.

Regards, Dave.

Andrew Dunstan <andrew@dunslane.net> writes:

Frankly this patch has significant infelicities. For example,
what is the reason for removing the standard protection
against double inclusion that header files should usually
have from pg_config.h.win32?

I've got to admit, I don't recall that. It may be an oversight - I keep
mixing up pg_config.h.win32 and port.h and port/win32.h in my head ;-)

You will notice that the other two of those don't have it.

But it shouldn't be a problem - AFAIK it's only loaded from c.h, and
that one has protection.

I assume that no test was done to see if this broke Cygwin,
despite the fact that if you have a Windows box to test on,
checking that you haven't broken Cygwin should not be too
difficult..

Given the amount of damage I've seen it do, Cygwin is definitly *not*
making it onto my development machines. So no, I didn't build it on
cygwin. However, I didn't intend for it to break of course - I tried
manual checking. Which I obviously didn't do good enough.

I'll try to set it up in a VM for testing.

And why do win32 and cygwin now not include at all pg_config_os.h?

It's a way to avoid the step to copy win32\port.h in msvc. configure
copies it to pg_config_os.h. Since for win32 platforms (unfortunatly, at
this point it considers cygwin win32..)that will always be port/win32.h,
it explicitly includes that one instead.

Tom writes:

Magnus, this was your patch, can you see about fixing the
collateral damage to the Cygwin build?

Will do. May be a ocuple of days before I can set up a VM with cygwin,
but I'll try to get it done as soon as I can.

//Magnus

On Thu, Jun 22, 2006 at 11:37:08AM -0400, Tom Lane wrote:

item #3: Carsten Wolff copyright in informix.c file
The file informix.c contains a copyright from Carsten Wolff. Did Carsten
directly contribute this file to the PostgreSQL project?

This code was added by Michael Meskes in informix.c rev 1.6
(2003-05-06). Michael, any info on the exact copyright status?

Yes. In fact the copyright belongs to credativ GmbH the company that
paid Carsten for his work. As you may or may not know I'm the CEO of
that company and can assure you that his work was contributed to the
PostgreSQL project.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Dave Page wrote:

Is there any real reason to continue to support Cygwin? We've always
said it's not a first class port, and now we have the native port which
is it seems somewhat pointless expending further effort on it.

Some people still use it for development, I believe. Similar arguments
were used against our having the Win32 port in the first place.
Personally I am inclined to support whatever platforms we reasonably
can, and leave the choice to users rather than make it for them.

cheers

andrew

On Jun 23, 2006, at 3:10 AM, Dave Page wrote:

Is there any real reason to continue to support Cygwin? We've always
said it's not a first class port, and now we have the native port
which
is it seems somewhat pointless expending further effort on it.

Are all the tools needed to compile from source on Win32 freely
available?

John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL

Michael Meskes <meskes@postgresql.org> writes:

On Thu, Jun 22, 2006 at 11:37:08AM -0400, Tom Lane wrote:

item #3: Carsten Wolff copyright in informix.c file

The file informix.c contains a copyright from Carsten Wolff. Did Carsten
directly contribute this file to the PostgreSQL project?

This code was added by Michael Meskes in informix.c rev 1.6
(2003-05-06). Michael, any info on the exact copyright status?

Yes. In fact the copyright belongs to credativ GmbH the company that
paid Carsten for his work. As you may or may not know I'm the CEO of
that company and can assure you that his work was contributed to the
PostgreSQL project.

That sounds fine --- could you add a note in the source code to this
effect? "Contributed under the PostgreSQL License" or something like
that after the copyright notice would be sufficient.

regards, tom lane

-----Original Message-----
From: John DeSoi [mailto:desoi@pgedit.com]
Sent: 23 June 2006 14:56
To: Dave Page
Cc: Andrew Dunstan; Tom Lane; Bort, Paul; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [CORE] GPL Source and Copyright Questions

On Jun 23, 2006, at 3:10 AM, Dave Page wrote:

Is there any real reason to continue to support Cygwin? We've always
said it's not a first class port, and now we have the native port
which
is it seems somewhat pointless expending further effort on it.

Are all the tools needed to compile from source on Win32 freely
available?

Yes. Even when/if we add a VC++ build they will be.

Regards, Dave.

"Dave Page" <dpage@vale-housing.co.uk> writes:

Is there any real reason to continue to support Cygwin? We've always
said it's not a first class port, and now we have the native port which
is it seems somewhat pointless expending further effort on it.

I think the day will come when there's a good reason to decommission the
Cygwin port (ie, some problem that seems unreasonably hard to solve),
and then I'll be the first in line voting to do so. But accidental
breakage due to someone being sloppy with #ifdefs for a different port
isn't a good reason.

Actually, my gripe about this one is that it wasn't detected promptly.
That patch went in two weeks ago; we should have known about the problem
within a couple days at most. Seems like the Windows members of the
buildfarm don't run often enough. The whole point of the buildfarm is
to spot problems while the code is still fresh in mind, no?

regards, tom lane

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 23 June 2006 15:15
To: Dave Page
Cc: Andrew Dunstan; Bort, Paul; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [CORE] GPL Source and Copyright Questions

Actually, my gripe about this one is that it wasn't detected promptly.
That patch went in two weeks ago; we should have known about
the problem
within a couple days at most. Seems like the Windows members of the
buildfarm don't run often enough. The whole point of the buildfarm is
to spot problems while the code is still fresh in mind, no?

I think that speaks for the current usage of the cygwin port. Snake runs
native builds daily, but like Magnus and his dev box there's no way I'm
letting Cygwin anywhere near it. Istr that the only vaguely active
Cygwin member is Andrew's laptop.

Regards, Dave.

"Dave Page" <dpage@vale-housing.co.uk> writes:

Actually, my gripe about this one is that it wasn't detected promptly.
That patch went in two weeks ago; we should have known about
the problem
within a couple days at most. Seems like the Windows members of the
buildfarm don't run often enough. The whole point of the buildfarm is
to spot problems while the code is still fresh in mind, no?

I think that speaks for the current usage of the cygwin port. Snake runs
native builds daily, but like Magnus and his dev box there's no way I'm
letting Cygwin anywhere near it. Istr that the only vaguely active
Cygwin member is Andrew's laptop.

Well, "lack of interest" is certainly adequate reason to decommission a
port. If we can't find anyone who cares enough about Cygwin to host a
regularly-scheduled buildfarm member, I'm for blowing it off.

regards, tom lane

Tom Lane wrote:

"Dave Page" <dpage@vale-housing.co.uk> writes:

Actually, my gripe about this one is that it wasn't detected
promptly. That patch went in two weeks ago; we should have known
about
the problem
within a couple days at most. Seems like the Windows members of the
buildfarm don't run often enough. The whole point of the buildfarm
is to spot problems while the code is still fresh in mind, no?

I think that speaks for the current usage of the cygwin port. Snake
runs native builds daily, but like Magnus and his dev box there's no
way I'm letting Cygwin anywhere near it. Istr that the only vaguely
active Cygwin member is Andrew's laptop.

Well, "lack of interest" is certainly adequate reason to decommission
a port. If we can't find anyone who cares enough about Cygwin to
host a regularly-scheduled buildfarm member, I'm for blowing it off.

What all's needed on the host for this?

I might be able to use either my house machine or my work desktop
here @pervasive, or one of my test boxes here @pervasive.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: ler@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893

On Fri, Jun 23, 2006 at 09:58:42AM -0400, Tom Lane wrote:

That sounds fine --- could you add a note in the source code to this
effect? "Contributed under the PostgreSQL License" or something like
that after the copyright notice would be sufficient.

No problem. Just committed it.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

Tom Lane wrote:

"Dave Page" <dpage@vale-housing.co.uk> writes:

Actually, my gripe about this one is that it wasn't detected promptly.
That patch went in two weeks ago; we should have known about
the problem
within a couple days at most. Seems like the Windows members of the
buildfarm don't run often enough. The whole point of the buildfarm is
to spot problems while the code is still fresh in mind, no?

I think that speaks for the current usage of the cygwin port. Snake runs
native builds daily, but like Magnus and his dev box there's no way I'm
letting Cygwin anywhere near it. Istr that the only vaguely active
Cygwin member is Andrew's laptop.

Well, "lack of interest" is certainly adequate reason to decommission a
port. If we can't find anyone who cares enough about Cygwin to host a
regularly-scheduled buildfarm member, I'm for blowing it off.

We used to have a couple of Cygwin boxes doing regular buildfarm runs. I
don't recall why Jim Buttafuoco stopped running ferret.

I have a shiny new set of components just waiting for me to put them
together in a machine. Sudden trips to Australia and bouts of ill
health have delayed this process far beyond what I wanted. My intention
is to put a couple of VMs on this box, one of which will be Windows, and
will run buildfarm regularly. Of course, if someone wanted to donate a
nice machine, either hosted by me or somewhere else, that would
shortcircuit things :-)

Anyway, the lack of daily Cygwin builds is not permanent.

There are several supported platforms not represented on the buildfarm -
e.g. the one HPUX member has never actually reported any results.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Anyway, the lack of daily Cygwin builds is not permanent.

There are several supported platforms not represented on the buildfarm -
e.g. the one HPUX member has never actually reported any results.

Yeah, and this is not a good thing. Eventually I'd like to get to a
point where every platform we consider "supported" has regular buildfarm
reports. No more calls for port reports during beta periods --- beta
work should focus on functionality testing, not getting it to build.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

There are several supported platforms not represented on the buildfarm -
e.g. the one HPUX member has never actually reported any results.

Yeah, and this is not a good thing. Eventually I'd like to get to a
point where every platform we consider "supported" has regular buildfarm
reports. No more calls for port reports during beta periods --- beta
work should focus on functionality testing, not getting it to build.

Then people who have access to people who own or can provide access to
machines in classes not covered need to do a bit of begging ;-)

The requirements are (deliberately) very modest:

OS and toolset required to build postgres from CVS
A modern perl installation (>=5.6 is adequate)
Anonymous read access to a CVS repository - either the one at
postgresql.org or a replica
Outbound HTTP port 80 access to www.pgbuildfarm.org, possibly via a proxy.

Once it is set up it is close to hands free - you just set up the cron
job(s) or equivalent.

cheers

andrew

On 23/06/06, Andrew Dunstan <andrew@dunslane.net> wrote:

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

There are several supported platforms not represented on the buildfarm -
e.g. the one HPUX member has never actually reported any results.

Yeah, and this is not a good thing. Eventually I'd like to get to a
point where every platform we consider "supported" has regular buildfarm
reports. No more calls for port reports during beta periods --- beta
work should focus on functionality testing, not getting it to build.

Then people who have access to people who own or can provide access to
machines in classes not covered need to do a bit of begging ;-)

The requirements are (deliberately) very modest:

Once it is set up it is close to hands free - you just set up the cron
job(s) or equivalent.

Hello,

I'll try to set up a buildfarm installation for Cygwin on my computer at work.
But I'm taking the next week off, so this will have to wait until my return.

Cheers,
Adrian Maier

And why do win32 and cygwin now not include at all pg_config_os.h?

It's a way to avoid the step to copy win32\port.h in msvc.
configure copies it to pg_config_os.h. Since for win32
platforms (unfortunatly, at this point it considers cygwin
win32..)that will always be port/win32.h, it explicitly
includes that one instead.

Attached simple patch reverts this, as it clearly broke cygwin.

Still can't get it to build on cygwin though, but I doubt it's the fault
of the win32 patch... With ./configure, I get:
checking for random... yes
checking for rint... yes
checking for srandom... yes

But if I look in the generated pg_config.h I have:
/* Define to 1 if you have the `random' function. */
/* #undef HAVE_RANDOM */

and similar for SRANDOM. This gives a "conflicting types for random"
between port.h line 314 and stdlib.h line 24.

Hopefully that's something broken in my cygwin environment only (a fresh
one installed, but I really don't know cygwin enough to comment on if I
broke something :-P), in which case someone with an already working
cygwin environment should be able to build again after this one.

//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:

Attached simple patch reverts this, as it clearly broke cygwin.

Applied ... hopefully it didn't also break mingw ;-)

regards, tom lane

Attached simple patch reverts this, as it clearly broke cygwin.

Applied ... hopefully it didn't also break mingw ;-)

Oh, I tested that. It also didn't break msvc.

//Magnus

On Friday 23 June 2006 14:30, Andrew Dunstan wrote:

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

There are several supported platforms not represented on the buildfarm -
e.g. the one HPUX member has never actually reported any results.

Yeah, and this is not a good thing. Eventually I'd like to get to a
point where every platform we consider "supported" has regular buildfarm
reports. No more calls for port reports during beta periods --- beta
work should focus on functionality testing, not getting it to build.

Then people who have access to people who own or can provide access to
machines in classes not covered need to do a bit of begging ;-)

The requirements are (deliberately) very modest:

OS and toolset required to build postgres from CVS
A modern perl installation (>=5.6 is adequate)
Anonymous read access to a CVS repository - either the one at
postgresql.org or a replica
Outbound HTTP port 80 access to www.pgbuildfarm.org, possibly via a proxy.

Once it is set up it is close to hands free - you just set up the cron
job(s) or equivalent.

Dave,

wasn't someone just trying to donate a machine to us for the website but we
weren't sure what to do with it? One that could do VM's? Seems we could use
that for some buildfarm members maybe.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Michael Meskes wrote:

On Thu, Jun 22, 2006 at 11:37:08AM -0400, Tom Lane wrote:

item #3: Carsten Wolff copyright in informix.c file
The file informix.c contains a copyright from Carsten Wolff. Did Carsten
directly contribute this file to the PostgreSQL project?

This code was added by Michael Meskes in informix.c rev 1.6
(2003-05-06). Michael, any info on the exact copyright status?

Yes. In fact the copyright belongs to credativ GmbH the company that
paid Carsten for his work. As you may or may not know I'm the CEO of
that company and can assure you that his work was contributed to the
PostgreSQL project.

Michael, I saw your patch stating that the copyright was assigned to
PGDG. However, once that happens, we are of the policy to remove
copyrights to individual users because it confuses things.

Therefore, I have updated your applied patch to just mention the
author's name, email address, and date.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:

[ redirecting to -hackers, as I see no need for this to be a core issue ]

Charles Comiskey <comiskey@us.ibm.com> writes:

Hello,
I've recently looked through the PostgreSQL code and a couple of questions
surfaced. I was hoping someone here may be able to answer them. Two have
links to possible GPL sources and the third is just a contribution
question.

item #1: Does the geo_ops.c file contain GPL code?
Embedded within the geo_ops.c file is a John Franks copyright statement
referring to wn/image.c file from WN Server 1.15.1. WN Server appears to
have been under the GPL license since 0.94 and continues to be offered
under the GPL license today. John's letter to Linux Journal seems to only
point the user to his WN Server distribution vs granting any specific
license.

The comment is:

/* poly_contain_pt()
* Test to see if the point is inside the polygon.
* Code adapted from integer-based routines in
* Wn: A Server for the HTTP
* File: wn/image.c
* Version 1.15.1
* Copyright (C) 1995 <by John Franks>
* (code offered for use by J. Franks in Linux Journal letter.)
*/

That term "adapted from" isn't something Thomas would idly type, I
think. I bet it means he looked at John Franks' code and used it as a
base for our code. I am not concerned.

Questions:
1) Is any John Franks code really in this file?
2) Did John provide a separate license for PostgreSQL to license it under
the BSD license?

This code seems to have been inserted by Tom Lockhart on 1997-07-29
(geo_ops.c rev 1.13). Tom, any info on the copyright status?

References:
- 1994 e-mail with GPL reference to WN Server v0.94:
http://1997.webhistory.org/www.lists/www-talk.1994q4/1080.html
- 1995 e-mail from John with GPL license text reference:
http://1997.webhistory.org/www.lists/www-talk.1995q1/0482.html
- WN Server url today: http://hopf.math.northwestern.edu/
- Link to Linux Journal article: http://www.linuxjournal.com/article/2197

item #2: Is dllinit.c GPL code?
The file dllinit.c, located in the src/utils directory documents the
author as Mumit Khan. Did Mumit Khan contribute this code and did he
contribute it for distribution under the PostgreSQL license? If I read
correctly, the name stamp in CVS does not indicate that Mumit Khan
directly contributed this file. I ask because this question has surfaced
as a forum item for a different project and Mumit Khan directly answered
their forum posting (http://curl.haxx.se/mail/lib-2002-11/0061.html).

Per the comments in that thread, it would be pretty trivial to either
rewrite or remove this file. I don't think there is anything there that
amounts to protectable content (and Mumit evidently agrees, see link)
but let's do something about it anyway. Can some of the Windows folk
check whether we can just remove it?

File removed.

item #3: Carsten Wolff copyright in informix.c file
The file informix.c contains a copyright from Carsten Wolff. Did Carsten
directly contribute this file to the PostgreSQL project?

This code was added by Michael Meskes in informix.c rev 1.6
(2003-05-06). Michael, any info on the exact copyright status?

Fixed to remove copyright.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Sat, Jun 24, 2006 at 09:45:45PM -0400, Bruce Momjian wrote:

Michael, I saw your patch stating that the copyright was assigned to
PGDG. However, once that happens, we are of the policy to remove
copyrights to individual users because it confuses things.

Therefore, I have updated your applied patch to just mention the
author's name, email address, and date.

If that suffices, fine with me.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

-----Original Message-----
From: Robert Treat [mailto:xzilla@users.sourceforge.net]
Sent: 24 June 2006 20:50
To: pgsql-hackers@postgresql.org
Cc: Andrew Dunstan; Tom Lane; Dave Page
Subject: Re: Anyone still care about Cygwin? (was Re:
[HACKERS] [CORE] GPL

Dave,

wasn't someone just trying to donate a machine to us for the
website but we
weren't sure what to do with it? One that could do VM's?
Seems we could use
that for some buildfarm members maybe.

As with most of these, the two I was discussing recently fell through
(usual problem, company making the offer seems to think we run the
entire project off one ancient server, and therefore think that the
celeron box they offer will entitle them to be listed as hosts of the
entire project).

Devrim was working with another potential contributor though, dunno how
that's going.

Regards, Dave

I did some research on this item. I downloaded the source code to WN from:

http://hopf.math.northwestern.edu/index.html

I could only find the most recent version. wn-2.4.7. I then looked at
its image.c file:

http://momjian.us/expire/image.c

I looked at the last two functions in the file and compared it to what
we have in CVS, particularly the version of the code when it was first
added to CVS:

http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/geo_ops.c?rev=1.13;content-type=text%2Fplain

Again, look at the last two functions in the file.

You will see similarities and differences. Many of the variable names
are the same, and there is an identical comment block. The algorithm
used is very similar as well, but the style and formatting is different.

I have updated the code comment in CVS to mention the web site, GPL
license, and article describing the algorithm.

Not sure where to go from here.

---------------------------------------------------------------------------

bruce wrote:

Tom Lane wrote:

[ redirecting to -hackers, as I see no need for this to be a core issue ]

Charles Comiskey <comiskey@us.ibm.com> writes:

Hello,
I've recently looked through the PostgreSQL code and a couple of questions
surfaced. I was hoping someone here may be able to answer them. Two have
links to possible GPL sources and the third is just a contribution
question.

item #1: Does the geo_ops.c file contain GPL code?
Embedded within the geo_ops.c file is a John Franks copyright statement
referring to wn/image.c file from WN Server 1.15.1. WN Server appears to
have been under the GPL license since 0.94 and continues to be offered
under the GPL license today. John's letter to Linux Journal seems to only
point the user to his WN Server distribution vs granting any specific
license.

The comment is:

/* poly_contain_pt()
* Test to see if the point is inside the polygon.
* Code adapted from integer-based routines in
* Wn: A Server for the HTTP
* File: wn/image.c
* Version 1.15.1
* Copyright (C) 1995 <by John Franks>
* (code offered for use by J. Franks in Linux Journal letter.)
*/

That term "adapted from" isn't something Thomas would idly type, I
think. I bet it means he looked at John Franks' code and used it as a
base for our code. I am not concerned.

Questions:
1) Is any John Franks code really in this file?
2) Did John provide a separate license for PostgreSQL to license it under
the BSD license?

This code seems to have been inserted by Tom Lockhart on 1997-07-29
(geo_ops.c rev 1.13). Tom, any info on the copyright status?

References:
- 1994 e-mail with GPL reference to WN Server v0.94:
http://1997.webhistory.org/www.lists/www-talk.1994q4/1080.html
- 1995 e-mail from John with GPL license text reference:
http://1997.webhistory.org/www.lists/www-talk.1995q1/0482.html
- WN Server url today: http://hopf.math.northwestern.edu/
- Link to Linux Journal article: http://www.linuxjournal.com/article/2197

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Hi,

On Mon, 2006-06-26 at 08:28 +0100, Dave Page wrote:

Devrim was working with another potential contributor though, dunno
how that's going.

Ok, I talked with them now. They need the following information:

- What type of hardware do we need? Is an Opteron enough? Memory? Disk?
- Do we need a private box, or is a VM enough?
- What is the average traffic of our web servers?

Bandwith is not cheap in Turkey, so they are inclined to put that server
somewhere outside Turkey.

They are ready to proceed, they just want to learn the details.

Regards,
--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

On Monday 26 June 2006 03:28, Dave Page wrote:

-----Original Message-----
From: Robert Treat [mailto:xzilla@users.sourceforge.net]
Sent: 24 June 2006 20:50
To: pgsql-hackers@postgresql.org
Cc: Andrew Dunstan; Tom Lane; Dave Page
Subject: Re: Anyone still care about Cygwin? (was Re:
[HACKERS] [CORE] GPL

Dave,

wasn't someone just trying to donate a machine to us for the
website but we
weren't sure what to do with it? One that could do VM's?
Seems we could use
that for some buildfarm members maybe.

As with most of these, the two I was discussing recently fell through
(usual problem, company making the offer seems to think we run the
entire project off one ancient server, and therefore think that the
celeron box they offer will entitle them to be listed as hosts of the
entire project).

Right, but I am thinking that maybe we should ask these guys if they can offer
boxes for the buildfarm, which could run from a celeron box.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

-----Original Message-----
From: Robert Treat [mailto:xzilla@users.sourceforge.net]
Sent: 26 June 2006 16:08
To: Dave Page
Cc: pgsql-hackers@postgresql.org; Andrew Dunstan; Tom Lane;
Devrim GUNDUZ
Subject: Re: Anyone still care about Cygwin? (was Re:
[HACKERS] [CORE] GPL

Right, but I am thinking that maybe we should ask these guys
if they can offer
boxes for the buildfarm, which could run from a celeron box.

Ahh, you miss the point though - they vanish back into the woodwork when
they realise that they can't brag that they host the entire project.
It's not that they want to help, they just want maximum publicity off
our name for as little hardware as possible.

I should mention at this point that not all companies are like this, and
we do have some very generous contributors to whom we are very grateful.

Regards, Dave.

-----Original Message-----
From: Devrim GUNDUZ [mailto:devrim@commandprompt.com]
Sent: 26 June 2006 15:03
To: Dave Page
Cc: Robert Treat; pgsql-hackers@postgresql.org; Andrew
Dunstan; Tom Lane
Subject: Re: Anyone still care about Cygwin? (was Re:
[HACKERS] [CORE] GPL

Ok, I talked with them now. They need the following information:

- What type of hardware do we need? Is an Opteron enough?
Memory? Disk?

Depends what it was used for.

- Do we need a private box, or is a VM enough?

As above.

- What is the average traffic of our web servers?

Dunno, but not a huge figure - the network is heavily specc'ed towards
high availability and coping with a good /.ing. Individual servers tend
to be very lightly loaded.

Bandwith is not cheap in Turkey, so they are inclined to put
that server
somewhere outside Turkey.

They are ready to proceed, they just want to learn the details.

Well I think Robert is suggesting we setup a box with a bunch of VM's
running different OS's as buildfarm clients. I don't know how useful
that would be, but at the least, with VMWare (or Bochs if it's mature
enough now) and a Windows licence it could run nightly builds of Mingw
and Cygwin, and with just VMWare it could do Solaris x86, and an
assortment of Linuxes and *BSDs.

Regards, Dave.

Dave, all,

Ahh, you miss the point though - they vanish back into the woodwork when
they realise that they can't brag that they host the entire project.
It's not that they want to help, they just want maximum publicity off
our name for as little hardware as possible.

I seem to have missed a cycle. Who are we talking about?

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

OK, with no feedback on this, I have removed the copied comments from
geo_ops.c, reorganized a little, and removed the GPL copyright notice.

Patch attached as unified diff so you can see the line changes easier.
Should this be backpatched to 8.2.X?

---------------------------------------------------------------------------

Bruce Momjian wrote:

I did some research on this item. I downloaded the source code to WN from:

http://hopf.math.northwestern.edu/index.html

I could only find the most recent version. wn-2.4.7. I then looked at
its image.c file:

http://momjian.us/expire/image.c

I looked at the last two functions in the file and compared it to what
we have in CVS, particularly the version of the code when it was first
added to CVS:

http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/geo_ops.c?rev=1.13;content-type=text%2Fplain

Again, look at the last two functions in the file.

You will see similarities and differences. Many of the variable names
are the same, and there is an identical comment block. The algorithm
used is very similar as well, but the style and formatting is different.

I have updated the code comment in CVS to mention the web site, GPL
license, and article describing the algorithm.

Not sure where to go from here.

---------------------------------------------------------------------------

bruce wrote:

Tom Lane wrote:

[ redirecting to -hackers, as I see no need for this to be a core issue ]

Charles Comiskey <comiskey@us.ibm.com> writes:

Hello,
I've recently looked through the PostgreSQL code and a couple of questions
surfaced. I was hoping someone here may be able to answer them. Two have
links to possible GPL sources and the third is just a contribution
question.

item #1: Does the geo_ops.c file contain GPL code?
Embedded within the geo_ops.c file is a John Franks copyright statement
referring to wn/image.c file from WN Server 1.15.1. WN Server appears to
have been under the GPL license since 0.94 and continues to be offered
under the GPL license today. John's letter to Linux Journal seems to only
point the user to his WN Server distribution vs granting any specific
license.

The comment is:

/* poly_contain_pt()
* Test to see if the point is inside the polygon.
* Code adapted from integer-based routines in
* Wn: A Server for the HTTP
* File: wn/image.c
* Version 1.15.1
* Copyright (C) 1995 <by John Franks>
* (code offered for use by J. Franks in Linux Journal letter.)
*/

That term "adapted from" isn't something Thomas would idly type, I
think. I bet it means he looked at John Franks' code and used it as a
base for our code. I am not concerned.

Questions:
1) Is any John Franks code really in this file?
2) Did John provide a separate license for PostgreSQL to license it under
the BSD license?

This code seems to have been inserted by Tom Lockhart on 1997-07-29
(geo_ops.c rev 1.13). Tom, any info on the copyright status?

References:
- 1994 e-mail with GPL reference to WN Server v0.94:
http://1997.webhistory.org/www.lists/www-talk.1994q4/1080.html
- 1995 e-mail from John with GPL license text reference:
http://1997.webhistory.org/www.lists/www-talk.1995q1/0482.html
- WN Server url today: http://hopf.math.northwestern.edu/
- Link to Linux Journal article: http://www.linuxjournal.com/article/2197

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +