Mail Archives: cygwin-apps/2001/09/03/10:28:28
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.
- Raw text -