Dynamic linking, was: Re: Dispelling BSD License Misconceptions

[Ben Tilly]

On 1/18/07, Matthew Flaschen <matthew.flaschen at gatech.edu> wrote:
> Ben Tilly wrote:
> > On 1/18/07, Matthew Flaschen <matthew.flaschen at gatech.edu> wrote:
> >> Chuck Swiger wrote:
> >>
> >> Sticking to the example of readline and Python, part of the code is
> >> still specifically written to depend on readline.  I think under Eben's
> >> argument, this part would then be a derivative work.  Thus, that part at
> >> least should be licensed under the GPL.
> >
> > I can't speak to Python, but I can to Perl.  The situation is nowhere
> > near as simple as you describe.
>
> To clarify, I wrote that text, not Chuck.

I did not intend to confuse.

> > There is a module, Term::ReadLine, that is distributed with the Perl
> > core.  This module is a stub, it allows people to interface to one of
> > (currently) three implementations of readline.  The first will load a
> > module (available on CPAN) that provides a Perl interface to the GNU
> > application.
>
> IANAL, but I think this is most likely to be a derivative work of readline.

Agreed.

> > Here is my opinion as a non-lawyer who can't give legal advice.  It is
> > obvious to me that no part of Perl outside of Term::ReadLine depends
> > on or is derivative from the GNU implementation of readline.  I
> > strongly doubt that Term::ReadLine can be said to be derivative of
> > readline.  I suspect that the author of Term::ReadLine::Gnu may be
> > overstepping when he licenses his module  under a dual Artistic/GPL
> > license.  (See the README file at
> > http://search.cpan.org/~hayashi/Term-ReadLine-Gnu-1.16/ for details.)
>
> I don't follow.  If you say his code is not derivative of anything,
> shouldn't he be able to choose whatever license he wants?

I didn't say that.  Or rather, I said that about another piece of
code.  Here are the pieces of code of interest:

1. Perl minus Term::ReadLine
2. Term::ReadLine
3. Term::ReadLine::Gnu
4. Code written in Perl

I think the first is obviously not derivative, the second I strongly
doubt is derivative, the third I'm inclined to think would be (but
don't feel qualified to judge), and the last is generally not but in
some cases could be.  There is no contradiction between my opinions on
item 2 and 3 because they are about different pieces of code with
different histories.

> >> This isn't quite the same thing.  Readline wasn't written to an existing
> >> Python plugin API.  Part of Python was written to interact specifically
> >> with readline.
> >
> > I suspect that Python did what Perl does.  (Possibly with less
> > pieces.)  In which case Python is written with a general plugin API,
> > and someone wrote a Python plugin around readline.  I suspect that
> > what is actually distributed with Python is a stub like the Perl one
> > so the situation is completely parallel, but the Python stub may be
> > more filled in than the Perl one is.
>
> I think this hypothetical plugin/stub is most likely to be a derivative
> work.

I'd agree, but of the two the plugin is more likely to be derivative
than the stub.  Without seeing that stub I won't even venture my
unqualified opinion about whether I think it is derivative.  (I've
seen the Perl stub and I scrolled through the source-code.  It is so
minimal and generic that I don't think it is derivative of anything.)

Cheers,
Ben