GPL Violation

[Ismael Luceno]

I found a GPL violation related to Pidgin:
http://blog.mebeam.com/2008/07/pidgin-using-me.html

I know little about it, a friend of mine is using this plugin.

I downloaded it and asked for the sources a week ago, but got no response...



_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[Jeff Sadowski]

On Mon, Sep 28, 2009 at 1:58 AM, Ismael Luceno <ismael.luceno@...> wrote:
> I found a GPL violation related to Pidgin:
> http://blog.mebeam.com/2008/07/pidgin-using-me.html
>
> I know little about it, a friend of mine is using this plugin.
>
> I downloaded it and asked for the sources a week ago, but got no response...
>

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?

Off hand its like your claiming oracle is a gpl violation because they
wont share the source code for their database and they are using it on
linux.

>
> _______________________________________________
> Devel mailing list
> Devel@...
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>
>

_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[John Bailey-2]

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



_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[Jeff Sadowski]

On Mon, Sep 28, 2009 at 10:11 AM, John Bailey <rekkanoryo@...> 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)

>
> _______________________________________________
> Devel mailing list
> Devel@...
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>
>

_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[Marc Seiler]

On Mon, Sep 28, 2009 at 1:06 PM, Jeff Sadowski <jeff.sadowski@...> wrote:

>
> 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)
>

Well the skype plugin itself is open and the source code is available
so the plugin does not violate like the mebeam plugin. If it was like
that pretty much every protocol but xmpp iirc would be in jeopardy.
You have to understand that regardless of if the protocol itself is
closed source and violates the gpl doesn't matter as long as the
plugin itself being used is open and doesn't violate the gpl. Like I
said pretty much every protocol used in pidgin is a closed source
backwards engineered protocols.


 Thank you,
   Marc

_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[Peter Saint-Andre-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/28/09 11:32 AM, Marc Seiler wrote:

> On Mon, Sep 28, 2009 at 1:06 PM, Jeff Sadowski <jeff.sadowski@...> wrote:
>>
>> 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)
>
> Well the skype plugin itself is open and the source code is available
> so the plugin does not violate like the mebeam plugin. If it was like
> that pretty much every protocol but xmpp iirc would be in jeopardy.
> You have to understand that regardless of if the protocol itself is
> closed source and violates the gpl doesn't matter as long as the
> plugin itself being used is open and doesn't violate the gpl. Like I
> said pretty much every protocol used in pidgin is a closed source
> backwards engineered protocols.

A point of clarification: protocols are not "open source" or "closed
source", because IMHO the term "source code" refers to software and not
protocol specifications (yes, I have had long philosophical discussions
about this on the debial-legal list, but I shall spare you the details
here).  Let's not try to paint everything with the same brush. :)

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrA9OIACgkQNL8k5A2w/vwVkwCgsjkR8gJnn4wiY/d+fVdzGVx6
H2IAoPlp28f3s9UQUxbgu8UXdYEnPMjB
=Bazp
-----END PGP SIGNATURE-----

_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[Jeff Sadowski]

On Mon, Sep 28, 2009 at 11:32 AM, Marc Seiler <mseiler@...> wrote:

> On Mon, Sep 28, 2009 at 1:06 PM, Jeff Sadowski <jeff.sadowski@...> wrote:
>>
>> 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)
>>
>
>
>
> Well the skype plugin itself is open and the source code is available
> so the plugin does not violate like the mebeam plugin. If it was like
> that pretty much every protocol but xmpp iirc would be in jeopardy.
> You have to understand that regardless of if the protocol itself is
> closed source and violates the gpl doesn't matter as long as the
> plugin itself being used is open and doesn't violate the gpl. Like I
> said pretty much every protocol used in pidgin is a closed source
> backwards engineered protocols.
>

So its a structuring problem?
If they moved their proprietary code to a dll and made calls to it and
distributed a binary dll and open sourced the plugin that made calls
to the proprietary dll then it would be alright? Just curious?

>
>  Thank you,
>    Marc
>
> _______________________________________________
> Devel mailing list
> Devel@...
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>

