Re: License Compatabilities and KPlugin

On Monday 24 November 2014 08:38:56 Andreas Cord-Landwehr wrote:
> Hey, I would like to hear some opinions whether the following is possible.
> The setting is as follows:
> 
> * a GPL-2+ application that uses an internal LGPL+2.1+ library
> * the library has a plugin structure with the help of KPluginFactory
> 
> Now, I want to add a new plugin to the application libraries' plugins that
> links to an (external) EPL-1 licensed library, whereas we all know that EPL
> is incompatible to GPL. I know that I could write that plugin with some
> BSD- licensed (or maybe better dual-licensed BSD & LGPL ?) classes to solve
> all issues inside the plugin.
> 
> But what I wonder is, is the KPluginFactory mechanism implemented in such a
> way that I can actually *use* the plugin, i.e., load it with KPluginLoader
> and create it by factory->create()?

Well, as I understand it, the "derived work" status of dynamically-linked code 
is still a bit of a gray area from a legal standpoint. The FSF stance is that 
an application or library A that dymanically links against a library B counts 
as a derived work of B (and thus subject to any licensing constraints). A 
plugin C written to an interface of library B (and almost certainly linking 
against B) would, logically, also count as a derived work of B.

As for how A and C interact, that probably (I should stress that IANAL) 
depends on the licenses. Notably, the GPL does not restrict *use* of the 
software, but only *distribution* of the software. Assuming C (linked against 
B) is legal to distribute, and A (also linked against B) is legal to 
distribute, I would suspect that there is no problem. That said, if A (or B) 
is dependent on C for proper functioning, that may change things.

Note: I'm fairly confident there's nothing special about the implementation of 
KPluginLoader that makes it different from any other common-or-garden plugin 
mechanism, from a legal standpoint at least.

Alex