jeff.sadowski at gmail.com
Thu Oct 1 03:35:42 EDT 2009
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>
> 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 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:
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.
> Devel mailing list
> Devel at pidgin.im
More information about the Devel