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]

Re: libguile and readline


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