Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <3B92B700.1050201@ece.gatech.edu>
Date: Sun, 02 Sep 2001 18:47:28 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713
X-Accept-Language: en-us
MIME-Version: 1.0
To: Ralf Habacker <Ralf DOT Habacker AT freenet DOT de>
CC: Cygwin-Apps <cygwin-apps AT cygwin DOT com>
Subject: Re: cygipc packaging was Updated setup.ini with descriptions, categories, and dependencies
References: <000b01c133a3$0145ec10$7d6707d5 AT BRAMSCHE>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Ralf Habacker wrote:

>>Ralf Habacker wrote:
>>
>>>Hi,
>>>has anybody thinked about the cygipc package, which is needed by
>>>
>>kde ? Should
>>
>>>this be integrated and if so in which category ?
>>>
>>>
>>This has been mentioned with respect to postgresql and kde.
>>Unfortunately, the answer is: "nothing we can do".  That particular
>>dependency will remain "off book" (kinda like Social Security in the US
>>-- it's "real", but it doesn't "count")
>>
>>The problem is basically that the best is the enemy of the good (or in
>>this case, the merely adequate).
>>
>>The Right Thing To Do is to add full IPC support to cygwin itself.
>>There are a few folks thinking about this issue, and what it will
>>require.  Among them: a streamlined daemon starter (cygrunsrv...), a
>>daemon to manage permissions and the shared objects themselves (Egor's
>>"cygwin daemon"?), and *a complete rewrite of IPC code without reference
>>to cygipc*.  (This has to do with licensing issues; the original authors
>>of cygipc retain copyright, and seem to have disappeared -- therefore,
>>we can't contact them to encourage them to assign copyright to Cygnus.
>>
> 
> The email adress if from france. I know a french developer, to which I have
> send the infos about these guys. Perhaps he can find out something.


Well, if Chris is right (and I assume he is) about the fact that the 
cygipc code came from linux, then "these guys" can't really assign 
copyright over to Red Hat *either*.

IOW, this code is covered by copyright owned by not only the two French 
developers, but also an unknown number of unknown linux contributors. 
All of those people must be tracked down, contacted, convinced to sign 
over copyright to Red Hat,...

(Tangent; this tangled mess of overlapping and diverse copyrights is 
touted by Linus Torvalds as one of the strengths of the linux kernel -- 
NOBODY owns a significant portion of it, not even him.  So NOBODY can 
EVER "sign over" ownership to a possibly malevolent corporate interest. 
  No matter what.)

Back to cygipc: so, this ain't gonna happen.  If we want to have IPC 
stuff directly in the cygwin kernel, "we" are going to have to write it 
ourselves.  (Unfortunately, I am most likely disallowed from helping, as 
are a number of other people.  "Contaminated" by exposure to the cygipc 
code.  How can anyone be sure that any code I contribute is not 
influenced -- or even copied! -- from my knowledge of the cygipc internals?)



> 
> I understand this complex problem only a little and I have some additional
> questions/remarks from my
> subjective view:
> 
> pro packaging:
> 1. Which advantage has integrating cygipc into cygwin ?
> For kde2 as example I have no problem to use an additional package, because it
> depends
> on about 15 external libs. One more or less isn't very important.
> Are there performance issues, stability, maintainance or other reasons ?
> What about the needed time to integrate this ? When would this be ready for use
> ?


Well, currently we're in a "no new packages" freeze.  Once that is 
lifted, I can have a cygipc package ready for SOME OTHER MAINTAINER to 
contribute in about a week.  (I am not willing to personally contribute 
cygipc, because I just can't handle another package...I'm swamped.)


> pro integrating
> 2. Is cygipc not distributed under the GPL ? Isn't that not enough to modify
> and use this code for cygwin, perhaps maintained as separate static lib,
> but linked into cygwin like the cygwin xfree team thinked about for the Xextlib
> ?


No, you misunderstand two issues: licensing and cygipc client/server 
dualism.

1) licensing: anything that is a part of the cygwin kernel ITSELF must 
have copyright ownership assigned to Red Hat.  This is because a 
copyright OWNER is allowed to distribute the software under multiple 
licenses; Red Hat distributes the cygwin kernel under BOTH GPL and a 
proprietary license.

