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
[Caml-list] License Conditions for OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-11-11 (14:56)
From: Patrick M Doane <patrick@w...>
Subject: Re: [Caml-list] License Conditions for OCaml
Hi Sven,

I agree that this discussion maybe getting a bit much for the list. Here
are responses to a few of those points that I think are relevant:

On Sun, 11 Nov 2001, Sven wrote:

> Tell me, what application do you want to write that you are so afraid people
> will reverse engineer ?

I'm not afraid of it - but those around me who pay the bills are. I'm
relating the opinions of what I see in the commercial world. It is very
common to strip binaries of all identifiers (or at least munge them beyond
comprehension), and to have copy protection code. People are taking
reasonable steps to protect their intellectual property.

I want to see Caml succeed in that world. Now, it seems that Xavier
indicates that these problems will be fixed which is great. We have had a
number of good suggestions posted to the list that should be acceptable.

> > Hmm... I doubt anyone would be complaining if this were released with
> > the MIT License. That is much simpler to understand.
> That said, you cannot link with other usefull GPL/LGPLed stuff then, and
> i doubt you will ever convince the FSF or other such to relicence their
> code.

Sure you can, it is perfectly acceptable to link non-LPGL code with LPGL
code provided that you follow the rules of the LGPL.

> > But the object files expose too much proprietary information. The .cmi
> > files include the names of identifiers plus their types. Even the
> > identifiers alone are too much.

> Mmm, this is something Xavier or others from the ocaml team should
> respond to, But i think someone able to reverse engineer the .cmi, is
> also more than likely to be able to reverse engineer the asm code as
> well. Maybe even more likely ?

There are already several tools included in the distribution to get you
started. Look under the tools directory at application like 'dumpapprox'.
Luckily, the .cmi files should not be needed to relink an application.
These would contain the most information.

It is relatively easy to reverse engineer assembly when identifiers are
still present in the code. Take these out and the problem get much harder.


Bug reports:  FAQ:
To unsubscribe, mail  Archives: