ftp.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-apps/2001/09/03/10:27:49

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
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
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <3B92B700.1050201@ece.gatech.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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.
> 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

- Raw text -

  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019