This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Richard Stallman wrote: > > I don't know what scenario you are talking about now. > So I cannot be sure whether I would agree or disagree > with what you mean to say about it. I suggest that if you > want to write something and have me be able to follow it, > you should start by stating clearly the scenario, and then > write in a more plodding and clear fashion. I apologize for the confusion. Here is the scenario. I will use concrete examples, but I believe it applies to many similar situations. Guile exists, and is under the Guile GPL. Another library exists which provides a readline interface for Guile. It is not necessary to link a Guile-using application against it when compiling; the user can cause the Guile interpreter to load this module at any time during the execution of any program that includes a Guile interpreter using the `dynamic-link' procedure. Neither Guile nor the application need to have any previous knowledge of this module. Let us assume for the sake of clarity that this module is distributed separately from Guile. Now, someone writes a proprietary application that links against Guile. It does not require the GPL'd readline module in any way, although it would benefit if a user chose to load it in. The author is not even necessarily aware that the GPL'd Guile readline interface exists. I believe in this case that if a user loads the readline module into the proprietary application's Guile interpreter, no violation of the GPL has taken place. I believe that the confusion stems from the fact that the term "dynamic linking" is used in two different ways: * To indicate linking a program against a shared library, as opposed to a static library, using the linker; in this case, the program requires the library to run. * To indicate loading an arbitrary piece of compiled code into a program at runtime, using the dlopen() family of functions. If a program allows a user to specify arbitrary shared object files to be loaded this way, it may be able to load and benefit from particular ones without in any way requiring them to run or depending on them for functionality. (Obviously if a program explicitly dlopen()s a given library at startup and requires it to function, this is no different from the first case). I have been referring to the second definition. Although the implementation technologies between these two kinds of "dynamic linking" are exactly the same, I believe the licensing implications are quite different. - Maciej Stachowiak