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 MAA10029; Fri, 9 Nov 2001 12:10:20 +0100 (MET) 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 MAA08938 for ; Fri, 9 Nov 2001 12:10:19 +0100 (MET) Received: from comtv.ru (mail.comtv.ru [217.10.32.4]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id fA9BAIn04865 for ; Fri, 9 Nov 2001 12:10:18 +0100 (MET) Received: from [10.2.64.72] (HELO oyster2) by comtv.ru (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1124418; Fri, 09 Nov 2001 14:10:08 +0300 Date: Fri, 9 Nov 2001 14:09:50 +0300 (MSK) From: malc X-Sender: malc@oyster To: Patrick M Doane cc: Will Benton , caml-list@inria.fr Subject: Re: [Caml-list] License Conditions for OCaml In-Reply-To: <20011108235538.V73712-100000@fledge.watson.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, 9 Nov 2001, Patrick M Doane wrote: > On Thu, 8 Nov 2001, Will Benton wrote: > > > Whoa, nelly! I don't know that I'd characterize the LGPL as a > > "problem", but your reading of it is completely off the mark. The LGPL > > requires that if you distribute an application linked to a library, that > > you must allow users to re-link against newer versions of the library > > that maintain interface compatibility, presumably by providing object > > files, bytecodes -- OR you must distribute an application that uses > > shared libraries. It is C-centric, but I do not think it poses any > > problems. (You must also redistribute any changes you make to the > > LGPLed library itself.) > > OCaml doesn't provide support for shared libraries (although 3.03 does > provide some dynamic loading capabilities for bytecode only). So we > need to consider the portions of the license that apply for static > linking. The LGPL provides some rather contradictory statements in section > 6 regarding that: While this is true for stock ocaml, there is a patch that adds shared linking support to 3.03Alpha, with limited scope though - i386 ELF only. (shameless plug) You can find it here http://algol.prosalg.no/~malc/scaml > > 1. you may also compile or link a "work that uses the Library" with the > Library to produce a work containing portions of the Library, and > distribute that work under terms of your choice, provided that the > terms permit modification of the work for the customer's own use and > reverse engineering for debugging such modifications. > > This clause is enough to throw out most commercial applications. It is > standard industry practice to disallow reverse engineering. Most software > companies are going to resist changing this - and for good reason too. > > Note that the license terms must also permit "modification of the work for > the customer's own use". I'm not sure of any way to comply with that > without providing source code. Object files are certainly not suitable > for modification by customer use. > > 2. Accompany the work with the complete corresponding machine-readable > source code for the Library including whatever changes were used in > the work (which must be distributed under Sections 1 and 2 above); and, > if the work is an executable linked with the Library, with the complete > machine-readable "work that uses the Library", as object code and/or > source code, so that the user can modify the Library and then relink > to produce a modified executable containing the modified Library. > > Here it suggests that object code is sufficient but this can't be modified > for the customer's own use. Perhaps this contradiction invalidates this > section of the license, I don't know. I'm not a lawyer. The only > reasonable way I see to comply with these two points is to provide source > code. Do you have any suggestions on how a user can modify object code > for their own use? > > These issues aside, the LGPL is still a real pain to deal with. > > - The LGPL text must be included with the distribution. > - All copyright notices for the product need to include the copyright > notice for Inria > - All these notices must also direct the user to the LPGL license > - All source to the INRIA libraries and standard runtime must be > included in the distribution. This is particularly annoying for > Windows developers because that distribution doesn't come in source > form. > - All source code (or perhaps object code) for my application must > be come with distributed. > - Or, as an exception to the previous two, a written letter must be > included with the product to be able to get those two. > > This is a lot of hassle - nowhere near the suggestion that "the LGPL puts > no restrictions at all on programs linked with LGPL-ed binaries." > > There are other license problems as well. In particular, some of the > libraries distributed with OCaml (like Str) are based on GPL code, but the > manual does not mention this and it would be very easy for a developer to > get into trouble because of that. > > I'm sorry if this sounds like just a lot of complaining, but I'm sure > folks in the commercial world would rather pay a small fee to avoid these > issues entirely. Ideally, any OCaml executable (with the exception of this > created with ocamlmktop) should be unencumbered from license issues. I > believe this was the intent of the INRIA team, but this is not the current > situation. > > ------------------- > Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ > To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr > > -- mailto:malc@pulsesoft.com ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr