From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id IAA13953; Tue, 7 Sep 2004 08:18:07 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id IAA14508 for ; Tue, 7 Sep 2004 08:18:06 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i876I3Wn016585 for ; Tue, 7 Sep 2004 08:18:05 +0200 Received: from [192.168.1.200] (ppp210-32.lns2.syd3.internode.on.net [203.122.210.32]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i876Hx4Y084268; Tue, 7 Sep 2004 15:48:01 +0930 (CST) Subject: Re: [Caml-list] Announcing the OMake build system version 0.9.1 From: skaller Reply-To: skaller@users.sourceforge.net To: Jacques GARRIGUE Cc: caml-list In-Reply-To: <20040907.112159.74194635.garrigue@kurims.kyoto-u.ac.jp> References: <1094463492.3352.1061.camel@pelican.wigram> <20040906.203420.68034706.garrigue@kurims.kyoto-u.ac.jp> <1094488104.3352.1160.camel@pelican.wigram> <20040907.112159.74194635.garrigue@kurims.kyoto-u.ac.jp> Content-Type: text/plain Message-Id: <1094537878.3352.1262.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 07 Sep 2004 16:17:59 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 413D529C.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 jacques:01 gpl:01 gpl:01 wrappers:01 glance:01 9660:01 glebe:01 compiler:01 compiler:01 garrigue:01 nsw:01 snail:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Tue, 2004-09-07 at 12:21, Jacques GARRIGUE wrote: > 2) the point I was trying to make was that the distinction between > static and dynamic linkage is not relevant here, since the tool > discussed does not link to anything anyway. As it stands. But a client might want to modify it. They might want to bind more strongly to it. They might want to add a custom routine to it. See below for a real example. > An ambiguity is only a problem if you happen to be in the ambiguous > area. I do not see how it can matter when you are well outside of it. Because things change -- what starts off clear may become less clear as you modify things. Here is a real example. Felix contains the CIL package, which is a C parser. It is used in a stand alone wrapper generator tool. Suppose CIL were GPL***, and I don't care if the wrapper generator is GPL. All is fine! Only -- a cute trick is to actually build the wrapper generator directly into the Felix compiler so you can #include a C file directly (and the compiler processes the generated wrappers). I actually DID do this (although I removed that feature). Well, if CIL were GPL that would make my core compiler also GPL -- simply because of a small change in the integration architecture. Such absurd artificial constraints in an experimental package make multi-licence situations undesirable. It also isn't just a legal problem that I might be able to sort out -- there is the issue of what potential clients might think with a cursory glance at the project. *** CIL is BSD. If it had been GPL I wouldn't have even considered it for inclusion. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners