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 JAA25649; Wed, 6 Jun 2001 09:38:34 +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 JAA25715 for ; Wed, 6 Jun 2001 09:38:32 +0200 (MET DST) Received: from dpt-info.u-strasbg.fr (dpt-info.u-strasbg.fr [130.79.6.1]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f567cWn21483 for ; Wed, 6 Jun 2001 09:38:32 +0200 (MET DST) Received: from lambda.u-strasbg.fr (mail@lambda.u-strasbg.fr [130.79.90.63]) by dpt-info.u-strasbg.fr (8.9.3/8.9.3) with ESMTP id JAA26589; Wed, 6 Jun 2001 09:37:24 +0200 Received: from luther by lambda.u-strasbg.fr with local (Exim 3.22 #1 (Debian)) id 157Xw1-0001lk-00; Wed, 06 Jun 2001 09:40:57 +0200 Date: Wed, 6 Jun 2001 09:40:57 +0200 To: Brian Rogoff Cc: Jacques Garrigue , caml-list@inria.fr Subject: Re: [Caml-list] CDK license Message-ID: <20010606094057.B4764@lambda.u-strasbg.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i From: Sven LUTHER Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, May 30, 2001 at 08:11:56PM -0700, Brian Rogoff wrote: > On Thu, 31 May 2001, Jacques Garrigue wrote: > > On the same line of thought, the ocaml compiler is released under the > > QPL, which is not compatible with the GPL. > > This means that you cannot build a toplevel including any library > > under the GPL, since it would be in contradiction with either of the > > two licenses. > > At the very least, it seems necessary to add a clause to the GPL, > > saying that linking to QPLed libraries is allowed, just as RMS himself > > suggested for KDE software. > > At this point, I'd suggest that we _really_ need to consult a lawyer who > is familiar with intellectual property law and the GPL. First, i am no lawyer, but as debian developper, and packager of ocaml and some other ocaml stuff for debian, i have been exposed to this kind of stuff a lot, so here is my opinion on it. > As far as libraries go, I think the LGPL is a fair compromise between the > really dedicated RMS followers (once affectionately referred to as > "license ayatollahs" on this very list :) and those who are willing to > tolerate a variety of kinds of software, including proprietary. I > understand the reasons for going GPL instead of LGPL ("resistance is > futile, prepare to be assimilated, or don't use this code") but if it's > going to be that way then I don't want my Consortium dues to fund work > on the CDK. Yes, the LGPL is a good choice, but still it has some problems with regard to ocaml programs/libraries. I think the important part is article 5. of the LGPL : ------------------------------------------------------------------ 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. ------------------------------------------------------------------ What all this is about is that you can do dynamic linking with the library and not release your program source code. That said, ocaml is not a dynamic linking language yet, and as such i don't know up to what point the : only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length). Could be related to the way ocaml uses modules and do linking. Could someone more familiar with the ocaml binaries internal give more light here ? Now, there are 2 possibilities : 1) We consider that the ocaml modules and linking stuff is considered such as Article 5 requires. Then there is no problem, and we can use the LGPL without major problem. But it would be nicer, when giving a LGPL license to your code, to make it clear that we consider it as such, saying for example : "This code is covered by the LGPL. Notice that we consider the ocaml linking and modules hadnling as consisting of only numerical ..." 2) Ocaml linking is more than just the above. Then you can still solve it by : 2.1) state in the license that you make an exception for ocaml linking, something like : "This code is covered by the LGPL with the additional permision that you may use the object file in an unrestricted manner, when linking to other ocaml objects." 2.2) comply with article 6 a), which says that you must also provide a complete machine readeable version of your program (the .cm* files) so that the user can modify the library and relink the program with the modified library. Now you don't need to distribute the files, you can resort to make them available (for at least 3 years) in either a downloadeable place, or in sending it for a cgharge no more than the cost of distirbution to anyone who request it. And naturaly, don't forget that you can issue any code with any number of licences that you want, provided _all_ the authors agree on it. If you plan to do so, best is to check with the consent of anyone who makes contributions to your work, before integrating the patches. Or keep a dual source tree, as was done with mozilla/netscape and some others. Ok, that is most of what i have read from the LGPL stuff, and which applies to ocaml. > > Another remark is that lablgtk-1.2.0 contains a COPYING file, saying > > that the library itself is LGPL, examples are more or less public > > domain, and applications are _not_ open source. Claiming that all this > > is GPL is clearly wrong. This COPYING is not there, and no README file > > either, which is the only documentation for lablgtk :-) > > > > (This is not a rant: I am the one who didn't check) erm, ... 1) about the public domain examples, best would be to add a COPYING file there stating it, because public domain is less restrictive than the LGPL. 2) about the application not being open source, what are they. I cannot possibly continue to include them in the debian package if their license situation is not clarified. Will they come under a closed source licence ? If yes, why, does it make any sense to do so ? 3) IANAL, but it seems to me that since you shipped lablgtk claiming that all of it is LGPLed, at least the versions that where such released are released under the LGPL, you cannot go back. You can change the licence though, but i guess anyone could continue work on the LGPLed version of it. I could be speaking nonsense though, i did not check the exact wording of it. Friendly, Sven Luther ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr