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