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
From: "Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>
To: "Cygwin-Apps" <cygwin-apps AT cygwin DOT com>
Subject: RE: cygipc packaging was Updated setup.ini with descriptions, categories, and dependencies
Date: Mon, 3 Sep 2001 16:27:40 +0200
Message-ID: <001501c13484$968c9e90$651c440a@BRAMSCHE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
In-Reply-To: <3B92B700.1050201@ece.gatech.edu>
Importance: Normal

> -----Ursprüngliche Nachricht-----
> Von: Charles Wilson [mailto:cwilson AT ece DOT gatech DOT edu]
> Gesendet am: Montag, 3. September 2001 00:47
> An: Ralf Habacker
> Cc: Cygwin-Apps
> Betreff: Re: cygipc packaging was Updated setup.ini with descriptions,
> categories, and dependencies
>
> 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.

You write about Win32 low-level IPC: Could this not be used for creating an ipc
deamon ?


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

I understand

>
> >
> > 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.
>
He don't answer any mail I have send too although he ask me to help him to get
this feature running two month ago.

>
> > 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?)
I'm sorry,

 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.
>
So when nobody is found, the package stay as it is, and this means that it would
not be integrated into cygwin. Is that right ?


> --Chuck
>
>
>