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