Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Message-ID: <01a801c0b7d2$ca577bc0$0200a8c0@lifelesswks> From: "Robert Collins" To: , References: <20010328103531 DOT C465 AT dothill DOT com> <20010328105608 DOT C32159 AT redhat DOT com> <3AC2520E DOT 96D89DC8 AT ece DOT gatech DOT edu> <20010328163642 DOT A2091 AT redhat DOT com> Subject: Re: PostgreSQL and cygipc Date: Thu, 29 Mar 2001 08:02:31 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 28 Mar 2001 21:57:19.0362 (UTC) FILETIME=[0F45C620:01C0B7D2] ----- 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 will > >dis-incentive folks to develop a working substitute that CAN be added to > >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 domain > a while ago, though. After poking at it for a while, I came to the conclusion > 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 donate > 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 software... 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. Rob