From: Martin J. <mar...@em...> - 2004-04-27 08:13:06
|
Hi ExtLibs, I would like to know the exact purpose of the sourceforge.net ExtLib (let's call it SF-ExtLib). This is taken from the web page: > ExtLib is a project aiming at providing a complete - yet small - standard > library for the OCaml programming langage. The purpose of this library is > to add new functions to OCaml Standard Library modules, to modify some > functions in order to get better performances or more safety > (tail-recursive) but also to provide new modules which should be useful > for the average OCaml programmer. > ExtLib is not directly related to OCaml authors (INRIA) although this > library can be seen as a proposal for inclusion in the official > distribution. Is SF-ExtLib supposed to be used from right now in serious projects? Is it supposed to replace the INRIA standard library? Why is there no answer from the SF-ExtLib team when I (or others) post some code? This is very disappointing. If SF-ExtLib is supposed to build a standard, then what are the guidelines for creating this standard? The other ExtLib (from Shawn Wagner, let's call it SW-ExtLib) does not intend to become a standard, as far as I can read: > Extlib contains a lot of the routines I find myself needing all the time > that aren't in the standard library (Especially string searching and > manipulation), and some other odds and ends that are useful at times. > Highlights include wildcard globbing, lots of string searching and > manipulation routines, locale support, ~user-style path expansion, and > more. As an independent OCaml user, I would like a separation between general-purpose stuff and specialized libraries. general-purpose = used in various kinds of applications (but maybe not everyday) specialized = used in very specific situations (but maybe everyday) I can imagine: - one library that provides lots of goodies that do not rely on other existing libraries but are boring or difficult to implement. They do NOT need to be required everyday by everyone. - some libraries, like many already exist, for doing specialized things. Especially the implementation of standard protocols or binding to such libraries written in foreign languages. Very personal view: I don't care much about standards as far as I can include the (possibly modified) source code of the general-purpose library in my software distributions in either source or binary form. Martin |
From: Nicolas C. <war...@fr...> - 2004-04-27 11:05:28
|
> > ExtLib is a project aiming at providing a complete - yet small - standard > > library for the OCaml programming langage. The purpose of this library is > > to add new functions to OCaml Standard Library modules, to modify some > > functions in order to get better performances or more safety > > (tail-recursive) but also to provide new modules which should be useful > > for the average OCaml programmer. > > > ExtLib is not directly related to OCaml authors (INRIA) although this > > library can be seen as a proposal for inclusion in the official > > distribution. > > Is SF-ExtLib supposed to be used from right now in serious projects? Yes, it's mature and bug-free enough. > Is it supposed to replace the INRIA standard library? No. We're positioning ourselves as a proposal for extension. That means that some parts of the ExtLib might be added to the OCaml stdlib if INRIA wish to do so : we would actually be happy about that. Whatever happens, we'll still maintain an independant library that can enrich the standard ocaml library and research additional ways of doing things better. > Why is there no answer from the SF-ExtLib team when I (or others) post > some code? This is very disappointing. I usually answer most of the messages, all subsribers on this list are also welcome to do so. If there is no answer to your message it means that maybe people here are too busy to answer, or maybe that there is no interest on this subject. If you're precisely talking about your recent post "('a,'b list ref) Hashtbl.t" then I personaly never had the need of such module (although I am programming ocaml almost everyday in different domains). That does not mean that it is not useful, but maybe that does mean it's not wide usage enough to be included. I dismissed myself from answering since I don't see how it can be useful. If some people were interested by this module, they would have answered. If there was a common agreement that it's useful (whatever my opinion) then I would have committed the code into the CVS. > If SF-ExtLib is supposed to build a standard, then what are the guidelines > for creating this standard? Not a standard, just a library. Guidelines are : - everybody can post some code or suggestions for improvement - all the process is open-sourced , including the talks and debates about what should be included or not - if there is a concensus, then the code is included. > As an independent OCaml user, I would like a separation between > general-purpose stuff and specialized libraries. > general-purpose = used in various kinds of applications (but maybe not > everyday) > specialized = used in very specific situations (but maybe everyday) > I can imagine: > - one library that provides lots of goodies that do not rely on other > existing libraries but are boring or difficult to implement. They do NOT > need to be required everyday by everyone. > - some libraries, like many already exist, for doing specialized > things. Especially the implementation of standard protocols or binding to > such libraries written in foreign languages. > > > Very personal view: I don't care much about standards as far as I can > include the (possibly modified) source code of the general-purpose > library in my software distributions in either source or binary form. ExtLib is general purpose. That means that some domain-specific code will not be included into it. For other reasons, such as easy porting, ExtLib is pure OCaml and does not contains any C code. Concerning the protocols ( IMAP, FTP, ... or formats : XML , ... ) my own opinion is that they could be added to ExtLib, that's not an opinion shared by all the users here so nothing have been decided yet. Regards, Nicolas Cannasse |
From: Martin J. <mar...@em...> - 2004-04-27 11:50:22
|
On Tue, 27 Apr 2004, Nicolas Cannasse wrote: > > Is it supposed to replace the INRIA standard library? > > No. We're positioning ourselves as a proposal for extension. That means that > some parts of the ExtLib might be added to the OCaml stdlib if INRIA wish to > do so : we would actually be happy about that. Whatever happens, we'll still > maintain an independant library that can enrich the standard ocaml library > and research additional ways of doing things better. So, what makes you better than them? What additional power do you have? Things like: - hundreds of developers (?) - extra financial support (?) - exceptional communication skills (?) - ... > > Why is there no answer from the SF-ExtLib team when I (or others) post > > some code? This is very disappointing. > > I usually answer most of the messages, all subsribers on this list are also > welcome to do so. If there is no answer to your message it means that maybe > people here are too busy to answer, or maybe that there is no interest on > this subject. > > If you're precisely talking about your recent post "('a,'b list ref) > Hashtbl.t" then I personaly never had the need of such module (although I am > programming ocaml almost everyday in different domains). That does not mean > that it is not useful, but maybe that does mean it's not wide usage enough > to be included. I dismissed myself from answering since I don't see how it > can be useful. If some people were interested by this module, they would > have answered. If there was a common agreement that it's useful (whatever my > opinion) then I would have committed the code into the CVS. There were many messages on the caml-list about a Hashtbl.keys function, and how to remove the redundancies (!). The answer is simple: don't add the same key multiple times. Use Hashtbl.replace if don't want to keep all the previous bindings. If you need to keep them, then use something like my proposal, and everything will become O(1) or O(n). I really think that such a module is useful because it hides an imperative approach behind a safe interface. Sorry, but I thought first that SF-ExtLib was an attempt to provide a more complete library than the standard one. For me, "more complete" does not mean "adding a few functions that INRIA was too stupid to forget", but providing 10 times more modules than INRIA and using the community to maintain this large collection. If only 2 or 3 persons have the power to check and decide what should be in SF-ExtLib, then the result will be similar to the current INRIA's standard library, unless you convince Superman to learn OCaml. ... unless there are very rational and precise conditions for adding things into the library so that the ExtLib leaders can check in 1 minute if some proposal is acceptable or not. I hope you understand my critics and that reading this is not a complete waste of time. Thanks for your attention, Martin |
From: Bardur A. <oca...@sc...> - 2004-04-27 12:23:49
|
On Tue, Apr 27, 2004 at 07:50:04PM +0800, Martin Jambon wrote: > On Tue, 27 Apr 2004, Nicolas Cannasse wrote: > > > > Is it supposed to replace the INRIA standard library? > > > > No. We're positioning ourselves as a proposal for extension. That means that > > some parts of the ExtLib might be added to the OCaml stdlib if INRIA wish to > > do so : we would actually be happy about that. Whatever happens, we'll still > > maintain an independant library that can enrich the standard ocaml library > > and research additional ways of doing things better. > > So, what makes you better than them? What additional power do you have? > > Things like: > - hundreds of developers (?) > - extra financial support (?) > - exceptional communication skills (?) > - ... I just think of it a more experimental branch of development for the ocaml standard library. If some extension/change from Extlib proves to be highly useful to lots of developers, then it can be added to the standard library when it has matured enough to be considered stable enough for the "mainline" (which would be the INRIA O'caml standard library). -- Bardur Arantsson <ba...@im...> <ba...@sc...> - Mmmmmmmmmmmmmmmm... something. Homer Simpson | The Simpsons |
From: Martin J. <mar...@em...> - 2004-04-27 12:45:22
|
On Tue, 27 Apr 2004, Bardur Arantsson wrote: > I just think of it a more experimental branch of > development for the ocaml standard library. > > If some extension/change from Extlib proves to be highly > useful to lots of developers, then it can be added to the > standard library when it has matured enough to be > considered stable enough for the "mainline" (which would > be the INRIA O'caml standard library). I am afraid that the people from INRIA are very satisfied with the quality of the current standard library, and will not accept any significant addition because they are not paid for writing libraries (and maybe not interested too). Martin |
From: Bardur A. <oca...@sc...> - 2004-04-27 12:55:12
|
On Tue, Apr 27, 2004 at 08:45:02PM +0800, Martin Jambon wrote: > On Tue, 27 Apr 2004, Bardur Arantsson wrote: > > > I just think of it a more experimental branch of > > development for the ocaml standard library. > > > > If some extension/change from Extlib proves to be highly > > useful to lots of developers, then it can be added to the > > standard library when it has matured enough to be > > considered stable enough for the "mainline" (which would > > be the INRIA O'caml standard library). > > I am afraid that the people from INRIA are very satisfied with the > quality of the current standard library, and will not accept any > significant addition because they are not paid for writing libraries (and > maybe not interested too). > Nitpick: They wouldn't actually have to write the libraries, they would already be written. So it wouldn't cost them anything to include them. But even so, if they decide not to accept anything from ExtLib into the mainline, that would be fine too. It doesn't really detract from the value of ExtLib as a more experimental (and, dare I say it, much more *useful*) standard library. -- Bardur Arantsson <ba...@im...> <ba...@sc...> - Good night. If you CAN! Stephen Fry | Fry and Laurie |
From: Martin J. <mar...@em...> - 2004-04-27 13:18:21
|
On Tue, 27 Apr 2004, Bardur Arantsson wrote: > On Tue, Apr 27, 2004 at 08:45:02PM +0800, Martin Jambon wrote: > > > On Tue, 27 Apr 2004, Bardur Arantsson wrote: > > > > > I just think of it a more experimental branch of > > > development for the ocaml standard library. > > > > > > If some extension/change from Extlib proves to be highly > > > useful to lots of developers, then it can be added to the > > > standard library when it has matured enough to be > > > considered stable enough for the "mainline" (which would > > > be the INRIA O'caml standard library). > > > > I am afraid that the people from INRIA are very satisfied with the > > quality of the current standard library, and will not accept any > > significant addition because they are not paid for writing libraries (and > > maybe not interested too). > > > > Nitpick: They wouldn't actually have to write the > libraries, they would already be written. So it wouldn't > cost them anything to include them. I don't believe in this model: software is living, it has sometimes to be rewritten or corrected. They will not accept this burden. Martin |
From: Bardur A. <oca...@sc...> - 2004-04-27 13:26:07
|
On Tue, Apr 27, 2004 at 09:17:59PM +0800, Martin Jambon wrote: > On Tue, 27 Apr 2004, Bardur Arantsson wrote: > > > On Tue, Apr 27, 2004 at 08:45:02PM +0800, Martin Jambon wrote: > > > > > On Tue, 27 Apr 2004, Bardur Arantsson wrote: > > > > > > > I just think of it a more experimental branch of > > > > development for the ocaml standard library. > > > > > > > > If some extension/change from Extlib proves to be highly > > > > useful to lots of developers, then it can be added to the > > > > standard library when it has matured enough to be > > > > considered stable enough for the "mainline" (which would > > > > be the INRIA O'caml standard library). > > > > > > I am afraid that the people from INRIA are very satisfied with the > > > quality of the current standard library, and will not accept any > > > significant addition because they are not paid for writing libraries (and > > > maybe not interested too). > > > > > > > Nitpick: They wouldn't actually have to write the > > libraries, they would already be written. So it wouldn't > > cost them anything to include them. > > I don't believe in this model: software is living, it has sometimes to be > rewritten or corrected. Now, you've lost me... nobody said anything about rewriting or even "correcting" ocaml itself. As long as there is 100% compatibility with existing code, there is no reason for them *not* to accept things from extlib. >They will not accept this burden. If you think that they will never accept extlib modules, then that's your perogative, but like I said (the part you cut out): The value of extlib (as a project) remains in either case. -- Bardur Arantsson <ba...@im...> <ba...@sc...> - I tell ya, they only come out at night, or, in this case, the daytime. Chief Clancy Wiggum | The Simpsons |
From: Martin J. <mar...@em...> - 2004-04-27 14:15:42
|
On Tue, 27 Apr 2004, Bardur Arantsson wrote: > On Tue, Apr 27, 2004 at 09:17:59PM +0800, Martin Jambon wrote: > > > I don't believe in this model: software is living, it has sometimes to be > > rewritten or corrected. > > Now, you've lost me... nobody said anything about > rewriting or even "correcting" ocaml itself. I was talking about extlib: if it is included in INRIA's distribution and used by the compilers, at least someone at INRIA must check the quality of extlib. In this message, Xavier Leroy gave his point of view: http://caml.inria.fr/archives/200403/msg00171.html > As long as > there is 100% compatibility with existing code, there is > no reason for them *not* to accept things from extlib. > > >They will not accept this burden. > > If you think that they will never accept extlib modules, > then that's your perogative, but like I said (the part you > cut out): The value of extlib (as a project) remains in > either case. OK, but I don't have comments about that. Martin |
From: Nicolas C. <war...@fr...> - 2004-04-27 14:51:49
|
> > > I don't believe in this model: software is living, it has sometimes to be > > > rewritten or corrected. > > > > Now, you've lost me... nobody said anything about > > rewriting or even "correcting" ocaml itself. > > I was talking about extlib: if it is included in INRIA's distribution and > used by the compilers, at least someone at INRIA must check the quality of > extlib. > > In this message, Xavier Leroy gave his point of view: > http://caml.inria.fr/archives/200403/msg00171.html To put it clear : we're not excepting in any way ExtLib to be included into Ocaml distribution, we are just wishing it will be, but that's not current INRIA politics. In the future, and if ExtLib is widely used by the OCaml users, it might be packaged with OCaml or told as "you should definitly use that, you beginner". > So, what makes you better than them? What additional power do you have? ExtLib is not experimental either. It really works ! and have some advanced concepts that are making it better - I think - than other libs around. Mainly because most of the libs are the work of one people alone for his own needs, without thinking about the community of users. If you ask me why we're better I would say : - good experience with Ocaml (including "inside-the-box" such as low-level accesses or functors perfs) - an open process where everybody is welcome to post codes and comments Regards, Nicolas Cannasse |
From: Florian H. <ha...@bi...> - 2004-04-27 15:09:59
|
Nicolas Cannasse wrote: > To put it clear : we're not excepting in any way ExtLib to be included into > Ocaml distribution, we are just wishing it will be Of course, including code from extlib into the core distribution would kill ocaml for commercial development (due to the incompatible license), so it will not happen in the forseeable future. Yours, Florian. |
From: Alan P. <ap...@re...> - 2004-04-27 18:22:00
|
In article <408...@bi...>, Florian Hars wrote: > > Of course, including code from extlib into the core distribution > would kill ocaml for commercial development (due to the incompatible > license), so it will not happen in the forseeable future. I thought both libraries were LGPL? |
From: Florian H. <ha...@bi...> - 2004-04-29 06:31:01
|
Alan Post wrote: > In article <408...@bi...>, Florian Hars wrote: >>Of course, including code from extlib into the core distribution >>would kill ocaml for commercial development (due to the incompatible >>license), so it will not happen in the forseeable future. > > I thought both libraries were LGPL? No, the standard Library is LGPL + linking exception, Extlib is plain LGPL, which is almost the same as plain GPL for ocaml code, because the way the ocaml linker works makes it virtually impossible to distribute object code according to 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. without supplying the source code to your application. This may be a major difference for closed source projects. The only difference to the GPL is that you can supply the source under a NDA, but that is a lot of hassle. To reiterate my pet peeve: Releasing ocaml code under an unmodified LGPL is in many cases a sign of a careless licence choice since it doesn't do for ocaml what it does for C code, and so probably doesn't do what the authors intended. Getting the same effect as the LGPL has for C code is technically impossible with the current ocaml toolcahin. Make up your mind and either release under the GPL proper, or under a more liberal/less free (pick your poison) licence like LGPL + linking exception, old X, new BSD, or whatever. Or fix the linker to be compatible with the LGPL, but that is a major (or, rather, MAJOR) project. Yours, Florian. |
From: Nicolas C. <war...@fr...> - 2004-04-29 07:11:31
|
> Alan Post wrote: > > In article <408...@bi...>, Florian Hars wrote: > >>Of course, including code from extlib into the core distribution > >>would kill ocaml for commercial development (due to the incompatible > >>license), so it will not happen in the forseeable future. > > > > I thought both libraries were LGPL? > > No, the standard Library is LGPL + linking exception, Extlib is plain LGPL, ExtLib is also LGPL + linking exception , since it's released under "the same licence as Ocaml stdlib". From the README.txt : Licence : --------- Licence is the same as OCaml standard Library: LGPL without some linking restrictions. Regards, Nicolas Cannasse |
From: Bardur A. <oca...@sc...> - 2004-04-29 07:18:13
|
On Thu, Apr 29, 2004 at 09:10:36AM +0200, Nicolas Cannasse wrote: > > Alan Post wrote: > > > In article <408...@bi...>, Florian Hars wrote: > > >>Of course, including code from extlib into the core distribution > > >>would kill ocaml for commercial development (due to the incompatible > > >>license), so it will not happen in the forseeable future. > > > > > > I thought both libraries were LGPL? > > > > No, the standard Library is LGPL + linking exception, Extlib is plain > LGPL, > > ExtLib is also LGPL + linking exception , since it's released under "the > same licence as Ocaml stdlib". > From the README.txt : > > Licence : > --------- > > Licence is the same as OCaml standard Library: > LGPL without some linking restrictions. > That text is rather unclear... "*without* some linking *restrictions*"? Shouldn't that read LPGL **with** the linking **exception** ?? The full license text should also be available in a COPYING file!!! That would make it much clearer that it is indeed the same license as the OCaml stdlib. -- Bardur Arantsson <ba...@im...> <ba...@sc...> If at first you don't succeed, failure may be your style. http://www.demotivators.com |
From: Florian H. <ha...@bi...> - 2004-04-29 09:05:32
|
Nicolas Cannasse wrote: > ExtLib is also LGPL + linking exception , since it's released under "the > same licence as Ocaml stdlib". > From the README.txt : I explicitely checked the licence statements in the HEAD version of severeal source files in the repository before posting, and none of these were released with the linking exception. (IO.ml, dbi.ml, enum.ml, extLib.ml, refList.ml ...) The README.txt is mostly irrelevant if the actual files say something else if you want to play safe on the IP side, sad as it is. Yours, Florian. |
From: Nicolas C. <war...@fr...> - 2004-04-29 13:20:49
|
> Nicolas Cannasse wrote: > > ExtLib is also LGPL + linking exception , since it's released under "the > > same licence as Ocaml stdlib". > > From the README.txt : > > I explicitely checked the licence statements in the HEAD version of severeal > source files in the repository before posting, and none of these were released > with the linking exception. (IO.ml, dbi.ml, enum.ml, extLib.ml, refList.ml ...) > The README.txt is mostly irrelevant if the actual files say something else if > you want to play safe on the IP side, sad as it is. I'm not familiar with IP ;) If someone could tell what exactly to put into the files in order to be consistent with the wanted licence, I'll do the changes before the upcoming release. Regards, NC |
From: Florian H. <ha...@bi...> - 2004-04-30 14:02:41
|
Nicolas Cannasse wrote: > If someone could tell what exactly to put into the files in order to be > consistent with the wanted licence, I'll do the changes before the upco= ming > release. In every file, change * version 2.1 of the License, or (at your option) any later version. to * version 2.1 of the License, or (at your option) any later version, * with the special exception on linking described in file <filename>. and make sure that you only do this on files you have written yourself, o= r=20 where you have a written statement by the original author authorizing the= =20 change. Look at the ocaml distribution for inspiration about how to fill=20 "filename". Tsch=FCss, Florian Hars. |
From: Nicolas C. <war...@fr...> - 2004-05-02 10:43:33
|
> > If someone could tell what exactly to put into the files in order to = be > > consistent with the wanted licence, I'll do the changes before the upcoming > > release. > > In every file, change > > * version 2.1 of the License, or (at your option) any later version. > > to > > * version 2.1 of the License, or (at your option) any later version, > * with the special exception on linking described in file <filename>. > > and make sure that you only do this on files you have written yourself,= or > where you have a written statement by the original author authorizing t= he > change. Look at the ocaml distribution for inspiration about how to fil= l > "filename". > > Tsch=FCss, Florian Hars. Thanks, This is now updated , the only files remaining under plain LGPL are Ocaml= DBI ones. I'm waiting for the answer of its author in order to make the licen= ce changes. Other changes were made without contacting other contributors, since only the headers were wrong, everybody agreed to release under the same licence as Ocaml stdlib when the extlib starts. Regards, Nicolas Cannasse |
From: Nicolas C. <war...@fr...> - 2004-05-02 10:48:05
|
> This is now updated , the only files remaining under plain LGPL are OcamlDBI > ones. I'm waiting for the answer of its author in order to make the licence > changes. Changed confirmed, files commited. NC |
From: Richard J. <ri...@an...> - 2004-05-03 12:03:26
|
On Thu, Apr 29, 2004 at 11:05:10AM +0200, Florian Hars wrote: > Nicolas Cannasse wrote: > >ExtLib is also LGPL + linking exception , since it's released under "the > >same licence as Ocaml stdlib". > >From the README.txt : > > I explicitely checked the licence statements in the HEAD version of > severeal source files in the repository before posting, and none of these > were released with the linking exception. (IO.ml, dbi.ml, enum.ml, > extLib.ml, refList.ml ...) The README.txt is mostly irrelevant if the > actual files say something else if you want to play safe on the IP side, > sad as it is. The dbi code does have the linking exception; just that it's not properly documented in the code ... Rich. -- Richard Jones. http://www.annexia.org/ http://www.j-london.com/ Merjis Ltd. http://www.merjis.com/ - improving website return on investment MAKE+ is a sane replacement for GNU autoconf/automake. One script compiles, RPMs, pkgs etc. Linux, BSD, Solaris. http://www.annexia.org/freeware/makeplus/ |
From: John G. <jgo...@co...> - 2004-04-29 13:58:54
|
On Thu, Apr 29, 2004 at 08:30:45AM +0200, Florian Hars wrote: > Alan Post wrote: > >In article <408...@bi...>, Florian Hars wrote: > >>Of course, including code from extlib into the core distribution > >>would kill ocaml for commercial development (due to the incompatible > >>license), so it will not happen in the forseeable future. > > > >I thought both libraries were LGPL? > > No, the standard Library is LGPL + linking exception, Extlib is plain LGPL, > which is almost the same as plain GPL for ocaml code, because the way the > ocaml linker works makes it virtually impossible to distribute object code > according to > > 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. I don't buy it. You are quoting from section 6 of the LGPL, which grants exceptions for programs that use the library and combine themselves with portions of it (statically linking in the C sense, standard procedure in the OCaml sense.) From my reading of it, you are merely required, for ocaml, to provide the source code for the library and either source or object code for your work. So, you could provide the source to the library and .cmo/.cma files for your work. That is akin to providing .o and .a files in C. I don't see the difference. Moreover, what you quoted is but one option of five. And you can still use runtime linking (Dynlink) to load up the library. > Getting the same effect as the LGPL has for C code is technically > impossible with the current ocaml toolcahin. Make up your mind and > either release under the GPL proper, or under a more liberal/less free > (pick your poison) licence like LGPL + linking exception, old X, new > BSD, or whatever. Or fix the linker to be compatible with the LGPL, > but that is a major (or, rather, MAJOR) project. I don't really understand how OCaml is different from statically-linking in C. This is not a new problem. |
From: Florian H. <ha...@bi...> - 2004-04-30 14:02:44
|
John Goerzen wrote: > I don't really understand how OCaml is different from statically-linking > in C. This is not a new problem. OK, the I stand partially corrected: the linker is a bit more liberal than my subjective impression was after chasing too many chains of "File B and A make inconsistent assumptions over interface A" and then the same with C and B and so on... You can make some changes to the library and still relink, so technically you can in fact comply with the cited section from the LGPL. But there is a large class of changes to a library that keep the interface in the definitions files (as of LGPL 6.a, last sentence) unchanged and still make relinking impossible, so you might still be in violation of the LGPL if you don't distribute the source, depending on how much money the opposite side can pay for a lawyer. Here is a trivial example, first we compile a library and a program that uses it: $ cat foobar.mli val print_foobar: unit -> unit $ cat foobar.ml let print_foobar x = print_endline "foobar" $ cat use.ml let _ = Foobar.print_foobar () $ ocamlopt -a foobar.mli foobar.ml -o foobar.cmxa $ ocamlopt foobar.cmxa use.ml -o run $ ./run foobar Now we change the library slightly by factoring some functionality into a helper function without changing the visible interface and relink with the cmx of the application: $ cat foobar.ml let foobar x = "foobar" let print_foobar x = print_endline (foobar x) $ ocamlopt -a foobar.mli foobar.ml -o foobar.cmxa $ ocamlopt foobar.cmxa use.cmx -o run Files use.cmx and foobar.cmxa make inconsistent assumptions over implementation Foobar This is different form C, since the C linker does not care about additional symbols in the library, and a fortiori not about symbols that are not visible in the library. This behaviour of the C linker is written into the LGPL and it is disputable whether the ocaml linker has the required properties to allow releasing a work that uses a library without source. If you want to be safe, you cannot rely on it (look at the IBM policy: never ever use LGPL code that is statically linked, just to be safe). Copyright law is ugly. Yours, Florian. |