Re: [Caml-list] Shared run-time DLLs for commerce

[Jon Harrop <jon@ffconsultancy.com>]

I'd like to add that OCaml has the potential to become a valuable platform for 
commercial software if these issues are addressed.

On Monday 07 January 2008 15:54:45 Alain Frisch wrote:
> Jon Harrop wrote:
> > We're currently distributing .cma files but the main problem is that
> > they're far too brittle
>
> Ok, your concerns are not really about being able to distribute shared
> libraries, but rather being able to distribute binary libraries that
> don't depend on precise version of other dependent libraries and of
> OCaml. I don't think you'll get them any time soon.
>
> Suggestions:
>
> 1. Distribute the source code, even without an open source license. I
> cannot imagine this would reduce your sales, but you know better.

Yes. The concern here is not loss of sales but loss of competitive edge. With 
direct access to a comprehensible implementation of the complex algorithms 
inside the software, people will nick the algorithms even if they don't nick 
the source code. After 9 years of work, I'd rather not see that happen... :-)

> 2. Distribute a fully packaged OCaml distribution that includes all the
> dependent libraries (your users will be free to add third party libs as
> well).

Even with versions up for OCaml 3.09.1, 3.09.2 and 3.10.0 we're still getting 
requests for 3.09.3 which I didn't even know existed. With the number of 
requests we get for specific compiler versions, I believe customers would be 
unwilling to install a specific OCaml version just for our software.

In other words, we'd be slicing an already-small OCaml market into the tiny 
OCaml version 3.x.y market. I believe the whole OCaml market is just about 
commercially viable but that would not be.

> 3. Obfuscate the parts of the source code you want to keep secret.
> Camlp4 might help here.

This is a possibility but there is little scope for obfuscation within OCaml, 
AFAIK. I really want to distribute after pattern match compilation, for 
example.

I was thinking that externalizing an interface to the intermediate 
representation might be another solution?

> 4. Distribute a static binary that plays the role of a server that
> encapsulates all your precious trade secrets + a client library
> distributed in source code.

In many cases a separate server would work well. However, this is an 
OpenGL-based application so I think this would require one process to be able 
to render efficiently into an OpenGL context from another process. I'm not 
sure how or if that can work or whether or not it would be portable.

> > Ah, I hadn't noticed these .cmxs files. They look good but I assume they
> > are also brittle?
>
> Yes, indeed.

I'd be very happy if the brittle digest comparison were replaced with a 
structural API comparison instead. That would save me a lot of time and 
effort.

One final question: is it possible to throw money at the right people to get 
this kind of work done?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e