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] |
Maciej Stachowiak <mstachow@alum.mit.edu> writes: > Richard Stallman wrote: > > > > Dynamic linking does to some extent make a difference here. If I, > > as a user, dynamically link a GPL'd library using Guile's dnamic > > linking capability at runtime into a Guile-using proprietary > > application, I don't believe anyone has violated the GPL. > > > > Our position is that this does violate the GPL. We do not give > > permission for our GPL-covered code to be used in this way. > > Who is violating the GPL in this situation? There are three parties > involved, the user loading the library at runtime, the author of > the GPL'd library, and the author of the proprietary application. > [... the expected expansion followed... ] Perhaps we are seeing things too narrowly for legal purposes here, by evaluating legality in purely technically terms. Clearly, any library with a stable API can be linked in at run time by a user running a proprietary application (assuming the application is compatible with the API). If the author of that application was helpless to prevent this choice, then she obviously cannot be in violation of the GPL. However, if the application is designed in such a way that it is not truly functional until a certain specific GPL'd library (say, Guile) is linked in, and the application's users are explicitly expected to do so, then Guile is effectively a part of the application even though they were not distributed together, and the proprietary application is violating the GPL. This is not a distinction that can be made on technical grounds alone. It is, however, a judgement call of the sort that courts are often called on to make. I don't know offhand if the language of the GPL could be interpreted this way. I would think that in computer software, physical proximity would be less relevant than "functional proximity". Dependency ought to be a tighter bond than "mere aggregation", even when the two entities are not aggregated at all. If package A effectively _must have_ publicly-available package B to run, then the fact that packages happen not to be distributed together doesn't really change the fact that package B is part of package A (or vice-versa), IMHO. Of course, IANAL, which is sometimes frustrating. Just my $0.02. Quite probably others (RMS?) have been down this line of thought and could clarify..., -Karl