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 UAA17836 for caml-red; Wed, 7 Jun 2000 20:22:00 +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 WAA06813 for ; Tue, 6 Jun 2000 22:47:54 +0200 (MET DST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by nez-perce.inria.fr (8.10.0/8.10.0) with ESMTP id e56Klq503818 for ; Tue, 6 Jun 2000 22:47:53 +0200 (MET DST) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA169950 for ; Tue, 6 Jun 2000 16:46:02 -0400 Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30]) by northrelay03.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id QAA08876 for ; Tue, 6 Jun 2000 16:47:49 -0400 Message-Id: <200006062047.QAA08876@northrelay03.pok.ibm.com> Received: by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 6082 ; Tue, 06 Jun 2000 14:48:29 MDT Reply-To: "Daniel Ortmann" Received: from neon.rchland.ibm.com by po1 (AIX 3.2/UCB 5.64/4.7) id for caml-list@inria.fr; Tue, 6 Jun 2000 15:46:07 -0500 Received: by neon.rchland.ibm.com (AIX4.3/UCB 8.8.8/4.7) id ; Tue, 6 Jun 2000 15:46:06 -0500 Date: Tue, 6 Jun 2000 15:46:06 -0500 X-Authentication-Warning: neon.rchland.ibm.com: ortmann set sender to ortmann@rchland.ibm.com using -f From: Daniel Ortmann To: caml-list@inria.fr Subject: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml Sender: weis Sirs, With the intent of furthering the practical commercial use of O'Caml, or at least eliminating some possible objections to its use ... I submit the following observations and questions for your consideration: I have asked myself "How might companies object to Objective Caml?" The thought occurs to me that companies may wish to: - develop and sell byte-compiled O'Caml modules - develop and sell applications which use dynamically loaded modules - protect their actual source code Because of the well-thought regularity of O'Caml bytecode, the ease of viewing (for example) emacs elisp bytecode in emacs, and the unusual numbers of bright people working with O'Caml ... ... it occurs to me that companies may be concerned about the ease of "reverse engineering" their byte compiled software modules and thus object to Objective Caml. So. How can companies protect their bytecode, at least their modules, from reverse engineering? 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? 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". -- Daniel Ortmann, IBM Circuit Technology, Rochester, MN 55901-7829 ortmann@vnet.ibm.com or ortmann@us.ibm.com and 507.253.6795 (external) ortmann@rchland.ibm.com and tieline 8.553.6795 (internal) ortmann@isl.net and 507.288.7732 (home) "The answers are so simple, and we all know where to look, but it's easier just to avoid the question." -- Kansas