From: Matthew Palmer <mpalmer@debian.org>
I don't think it's a GPL violation. To my way of thinking, the derivatives graph would look like this (where "A --> B" means "B isa derivative work of A"): GPL'd library --> FTP plugin <-- plugin loader
[snip]
So, reading this, the FTP plugin is a derivative of the loader and the GPL'd library, so the FTP plugin's licence must be compatible with both of those (with the loader being MIT, the plugin could be MIT, BSD, GPL, whatever).
Sorry, no. It's the other way around -- if A depends on B and A is GPL'd, then B must be GPL-compatible (by the way, that isn't a restriction on B. It's a restriction on A: if B isn't GPL-compatible, you can't distribute A at all (wouldn't it be wonderful if I could release a GPL'd program for Windows and, voila! Windows must be GPL'd (of course forgetting that the GPL makes an exception for code "normally distributed with the operating system" (whoa, too many nested parentheses. Stop that madness now!)))). But if it's B that is GPL'd, then A must be GPL'd too.
So, the FTP plugin's license must be _the GPL_, and it must not depend on GPL-incompatible code.
That said, it looks questionable whether the FTP plugin should really be considered a derivative of the plugin loader. If the latter has a documented API and the former only communicates with it through that API, I'd probably say no. Even more so if that plugin could conceivably work with another, non-GPL'd plugin loader.
Gerardo Ballabio