Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2000-06-07 (18:22)
From: Daniel Ortmann <ortmann@v...>
Subject: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

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


How can companies protect their bytecode, at least their modules, from reverse

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 or and 507.253.6795 (external) and tieline 8.553.6795 (internal) 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