Messages in this thread |  | | Date | Fri, 27 Dec 96 16:52 MST | From | (Clifford T. Matthews) | Subject | Re: "legal" advice required |
| |
>>>>> "Dick" == Richard B Johnson <root@analogic.com> writes:
[snip]
Dick> In the event that the manufacturer is not cooperative, some Dick> third party can WRITE A SPECIFICATION, detailing all he/she ^^^^^^^^^^ Dick> is able to determine by any means whatsoever including ^^^^^^^^^^^^^^^^^^^^
It's not sufficient to detail all that one is able to determine. You must detail all that is required, and as a functional specification. If the bits that are being loaded are indeed tables for some finite state machine, then you can't specify the bits, but you can describe the machine and detail what transitions need to be made and why.
Dick> disassembling code. This specification must address what has Dick> to be done, NOT how to do it. This is the way Phoenix wrote Dick> the first "clone" BIOS for the IBM/PC/AT. They had a bunch Dick> of "dirty" engineers that disassembled code, etc., and wrote Dick> a complete specification. ^^^^^^^^^^^^^^^^^^^^^^^^
The specification has to be functional in nature, so the person writing it can't just say blast a particular bitstream across. So *much more* analysis would have to be done before you could use the clean-room/dirty-room approach that Dick is suggesting.
After all, people intent on cloning the Mac can't include the Mac ROMs in their code by getting someone to write a spec. that says "then, during bootup, load these 512k bytes into memory..."
From Dick's description, it appears that he knows this, but since the original question was "I have a bunch of bits that need to be sent, but I don't know what they do", I just want to make sure that everyone knows that clean-room/dirty-room engineering will require the big step of figuring out exactly what those bits do. Only then can someone write a description of the requirements for those bits. And nobody can write down the bits themselves (there are exceptions, but I don't think they would apply to this particular case) and pass that information on to the implementor without tainting the implementation.
--Cliff ctm@ardi.com
|  |