GPL Violation

[Mark Doliner]

On Thu, Oct 1, 2009 at 12:35 AM, Jeff Sadowski <jeff.sadowski at gmail.com> wrote:
> On Wed, Sep 30, 2009 at 11:09 PM, Haudy Kazemi <kaze0010 at umn.edu> wrote:
>> 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
>
> Sweet perfect this answers my question exactly and could be a way for
> them to re-release their plugin that would satisfy the gpl
> by making it a lib. Like I said earlier its a structuring issue.
>
>> 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

Er, I think Linus's view tends to differ from the Free Software
Foundation and from many developers of this project.  Our opinion
tends to be that it is a violation of our license to distribute a
non-GPL compatible plugin or any plugin that links against a non-GPL
compatible library.  So it would not be acceptable to us to just make
the plugin a library.  You would need to move the non-GPL compatible
parts of the plugin into a standalone system with a high-level API
(not just some form of remote-procedure call).

-Mark