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


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