On 6/17/05, Andrew Suffield <[EMAIL PROTECTED]> wrote: > On Thu, Jun 16, 2005 at 04:42:00PM -0400, Mike wrote: > > Arnoud Engelfriet wrote: > > >Usually the advice is to write your own code based on descriptive > > >information about the protocol, without looking at the original > > >implementation. In other words, use the RFC, not the code. > > >This avoids accusations about nonliteral copying. > > > > Too bad it's a closed source protocol. But I will give reverse > > engineering it a try it might be interesting. It's a tiny protocol I > > might just be able to figure it out. There might even be some unofficial > > docs on the web somewhere. > > The best way to break derivation for stuff like this is to > reverse-engineer it and write a description of the protocol. Then > implement your own version using *only* the description. Never touch > both at once. > > To be really robust, you must have different people doing the two > parts, but even with only one, following the discipline gives you a > solid defence against accusations of copying.
This sort of reverse engineering to specification, followed by cleanroom implementation, is primarily used to defend against accusations of misappropriation of trade secrets. The reverse engineering team is vetted to make sure that they have had no privileged access to the target's knowledge going in, and the process is documented to demonstrate that it followed procedures available to any competitor. Hunting "unofficial" docs on the web is exactly the kind of thing that you shouldn't be doing if the source code and protocol are trade secrets. If you don't have any contractual relationship to the vendor or any information obtained through privileged access, then you don't have to worry about trade secrets, just copyright. If the implementation is closed source, and you're cloning its function, the burden is still on you to demonstrate that you copied only what you absolutely had to. Independently arriving at a very similar solution to the same problem is not a very good defense, since you are obviously reverse engineering a specific implementation. If you are in a position to compare the two by decompiling the original, you are obliged to make a reasonable effort to do so (in for a dime, in for a dollar) and to diverge from the expressive content of the original in pretty much every way possible while retaining interoperability. See, for instance, the recent Lexmark case in the Sixth Circuit, in which Static Control was permitted to copy the entire Toner Loading Program verbatim, but only because they demonstrated that its cryptographic checksum had to match in order to interoperate. The dissent in Lexmark is very well argued, and covers the history of reverse engineering cases at appellate level in the US. Judge Feikens felt that Static Control should have been obliged to work even harder at the reverse engineering, spot a flag that could be used to turn off the checksum operation, flip that flag and write their own Toner Loading Program. That view did not prevail, but it's an indication of the degree of thoroughness a judge expects from a reverse engineering project's avoidance of unnecessary literal copying. When you are talking about published source code, there is no trade secret to be misappropriated. You can't really claim not to have had access to the original source code, and there's no evidence that you didn't read the source code other than your own word. The only purpose of reverse engineering under those circumstances is to help demonstrate that, where your code resembles the original, that reflects functional necessity rather than plagiarism. It's complete folly not to look at openly published source code if you're trying to clone its function without infringing copyright. If it comes to a court battle, you have to be able to demonstrate that every bit of overlapping expressive content is a matter of engineering necessity. Publishing the source code of the original raises the burden of proof on the cloner, since it facilitates a good-faith effort on the cloner's part to avoid plagiarism. Cheers, - Michael (IANAL, TINLA)