From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 0799ABE33 for ; Mon, 25 Oct 2004 17:15:30 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i9PFFT0I017815 for ; Mon, 25 Oct 2004 17:15:29 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA25821 for ; Mon, 25 Oct 2004 17:15:28 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i9PFFQpZ032224 for ; Mon, 25 Oct 2004 17:15:28 +0200 Received: from [192.168.1.200] (ppp217-99.lns1.syd3.internode.on.net [203.122.217.99]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i9PFFLOU046988; Tue, 26 Oct 2004 00:45:22 +0930 (CST) Subject: Re: [Caml-list] Re: Announce: Schoca-0.2.3 released From: skaller Reply-To: skaller@users.sourceforge.net To: Stefan Monnier Cc: caml-list In-Reply-To: References: <1098642597.3075.32.camel@pelican.wigram> <20041025025832.GA1582@old.davidb.org> <20041025.123834.26988978.garrigue@math.nagoya-u.ac.jp> <20041025050127.GA3599@old.davidb.org> <417CB289.1010700@exomi.com> Content-Type: text/plain Message-Id: <1098717320.3075.309.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 26 Oct 2004 01:15:20 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 417D1891.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 417D188E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 sourceforge:01 wrote:01 gmp:01 gmp:01 gpl:01 bug:01 gpl:01 wrappers:01 wrappers:01 usr:01 usr:01 glebe:01 ffau:98 061:98 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: On Tue, 2004-10-26 at 00:35, Stefan Monnier wrote: > Following the GMP precedent (GMP was a GPL library and someone wanted to use > it in a non-GPL product), the FSF managed to require the company to write > the crappy implementation "fgmp" but was then satisfied. Sounds like a con job. I can write code that requires a GMP compatible library and FSF can't do anything about how I licence my code -- provided I don't actually derive any of my code from GPL'd code. > I.e. there's a clear precedent that shows you *can* indeed use the trick of > writing a crappy compatible library. The real problem is that to make your code work properly with GMP or other library you need to provide an interface. It isn't so easy to do that without 'deriving' from a published specification -- either the actual headers or the documentation. You have to use the same function names and equivalent types, and to get that right you pretty much have to derive from the spec. I have no idea how to do that without coming under the control of the licence for the spec .. but if you do manage to do so, the ability to link to the implementation can't possibly be relevant .. unless perhaps you test your code against it, and make bug fixes, in which case those fixed codes just might be deemed derived works. As it happens, Felix has a wrapper for the C++ wrapper for GMP, and it is FFAU and not GPL because the interface is 'the usual math operators'. I also ship a wrapper generator that can wrap code like GMP to make it available under Felix. Those wrappers are derived, and so they're GPL .. but I don't ship them, only the tool that creates them. It's not clear including such wrappers in a Felix program requires it to be GPL either. That's because Felix has an advanced source code linker that only instantiates used code .. so you can have the capability there, and perhaps your whole source is infected .. but if you don't actually call GMP the resultant program is no longer GPL :) Umm . what .. lol! Which all comes back to the stupidity of trying to define what using/linking/combining/distributing/ etc etc actually mean. The answer is -- nothing at all, outside of existing practice used for C programs. Interscript/Felix/Flxcc (the latter is the wrapper generator) approach the problem in such a novel way that the terms of the GPL are meaningless. For example .. the wrapper generator creates a derived work .. but it fails to include the licence of the original work in the generated wrappers. Is it breaching GPL? Of course not -- its the *client* who uses it that is at risk. Well, perhaps your /usr/include contains some code licenced with a license incompatible with GPL .. but flxcc wraps the *whole* of /usr/include in one go. The resultant product is derived from all of it simultaneously. So is it actually legal to run the tool at all?? -- 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