RE: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

[Brent Fulgham <brent.fulgham@xpsystems.com>]

> 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