From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 295FABC6B for ; Mon, 7 Jan 2008 20:59:37 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANoSgkfUnw7Vlmdsb2JhbACCNo1eAQEBAQcEBiIHgRSWQQ X-IronPort-AV: E=Sophos;i="4.24,254,1196636400"; d="scan'208";a="7541485" Received: from ptb-relay02.plus.net ([212.159.14.213]) by mail3-smtp-sop.national.inria.fr with ESMTP; 07 Jan 2008 20:59:36 +0100 Received: from [80.229.56.224] (helo=beast.local) by ptb-relay02.plus.net with esmtp (Exim) id 1JBy8F-0005b5-JX for caml-list@yquem.inria.fr; Mon, 07 Jan 2008 19:59:35 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Shared run-time DLLs for commerce Date: Mon, 7 Jan 2008 19:51:23 +0000 User-Agent: KMail/1.9.7 References: <200801071130.29025.jon@ffconsultancy.com> <200801071503.26977.jon@ffconsultancy.com> <47824B45.1000507@frisch.fr> In-Reply-To: <47824B45.1000507@frisch.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801071951.25170.jon@ffconsultancy.com> X-Spam: no; 0.00; run-time:01 ocaml:01 frisch:01 ocaml:01 libs:01 compiler:01 camlp:01 afaik:01 compilation:01 frog:98 wrote:01 wrote:01 caml-list:01 digest:01 cma:01 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