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 QAA08027 for caml-red; Mon, 12 Jun 2000 16:00:16 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA08312 for ; Fri, 9 Jun 2000 20:18:29 +0200 (MET DST) Received: from thresher.xpsystems.com ([207.171.47.5]) by nez-perce.inria.fr (8.10.0/8.10.0) with ESMTP id e59IIEr16651 for ; Fri, 9 Jun 2000 20:18:28 +0200 (MET DST) Received: by THRESHER with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Jun 2000 11:18:57 -0700 Message-ID: From: Brent Fulgham To: Daniel Ortmann Cc: caml-list@inria.fr Subject: RE: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml Date: Fri, 9 Jun 2000 11:18:56 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: weis > Also, isn't "information hiding" part of the purpose of .cmi > files? What I am suggesting might be viewed as an stronger > type of .cmi file ... with REAL "implementation hiding". :-) > Regarding your later anecdote about the Lisp source being available under Emacs, I think we may be comparing apples to oranges. Pulling up a .cmi file in a text editor does not provide me with the same ease-of-analysis of Lisp sources. I would have to sit down and understand the byte value meanings for the OCaml VM, parse the bytes in the .cmi file, and then discern the meaning. This is no different than "decompiling" the byte code from a Java VM (the compiled "class" modules). Certainly one of us could write a utility to "decompile" .cmi files (such beasts exist for Java). I guess my point is: The .cmi files seem to be obfuscated enough for general distribution. I mean, someone with enough interest in your 'secrets' to learn the byte code and write a decompiler will be capable of doing the same to native object code as well. I guess I'm just not sure your proposal would provide sufficient value for the effort and performance hit required. [ ... snip ... ] > > 2) Encryption is illegal in many countries, or at least > > export restricted, i think france changed this some time > > ago, but if not, it would not be possible for inria to > > distribute such a product. > > I believe the US has just lightened up on some of the restrictions. > > ... But the answer would be: Don't distribute the actual > encryptiong directly with O'Caml, just the hooks. Have the Please note that under the US's current law (well, current prior to the most recent potentially-temporary relaxation), it is also prohibited to provide encryption hooks in your code. You could get around this by calling them "compression" hooks. Regards, -Brent