PostgreSQL and cygipc

Robert Collins
Wed Mar 28 14:05:00 GMT 2001

----- Original Message -----
From: "Christopher Faylor" <>
To: <>; <>
Sent: Thursday, March 29, 2001 7:36 AM
Subject: Re: PostgreSQL and cygipc

> On Wed, Mar 28, 2001 at 04:05:18PM -0500, Charles Wilson wrote:
> >Worse, the existence of the cygipc library as a standard component
> >dis-incentive folks to develop a working substitute that CAN be added
> >the cygwin dll.
> >
> >Do we *really* want to include cygipc in "contrib"?
> Good point.  I seem to have a little bit of deja vu seeing these.  I
> wonder if I have made the same points myself.
> Now that you mention this, I've always resisted looking at the cygipc
> code in case I wanted to do my own implementation someday.
> I did download an os/2 version of an IPC library that was public
> a while ago, though.  After poking at it for a while, I came to the
> that I could do a better job.  Of course, that meant that I didn't
> really do any job.  :-) I did implement the semaphore part of the IPC
> stuff in a rudimentary fashion a few years ago, though.  I could
> that code to anyone who was interested in working on this.

First off... please don't shout when you read this. I've been thinking
about the same topic... I'd really love to simply pick up the cygipc
stuff and put it into cygwin1.dll. But we can't because it's GPL'd, and
cygwin is only GPL'd after it's downloaded from redhat. So a forked
cygwin1.dll & newlibc would be able to merge in GPL code... I been very
careful to avoid looking at existing implementations (ie for the fifo
stuff I ran tests rather than read code).

Chris, is there some way we can have a library of code that is "bolted
on" to cygwin and GPL'd not CYGWIN licenced? Such code would only be
built during a net release, so the redhat commercial builds would still
be a proprietary licence and able to let redhats clients sell their

I.E. the contributed squid tarball is GPL'd. Most of the packages are
GPL'd. The only ones that aren't (AFAIK) are newlib's source and
cygwin1.dll's source. Possibly w32api come to think of it.

BTW: I recognise, and am not arguing against, the commercial means by
which cygwin is supported (in fact I'm very glad of that).

I do recognise that this means more maintenance work, but it's possibly
worth the benefits of allowing compatible source sharing.


More information about the Cygwin-developers mailing list