mark at kingant.net
Thu Oct 1 04:30:47 EDT 2009
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>
>> 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.
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).
More information about the Devel