kaze0010 at umn.edu
Thu Oct 1 01:09:36 EDT 2009
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.
> 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:
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
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:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel