[IPython-user] Any future integration with pydbgr planned?

Flavio Coelho fccoelho@gmail....
Tue Jan 26 03:43:09 CST 2010


Hi Fernando,

Thanks for the references and for clarifying the issue with dynamic
linking<http://en.wikipedia.org/wiki/Library_%28computing%29>.
I personally don't think that dynamic linking should be considered
derivative work, but that debate is likely to rage on for years.

Reading up on the wikipedia article you pointed, I think I found a safe way
for Ipython to include support for pydbgr. Check out this quote from the
 FSF site:


*Can I apply the GPL when writing a plug-in for a non-free program?*

If the program uses fork and exec to invoke plug-ins, then the plug-ins are
separate programs, so the license for the main program makes no requirements
for them. So you can use the GPL for a plug-in, and there are no special
requirements.

If the program dynamically links plug-ins, and they make function calls to
each other and share data structures, we believe they form a single program,
which must be treated as an extension of both the main program and the
plug-ins. This means that combination of the GPL-covered plug-in with the
non-free main program would violate the GPL. However, you can resolve that
legal problem by adding an exception to your plug-in's license, giving
permission to link it with the non-free main program.

See also the question I am writing free software that uses a non-free
library. <#FSWithNFLibs>
*Can I release a non-free program that's designed to load a GPL-covered
plug-in?*

It depends on how the program invokes its plug-ins. For instance, if the
program uses *only* simple fork and exec to invoke and communicate with
plug-ins, then the plug-ins are separate programs, so the license of the
plug-in makes no requirements about the main program.

If the program dynamically links plug-ins, and they make function calls to
each other and share data structures, we believe they form a single program,
which must be treated as an extension of both the main program and the
plug-ins. In order to use the GPL-covered plug-ins, the main program must be
released under the GPL or a GPL-compatible free software license, and that
the terms of the GPL must be followed when the main program is distributed
for use with these plug-ins.

If the program dynamically links plug-ins, but the communication between
them is limited to invoking the ‘main’ function of the plug-in with some
options and waiting for it to return, that is a borderline case.

Using shared memory to communicate with complex data structures is pretty
much equivalent to dynamic linking.

See also the question I am writing free software that uses a non-free
library. <#FSWithNFLibs>



>From the above text it would be perfectly fine to invoke the debugger as
long as it was ran on a separate process, as is frequently the case with
debuggers. On the (pydbgr) project page, The ability to debug a program from
a separate process is presented as a design feature!
Please note that with this suggestion, I am not trying to diminish the
threat posed by the GPL to the Ipython code. But only to point out that
there are ways to achieve compatibility, if necessary.

best,
Flávio

On Tue, Jan 26, 2010 at 7:38 AM, Fernando Perez <fperez.net@gmail.com>wrote:

> On Mon, Jan 25, 2010 at 10:44 PM, Flavio Coelho <fccoelho@gmail.com>
> wrote:
> > another link:
> >
> >
> http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
> >
> > I hope this links, although not sufficient to educate a decision on how
> to
> > mix licenses, may help to steer this discussion in the right direction.
> >
>
> This goes in the other direction, which isn't relevant for this
> discussion.  The key point is well summarized by this wikipedia
> section:
>
>
> http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works
>
> It all amounts to whether dynamic linking (of which python runtime
> import is an extreme form) triggers the 'derived work<http://en.wikipedia.org/wiki/Derivative_work>'
> provisions of
> the GPL <http://en.wikipedia.org/wiki/GNU_General_Public_License> and
> hence its copyleft <http://en.wikipedia.org/wiki/Copyleft> effects.   As
> you can see, this is a
> highly contentious point, and one on which lawyers have weighed but
> without a definitive resolution in court.
>
> The last thing we want to do is to drag ipython into such a quagmire;
> fundamentally I think the best approach is to contact code authors of
> GPL code we may want to use in IPython.  If they feel that using
>
> import foo
>
> from their code truly demands that the code doing so becomes GPL, then
> we are not going to go over their position on their own code
> (regardless of how much case law may or may not exist on the matter).
> But if they ultimately only want to ensure that their code isn't
> modified without changes being contributed back, they may be willing
> to consider an LGPL<http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License>or BSD
> license <http://en.wikipedia.org/wiki/BSD_licenses>, both of which make it
> trivial then
> to use their tool in ipython (since the *L*GPL has no copyleft
> provisions).
>
> Cheers,
>
> f
>



-- 
Flávio Codeço Coelho

 Zemanta <http://www.zemanta.com> helped me add links & pictures to this
email. It can do it for you too. <http://www.zemanta.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/ipython-user/attachments/20100126/f39efc2e/attachment-0001.html 


More information about the IPython-user mailing list