Dynamic linking, was: Re: Dispelling BSD License Misconceptions

[Matthew Flaschen]

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.

> 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.

> 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?

>> 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.

>> Also, Chuck, please don't CC list members to list mail, unless they ask
>> you to.
> 
> Um, that's going to happen by default for most people.  The emails
> arrive from the sender and CCed to the list, so "reply all" is going
> to reply to both sender and list.

It happens by default for me too.  Some people take the trouble to fix
it, and some don't.

> I manually edited things to not double send to you this time.  But I
> won't guarantee to remember in the future.

Understood.

Matt Flaschen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20070118/8c610950/attachment.sig>