From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA12418 for caml-red; Fri, 9 Jun 2000 19:50:39 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA00372 for ; Fri, 9 Jun 2000 19:12:26 +0200 (MET DST) Received: from suburbia.net (suburbia.net [203.4.184.1]) by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e59HCLn29834 for ; Fri, 9 Jun 2000 19:12:23 +0200 (MET DST) Received: by suburbia.net (Postfix, from userid 110) id E844F6C508; Sat, 10 Jun 2000 01:44:19 +1000 (EST) To: "Daniel Ortmann" Cc: caml-list@inria.fr Subject: Re: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml References: <200006062047.QAA08876@northrelay03.pok.ibm.com> Cc: proff@iq.org From: Julian Assange Date: 10 Jun 2000 01:44:19 +1000 In-Reply-To: Daniel Ortmann's message of "Tue, 6 Jun 2000 15:46:06 -0500" Message-ID: User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/21.1 (Big Bend) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: weis Daniel Ortmann writes: > 1) The idea occurs to me that O'Caml might support various standard encryption > modules using different types of encryption techniques (DES, PGP, etc). > 2) Perhaps user encryption could also be supported. > 3) Perhaps the encryption modules should be composeable, multiple modules > being used to derive another module. > 4) What about using public/private keys and key management? > 5) Should this be integrated with licensing? What licensing techniques are > available on Windows? Mac? Unix? Other? (O'Caml WILL get big > commercially, and WILL need to address this eventually.) > 6) What things should be visible non-encrypted in cmi/cmo/other files? > 7) Should such encryption be available via marshalling? If not, might some > needs be common? My god, this is awful. (a) encryption will not help you if it is standardised. If it is not standardised, then all it will do is delay understanding. If it can be decrypted by the vm, it can be decrypted by the analyst. (b) Time to market penalties are so incredibly brutal now, I question whether obfuscating byte-code is at all necessary, simply because most people don't have time to analyse source code, let alone byte code. (c) Ocaml applications are so rare (compared to C/++), you can consider not only Ocaml byte code, but the Ocaml source code an excellent obfuscater. (d) Commercial programs rarely implement unpublished, hard to discover ideas. Patents are so easy to acquire you are far better off using patent protection. (e) Those who are willing to rip you off by reverse engineering are probably willing to do it by sheer piracy. e.g 2nd and 3rd world markets. > Philosophically speaking, earning money and protecting the rewards of hard > work are not bad a priori. There *will* be an exchange of value; that > exchange may be either with or without "concern for your fellow man". In > fact, one way of looking at a dollar bill is as a type of "certificate of > service to your fellow man". The problem is there is a lot of value exchange that isn't represented by the face of the bill. Ocaml itself is a case in point. Cheers, Julian.