Now, as a NON copyright owner, you or I have the right to *redistribute* 
*GPL* code -- but ONLY under the GPL.

Thus, if the cygipc *Server* code (more on this later) is actually 
INCORPORATED into the cygwin kernel -- either (a) it must by copyright 
assigned to Red Hat, or (b) Red Hat loses its right to distribute cygwin 
under the proprietary license.

Now, RH is not going to do that.  (and please, let's not start that old 
flamewar about GPL purity and proprietary licenses).  We thus have a choice:
   a) do nothing -- status quo
   b) provide cygipc as an official *package* with cygwin -- but not 
incorporated into the dll itself
   c) fork cygwin -- incorporate cygipc directly into "our" version of 
the cygwin kernel
   d) rewrite the IPC server function calls in a "cleanroom" way, and 
incorporate THAT into the cygwin kernel.  Rewrite the ipc-daemon as a 
cygwin deamon (in a "cleanroom" way) to handle the actual 
open/close/security manipulation IPC stuff.  Distribute that daemon as a 
  core cygwin package.  <IMO, Egor's cygwin deamon is a better starting 
place for this than ipc-daemon)  Rewrite the libcygipc.a client library 
(in a "cleanroom" way) and distribute as a core cygwin package.
   e) **CAN'T DO THIS; SEE ABOVE** get copyright assignment from 
original authors of cygipc code, incorporate cygipc directly in to 
cygwin dll.

Client/Server duality:
  to provide IPC functionality, you need a *server process*.  linux has 
the kernel (which is an actual, running process).  The cygwin "kernel" 
is NOT really a kernel.  It's just a shared lib that takes advantage of 
certain windows quirks to *pretend* that it is a running process.

Unfortunately, that's not enough for IPC.  we need a *real* process -- 
thus, the server daemon.

You also need some "system calls".  In linux, these are handled by the 
kernel.  In cygipc, these are split between ipc-daemon (which implements 
some stuff itself, or calls on the Win32 low-level IPC stuff), and the 
client library libcygipc.a.

In choice (d) above, the cygwin kernel would provide implemenations for 
many of the server-side syscalls AND implementations for the client-side 
syscalls.  (thus, no more need for -lcygipc when building client 
programs).  The cygwin daemon would be started at boot time, but most of 
the "guts" would actually just be calls to functions implemented in 
cygwin1.dll.


> pro integrating
> 3. Chris wrote:
> 
>>IIRC, the original "authors" got the code from the linux kernel
>>so they couldn't actually assign anything.
>>
> What's than the problem to take this code and integrate it ? Who can made a
> decision ?


As I explained above, many unavailable (unknown?) copyright holders is 
NOT the same thing as zero copyright holders.  It is NOT the same thing 
as "public domain."  We *can't* just take the code without permission -- 
and then release it under a proprietary license (as well as GPL) as if 
the code were our own.  ("we" and "our" == Red Hat; but I am not am 
employee of RH).


> 
> As I stated before, I see this from my very subjective way and this is because
> of the hard work on
> porting kde, mostly with ld and libtool (which are not ready for use with kde2)


aside; yeah, I've been desperately trying to contact Paul but he's not 
returning my email.  There's a BIG bug in binutils that I can't fix, in 
ADDITION to the memory leak that's causing you <ralf> so much trouble. 
Sigh.


> I like the cygipc as it is.
> Install and run. Thats all. 


I wish.  I get at least one email a week from somebody who has trouble 
with "install and run".

> If someone is able to say integrating is very little
> work (I can't that), than this would be the best way :-)


sure, recompiling cygipc to live in the /usr tree (not /usr/local), 
stripping out the --install-as-service stuff (and relying on cygrunsrv 
instead) -- that would take very little time.

BUT

I will not contribute and support yet another official package.  I can 
barely keep up with the ones I'm supporting now.  (Anybody want to take 
over zlib and libpng?)  So, IF (and it's a big if) we decide to 
incorporate cygipc as a official-but-separate package(*), I will help 
someone else get started, and then *that* person may contribute it.

(*) e.g. a cygipc package, distributed on the cygwin mirror system, 
installable by setup.exe -- but not part of cygwin1.dll itself.

--Chuck