GPL Violation

[Haudy Kazemi]

Jeff Sadowski wrote:
> On Mon, Sep 28, 2009 at 10:11 AM, John Bailey <rekkanoryo at rekkanoryo.org> wrote:
>   
>> Jeff Sadowski wrote:
>>     
>>> Just curious how this is a GPL violation?
>>> It doesn't modify the pidgin binary does it?
>>> It is a plugin that uses pidgin right?
>>>       
>> Read http://pidgin.im/pipermail/devel/2009-September/008906.html.
>>
>> John
>>
>>     
>
> Ok then yup it is. One reason not to use gpl code if you want to use a
> proprietary plugin.
> Maybe they can move their plugin to some other app.
>
> This seems kind of messed up for a unified messenger.
> Does the skype plugin follow the same fate?
>
> I would think you would maybe want to use some closed source apps
> (like some OCR program for maybe doing captcha for you, like for the
> yahoo rooms) with a plugin through pidgin. That same stipulation makes
> it impossible to do, right? Or could you get around it some how?
>
> Or maybe a closed source protocol(like for some sort of unreleased
> encryption) for an IM that would also fit the same fate, right?
> (I would think things like this exist and I am curious that is the
> only reason I ask)
>   

This is an old problem and essentially endless debate.  There are 
non-GPL, binary only, modules available for the Linux kernel.  When 
loaded, the kernel is considered 'tainted'.  These modules are not 
used/installed/loaded by default but are available for download and 
installation by end-users themselves.  Several graphics card drivers are 
binary only as well as some virtualization drivers.  Is there really a 
significant distinction to be made between an optional kernel module and 
an optional application plugin?  The kernel module enables hardware 
capabilities, the software plugin enables IM interface capabilities.

Here is a pretty good overview:
http://blog.milkingthegnu.org/2008/04/gpl-for-dummies.html

http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLAndPlugins
If a program released under the GPL uses plug-ins, what are the 
requirements for the licenses of a plug-in?

    It depends on how the program invokes its plug-ins. 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.

    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 the plug-ins must be released under 
the GPL or a GPL-compatible free software license, and that the terms of 
the GPL must be followed when those plug-ins are distributed.

    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.

Other possibly relevant sections/posts/articles:
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLModuleLicense
http://www.fsf.org/licensing/licenses/gpl-faq.html#LinkingOverControlledInterface
http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html
http://thread.gmane.org/gmane.linux.kernel/475654/focus=475824
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20091001/423cb135/attachment.html>