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 NAA12725; Sun, 11 Nov 2001 13:27:04 +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 NAA12484 for ; Sun, 11 Nov 2001 13:27:03 +0100 (MET) Received: from dpt-info.u-strasbg.fr (dpt-info.u-strasbg.fr [130.79.44.193]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id fABCR2508395 for ; Sun, 11 Nov 2001 13:27:03 +0100 (MET) Received: (from luther@localhost) by dpt-info.u-strasbg.fr (8.9.3/8.9.3) id NAA23804; Sun, 11 Nov 2001 13:25:49 +0100 Date: Sun, 11 Nov 2001 13:25:48 +0100 From: Sven To: Patrick M Doane Cc: Will Benton , caml-list@inria.fr Subject: Re: [Caml-list] License Conditions for OCaml Message-ID: <20011111132548.B23725@dpt-info.u-strasbg.fr> References: <20011109102505.B8267@dpt-info.u-strasbg.fr> <20011109101353.X80907-100000@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20011109101353.X80907-100000@fledge.watson.org>; from patrick@watson.org on Fri, Nov 09, 2001 at 10:33:02AM -0500 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, Nov 09, 2001 at 10:33:02AM -0500, Patrick M Doane wrote: > > The real problem is that the GPL and LGPL are long, with lot of legalese > > things, and difficult to understand in a fast glance, maybe we should prepare > > a small ocaml and LPGL faq or something such. That said, any legal document > > would cause the same problems, i think. > > Hmm... I doubt anyone would be complaining if this were released with the > MIT License. That is much simpler to understand. I am not sure, in my opinion the GPL/LGPL is better, since it ensures that people don't take the code without giving anything back. I am sure it is nicer to people wanting to use it and sell things, but not to people writing the code you use. In any case, i guess your company has enough ressources, that they could negotiate a more traditionnaly licenced version of ocaml if they whish to. That said, you cannot link with other usefull GPL/LGPLed stuff then, and i doubt you will ever convince the FSF or other such to relicence their code. > > > 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. > > > > Sure, but there is another clause below which lift these problems. > > Where? The one you said was incompatible, it is not. > > > 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. > > > > The work being the ocaml runtime system in this case. > > No, that is the library. The first sentence of section 6 reads "you may > compile or a link a 'work that uses the Library'" so it is clear that > 'work' refers to my application. I must look, but again, from previous discution on the debian-legal list, and reading of the FSF GPL/LGPL FAQ, i belive this is not so. > > > 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 is all you need to know about it, it says it quite clearly, you have to > > provide the object files, so that your client can rebuild your app with a > > modified version of the Library, that is the ocaml runtime. > > > > What's the problem with that ? > > It contradicts what is said earlier - that the user must be able to modify > the "work". In section 6, you read, at the end of the second paragraph : directing the user to the copy of this License. Also, you must do one of these things: followed by : a) 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. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) here, you clearly see that : o you need to acompany the complete machine readable source code for the library (ocaml runtime) => note, this can be a link to a place were you can find it. o and, if the work (your programm) 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 (the ocaml runtime) and then relink to produce a modified executable containing the modified Library. e > > 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? > > > > > > No, the customer need to be able to modify the ocaml runtime, not your code, > > and he can do that if you provide the object files. > > This might very well be the intent of the LPGL but it clearly says that > the customer must be able to modify my work, not the ocaml runtime. Please consult your firm's lawyer about it, or search advice from the FSF, but that is what is meant in legalese terms, and if it is not so, i am sure the FSF may be very happy with you finding a problem with their licences and modify it acordyingly. > > If you don't provide the object files, the user cannot modify the ocaml > > runtime, as the LGPL allows him, and as thus you take this right from him. > > Of course the user can modify the ocaml runtime - there is the question as > to whether the user can modify it and relink it with my application. What good will it do him if he can correct a bug in the ocaml runtime, but not in the version of the runtime that is already linked to your app ? > But the object files expose too much proprietary information. The .cmi > files include the names of identifiers plus their types. Even the > identifiers alone are too much. Mmm, this is something Xavier or others from the ocaml team should respond to, But i think someone able to reverse engineer the .cmi, is also more than likely to be able to reverse engineer the asm code as well. Maybe even more likely ? > > > These issues aside, the LGPL is still a real pain to deal with. > > > > > > - The LGPL text must be included with the distribution. > > > > Well, yes, this is normal, what is the problem with that ? It is just a > > relatively small text file, and any commercial distribution comes with it's > > licence and licence of their subparts, is that not so ? > > > > That said, you could well move all the needed object files and this licence > > into a subdirectory, and no more worry about it. > > Sure, this isn't unworkable, my point is that there are things that a user > of OCaml has to do when shipping an executable. Most compilers I've worked > with in the past don't have these kinds of restrictions. You build your > binary and ship it. Well, the problem is not with the compilers, but with the support libraries, i am sure you have the same problem when linking with the libc on linux systems, which is also LGPLed, i think. > > > - All copyright notices for the product need to include the copyright > > > notice for Inria > > > > mmm, don't know about this, but it is no more than a line saying that : > > >From section 6: "If the work during execution displays copyright notices, > you must include the copyright notice for the Library among them" > > > This sotware includes code from ocaml dcopyrighted by inria and licenced under > > the LPGL. > > > > Or something such, what is so difficult about it ? This is a standard legal > > requirement for other stuff, or do you wish to not give proper credit to the > > ocam lteam and inria ? > > I never said that it's difficult. I'm just listing what the requirements > of the LGPL are. > > > > > - 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. > > > > Huh ? Are you sure, i would have to read again, but i don't think it says > > this, What you may need though, is to give a link to a place were it can be > > downloaded, something like adding 'which can be downloaded from > > ftp.inria.fr.' to the above phrase would be enough to comply with this, or > > maybe just a redirection to the caml web pages. > > >From section 6: "Accompany the work with the complete corresponding > machine-readable source code for the Library including whatever changes > were used in the work" Sur, but you could go also with : c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. or d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. or e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. > > > - All source code (or perhaps object code) for my application must > > > be come with distributed. > > > > Object code only, this you cannot avoid. > > I can avoid this with another license - and this is the problem with the > LPGL. Yes, but is it really a problem, and you don't even need to provide it with your app, just offer to make it available as per d) above for example ? Most people would not care anyway. > > > 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. > > > > Only if the authors sue them. > > They are still breaking a license regardless of whether the authors sue > them. Who is not breaking licences, how comes there are so many cross licencing agreement all over the industry ? Because people are breaking licences all over the place, and need to tidy up afterward. > > Do you really think the ocaml team or xavier, or whoever will sue you for > > using ocaml ? > > No, but they didn't write the regexp package. I certainly believe the FSF > would *love* to do this. But, isn't the regexp code linked dynamically ? > > Please, do you still feel so with these clarifications, i am sure you > > can find a compromise with INRIA, maybe against a small fee or a > > consortium membership, and they can provide you with a version of > > ocaml licenced another way. It will not solve the GPled str problem, > > if it really is so, though. > > > > But then, maybe these clarificatiosn are enough ? > > The license is reasonable when delivering a stripped static binary is > sufficent. Additional clauses like giving credit to INRIA are perfectly > acceptable but it's very important to be able to take reasonable steps to > protecting proprietary information. And striping your client with the reasonable assurance of a bug free app, even if your company goes broke or the source code is lost in a disk crash or a terrorist attack on your firm ? > I can tell you that if I had access to the .cmi file for a competitors > product, it would be very easy to steal their code. The implementation and you can't from the plain asm code ? > hardly matters here. Giving away the names of identifiers and their > corresponding types is so much information. They are in no position to > protect their work because they must allow me to reverse engineer it. Again, if this is so important to you, your firm surely has the ressources to reach another argument with INRIA and the ocaml team with regard to licences, isn't it ? I am still curious about what kind of code you really developp, the opensource theory is that such protectionnism is only applicable to domains of very leading edge technology, which are not all that numerous still today. And that often you save more by having people with access to the source code helping you debugging your products, than by doing it yourself. That said, i am not sure this argument is as valid for ocaml than it is for C. But i think we are repeating ourself here, and maybe we are boring a whole lot of peoples on this list, so we may better take this offlist into personal mail ? Friendly, Sven Luther ------------------- 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