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 GAA02508; Fri, 9 Nov 2001 06:37:52 +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 GAA02241 for ; Fri, 9 Nov 2001 06:37:51 +0100 (MET) Received: from fledge.watson.org ([204.156.12.50]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id fA95bon29357 for ; Fri, 9 Nov 2001 06:37:50 +0100 (MET) Received: from localhost (patrick@localhost) by fledge.watson.org (8.11.6/8.11.5) with ESMTP id fA95ZC574204; Fri, 9 Nov 2001 00:35:13 -0500 (EST) (envelope-from patrick@watson.org) Date: Fri, 9 Nov 2001 00:35:11 -0500 (EST) From: Patrick M Doane To: Will Benton cc: caml-list@inria.fr Subject: Re: [Caml-list] License Conditions for OCaml In-Reply-To: <3BEB605D.78A04C4E@cs.wisc.edu> Message-ID: <20011108235538.V73712-100000@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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: 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