_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[Ethan Blanton-3]

Jeff Sadowski spake unto us the following wisdom:
> So its a structuring problem?
> If they moved their proprietary code to a dll and made calls to it and
> distributed a binary dll and open sourced the plugin that made calls
> to the proprietary dll then it would be alright? Just curious?

No, because the GPL is transitive in this respect.  Linking to a
plugin which links to a GPL-incompatible plugin is also GPL
incompatible.

These issues are well hashed out on the Internet in various fora, and
there is not complete agreement on where all boundaries lie.  I
suggest that you look into previous FSF and Debian threads on this
matter, in particular.  The Pidgin mailing lists aren't really a place
for license lawyering.

In this specific case, the MeBeam plugin is directly loaded by Pidgin,
and therefore must necessarily be GPL-compatible, and it does not
appear that it is.

Ethan

--
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
                -- Cesare Beccaria, "On Crimes and Punishments", 1764


_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[Yao Ko]

On Mon, Sep 28, 2009 at 10:56 AM, Ethan Blanton <elb@...> wrote:

Jeff Sadowski spake unto us the following wisdom:

> So its a structuring problem?
> If they moved their proprietary code to a dll and made calls to it and
> distributed a binary dll and open sourced the plugin that made calls
> to the proprietary dll then it would be alright? Just curious?

No, because the GPL is transitive in this respect.  Linking to a
plugin which links to a GPL-incompatible plugin is also GPL
incompatible.

These issues are well hashed out on the Internet in various fora, and
there is not complete agreement on where all boundaries lie.  I
suggest that you look into previous FSF and Debian threads on this
matter, in particular.  The Pidgin mailing lists aren't really a place
for license lawyering.

In this specific case, the MeBeam plugin is directly loaded by Pidgin,
and therefore must necessarily be GPL-compatible, and it does not
appear that it is.

How about close-sourced UI that loads libpurple (eg. Meebo).  Is Pidgin GPL or LGPL?

Thanks,

Yao 

 

_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[Ethan Blanton-3]

Yao Ko spake unto us the following wisdom:
> How about close-sourced UI that loads libpurple (eg. Meebo).  Is Pidgin GPL
> or LGPL?

Again, this has been well-hashed-out in the Internet, and is not
really a topic for pidgin-devel.  This particular discussion has even
been previously hashed out on our mailing lists.  Please do some
research before continuing this thread.

The FSF and other bodies have more or less agreed that Internet
services need not open source their components, as the binaries are
not actually distributed to the user.  You may read the GPL yourself
to understand why this is important.  This was one of the impetus for
the GPL v3.

Ethan

--
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
                -- Cesare Beccaria, "On Crimes and Punishments", 1764


_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[Evan Schoenberg]

On Sep 28, 2009, at 1:03 PM, Yao Ko <yaoyao@...> wrote:

On Mon, Sep 28, 2009 at 10:56 AM, Ethan Blanton <elb@...> wrote:

Jeff Sadowski spake unto us the following wisdom:

> So its a structuring problem?
> If they moved their proprietary code to a dll and made calls to it and
> distributed a binary dll and open sourced the plugin that made calls
> to the proprietary dll then it would be alright? Just curious?

No, because the GPL is transitive in this respect.  Linking to a
plugin which links to a GPL-incompatible plugin is also GPL
incompatible.

These issues are well hashed out on the Internet in various fora, and
there is not complete agreement on where all boundaries lie.  I
suggest that you look into previous FSF and Debian threads on this
matter, in particular.  The Pidgin mailing lists aren't really a place
for license lawyering.

In this specific case, the MeBeam plugin is directly loaded by Pidgin,
and therefore must necessarily be GPL-compatible, and it does not
appear that it is.

How about close-sourced UI that loads libpurple (eg. Meebo).  Is Pidgin GPL or LGPL?

Meebo is not distributed, so licesning is (for better or worse) irrelevant in terms of the GPL. 

-Evan

Thanks,

Yao 

 

_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[Haudy Kazemi]

Jeff Sadowski wrote:

On Mon, Sep 28, 2009 at 10:11 AM, John Bailey rekkanoryo@... 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

