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: <3B939388.2090004@ece.gatech.edu>
Date: Mon, 03 Sep 2001 10:28:24 -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: Corinna Vinschen <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> <3B92B700 DOT 1050201 AT ece DOT gatech DOT edu> <20010903101735 DOT A23714 AT cygbert DOT vinschen DOT de> <999508458 DOT 30663 DOT 11 DOT camel AT lifelesswks> <20010903125344 DOT A29433 AT cygbert DOT vinschen DOT de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Corinna Vinschen wrote:

> On Mon, Sep 03, 2001 at 07:13:49PM +1000, Robert Collins wrote:
> 
>>So finally, IMO, it's up to Chuck - Chuck if you feel you wouldn't be
>>copying, rather creating anew something you have seen working elsewhere,
>>then stand up and be counted. 
>>
> 
> Of course we shouldn't reproduce cygipc.  What we need is a general
> purpose server process which has ipc just as one part.  I just don't
> see a reason that Chuck couldn't work on the ipc part of that server. 
> Assuming he _wants_ to, of course.


Usually, when re-implementing code using the cleanroom approach 
(necessary when the original code is covered by copyright or patent), 
it's considered safest legally if "the coders" have never seen the 
original implementation.  Folks (like me) who've looked at the original 
code are the "testers" who
   (a) write the specifications -- e.g. "we need a function that creates 
new semaphores".  It should obey this signature: 
ipc_create_semaphore(int process_id, security_descriptor *sd, int 
unique_id).  process_id is the id of the calling process that wants the 
  semaphore. If sd == NULL, then allocate a "wide open" 'null' security 
descriptor and use that.  Unique_id is..."
   (b) test the specified code once "the coders" have written it.

When the x86 was cloned, the "coders" (aka chip designers) weren't 
allowed to talk to "the specification team" at all.  ALL communication 
between the two groups was on paper.  (Just a little something I read 
about).

It's more risky when "the testers" (like me) also code, even if there 
are other "coders".  In this particular case, it seems that I'd be the 
only coder for IPC stuff, which is even more risky (legally).  You have 
to *prove* you didn't copy or derive your code from the original source 
if you're ever challenged. (Yep, that's right: guilty until proven 
innocent).  Notice that it doesn't have to be a copy to infringe on the 
original authors' copyrights -- derived works are infringing, too.

However, if folks *want* to take this risk (let's face it, we can't even 
find these original authors; it's doubtful there will ever be challenge 
no matter what -- so the risk is fairly low) then I could start working 
on stuff.  Unfortunately, it's not really *our* decision.  It's the Red 
Hat lawyers' decision.

Additionally, I'm kinda bummed about this issue:  we've had a need for a 
particular feature for a LONG time.  Six months ago or so (back when 
cygipc was first suggested for inclusion as an "official" package) we 
decided that we really needed to reimplement it ourselves, and Egor 
said, "Hey, I've got this daemon thingy we could use as a "cygwin 
daemon" -- it could manage the IPC stuff just like ipc-daemon does if 
somebody adds the code to it" (*bigtime* paraphrase!!)  I mentioned the 
copyright aspects, and said that I considered "myself" to be 
disqualified from working on this for legal reasons.  I also mentioned 
Jason Tishler, Fred Yankowski, and Yakada Tanida as possibly 
"contaminated".  I even mentioned Corinna -- but I was mistaken; her 
contributions back in Feb were in the nature of advice on coding NEW 
stuff in ipc-daemon. This was all original work, so is not covered by 
the pre-existing copyright -- and except for a "alloc_nullsd" snippet, 
she never actually coded anything for ipc-daemon or looked at cygipc 
code at all.

I also thought this was a good way of encouraging other *new* developers 
to pick up some slack: 1) we have a clearly defined need 2) it's limited 
in scope 3) the "usual suspects" *CAN'T* work on it 4) it seems to be a 
high priority for some users.

The perfect combination for a motivated user to jump in and become a 
developer -- how many times have folks complained about cygipc NOT being 
a part of the official packageset?  Yet, even so -- NOBODY has stepped 
forward for over six months.

I'm depressed.

--Chuck

P.S. If a volunteer steps forward to handle the coding side, I'd feel 
much more comfortable (legally) writing specifications based on what I 
know about cygipc implementations.  I'm quite willing to help out in 
this way; but as I said, I'm still hesitant to actually DO the coding. 
Good intentions on my part won't really protect Red Hat against 
copyright infringement/derived work claims.