Version française
Home     About     Download     Resources     Contact us    
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: -- (:)
From: Sven LUTHER <luther@d...>
Subject: Re: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml
On Tue, Jun 06, 2000 at 03:46:06PM -0500, Daniel Ortmann wrote:
> 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".

This surely is the philosophy of those who want to make more money using all
the free software that other people have developped for free.

Anyway, i personnaly are not at all in favor for a scheme such as what you
propose.

But then i am a Debian GNU/Linux developper and my opinion might be a bit
biased on this.

Still, please remmeber a few things :

1) Reverse engineering is legal in many european countries.

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.

3) Well this would be a big step back in what the has been achieved in
freedom of software and sharing of ressources. Caml has a too small
community today that you can permit to hamper it by being overly
protectionist. And despite what you may think, it would be more important fro
ocaml to be adopted by the "free" software community (that is all the
linux/*bsd/whatever users), than by the "non-free" one (that is the people you
have in mind). Since the former surely will contain all the programmers in
formation who will later become programmers and decider of the second group.
Also remember that many big companies are going for the "free" movement, like
IBM and SGI for example.

4) Is there really a need for this, would the complexity of doing so not
outweigh the benefit ?

5) In particluar there is a theory that says that security though peer review
permitted by open source developpment model is higher than security trough
hiding which you are suggesting. Or else you will find yourself with a
microsoftian type of product (buggy, hidden, expensive, ...), which i doubt
is something the ocaml community wish to be associated with.

6) If someone is good enough to reverse engineer your ocaml bytecode, i think
he is good enough also to reverse engineer your encrypted stuff, or at least
to find holes in the security of it. 

7) If you think the bytecode security is not enough for you, just use native
code, it is faster anyway, and i doubt you will have less hideance in this
than writting in C or C++, ...

8) Finally, if all the above don't convince you, Ocaml is now available under
a free license, and thus you are free to implement such a scheme, if you want
so. This may not be the best fro the ocaml community, but still you can do it.

As a personal note, if it is not confidential, what are the personal interrest
that make you ask yourself this kind of questions, are you aware of a
particular company which ask this kind of question when faced with ocaml ?

And i hope this few remarks can contribute to this discution, please don't
take them negatively, if i was unexact or maybe offending somewhere.

Friendly,

Sven LUTHER