SEO

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

> 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...94q4/1080.html
> - 1995 e-mail from John with GPL license text reference:
> http://1997.webhistory.org/www.lists...95q1/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?


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

> Thank you,
> Charles Comiskey
> Tivoli Software
> IBM Software Group
> comiskey@us.ibm.com
> 919.224.1223 or TL 687-1223

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: 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

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

"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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

---------------------------(end of broadcast)---------------------------
TIP 1: 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

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

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