Big development in the GUI realm

Jeff Shannon jeff at ccvcorp.com
Tue Feb 8 16:18:41 EST 2005


Maciej Mróz wrote:

> However, imagine simple situation:
> 1. I write proprietary program with open plugin api. I even make the api 
> itself public domain. Program works by itself, does not contain any 
> GPL-ed code.
> 2. Later someone writes plugin using the api (which is public domain so 
> is GPL compatible), plugin gets loaded into my software, significantly 
> affecting its functionality (UI, operations, file formats, whatever).
> 3. Someone downloads the plugin and loads it into my program

I believe that in this case, the key is *distribution*.

You are not violating the GPL, because you are not distributing a 
program that is derived (according to the GPL's definition of derived) 
from GPL code.

The plugin author *is* distributing GPL-derived code, but is doing so 
under a GPL license.  That's fine too.

The end user is now linking (dynamically) GPL code with your 
proprietary code.  However, he is *not* distributing the linked 
assemblage.  This is allowed under the GPL; its terms only apply when 
distribution takes place.

If the end user is a repackager, and then turns around and distributes 
both sets of code together, then that would (potentially) violate GPL 
terms.  But as long as they're not distributed together, then it's 
okay.  This should even extend to distributing a basic (proprietary) 
plugin and including a document describing where & how to get the 
more-featureful GPL replacement plugin.  (Distributing both programs 
as separate packages on a single installation medium would be a tricky 
edge case.  I suspect it *could* be done in a GPL-acceptable way, but 
one would need to take care about it.)

Of course, this is only my own personal interpretation and opinion -- 
IANAL, TINLA, YMMV, etc, etc.

Jeff Shannon
Technician/Programmer
Credit International




More information about the Python-list mailing list