_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[Jeff Sadowski]

On Wed, Sep 30, 2009 at 11:09 PM, Haudy Kazemi <kaze0010@...> wrote:

> Jeff Sadowski wrote:
>
> On Mon, Sep 28, 2009 at 10:11 AM, John Bailey <rekkanoryo@...>
> 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
>
> _______________________________________________
> Devel mailing list
> Devel@...
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>
>

_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[Mark Doliner]

On Thu, Oct 1, 2009 at 12:35 AM, Jeff Sadowski <jeff.sadowski@...> wrote:

> On Wed, Sep 30, 2009 at 11:09 PM, Haudy Kazemi <kaze0010@...> wrote:
>> Jeff Sadowski wrote:
>>
>> On Mon, Sep 28, 2009 at 10:11 AM, John Bailey <rekkanoryo@...>
>> 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

_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[Ethan Blanton-3]

Jeff Sadowski spake unto us the following wisdom:
> > 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.

No, that is NOT the case.  Pay attention.  Note that the specific
article you post requires *exceptions to the GPL*, for one.

A Pidgin plugin is intimately involved with Pidgin, and method calls
are made in both directions with some frequency during the lifetime of
the plugin usage.  Providing the Pidgin plugin interface for a complex
plugin without simply using Pidgin (or libpurple) would require
reimplementing a significant amount of software.  Therefore, a Pidgin
plugin is derived from Pidgin, and must be license-compatible with
Pidgin.  The GPL under which Pidgin/libpurple themselves are licensed
does *not* have any exceptions for closed-source libraries, so linking
with a GPL which does is incompatible.

You cannot circumvent the GPL with a little bit of indirection anad
some sleight-of-hand.  You might find the differences between the GPL
and the LGPL instructive for understanding this sort of thing.

Now, I'll say it one more time -- this list is not the place for
license lawyering.  If MeBeam wants to come talk to us about how to
resolve their license difficulties, that's fine, but random
speculation about how to most effectively circumvent the GPL is *not*
on-topic.

Ethan

--
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
                -- Cesare Beccaria, "On Crimes and Punishments", 1764


_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel

[Luke Schierer-5]

This whole discussion is more appropriate for  
discussion@...  than it is for a development mailing list.

Luke

On Oct 1, 2009, at 09:41 EDT, Ethan Blanton wrote:

> Jeff Sadowski spake unto us the following wisdom:
>>> 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.
>
> No, that is NOT the case.  Pay attention.  Note that the specific
> article you post requires *exceptions to the GPL*, for one.
>
> A Pidgin plugin is intimately involved with Pidgin, and method calls
> are made in both directions with some frequency during the lifetime of
> the plugin usage.  Providing the Pidgin plugin interface for a complex
> plugin without simply using Pidgin (or libpurple) would require
> reimplementing a significant amount of software.  Therefore, a Pidgin
> plugin is derived from Pidgin, and must be license-compatible with
> Pidgin.  The GPL under which Pidgin/libpurple themselves are licensed
> does *not* have any exceptions for closed-source libraries, so linking
> with a GPL which does is incompatible.
>
> You cannot circumvent the GPL with a little bit of indirection anad
> some sleight-of-hand.  You might find the differences between the GPL
> and the LGPL instructive for understanding this sort of thing.
>
> Now, I'll say it one more time -- this list is not the place for
> license lawyering.  If MeBeam wants to come talk to us about how to
> resolve their license difficulties, that's fine, but random
> speculation about how to most effectively circumvent the GPL is *not*
> on-topic.
>
> Ethan
>
> --
> The laws that forbid the carrying of arms are laws [that have no  
> remedy
> for evils].  They disarm only those who are neither inclined nor
> determined to commit crimes.
> -- Cesare Beccaria, "On Crimes and Punishments", 1764
> _______________________________________________
> Devel mailing list
> Devel@...
> http://pidgin.im/cgi-bin/mailman/listinfo/devel

_______________________________________________
Devel mailing list
Devel@...
http://pidgin.im/cgi-bin/mailman/listinfo/devel