On Wed, 27 Nov 2002, Philipp Müller wrote:

> If you call it as a library, this will not work. You cannot access non GPL
> conform libraries from GPL'd code. Even LGPL wouldn't help here. You can only
> access LGPL libraries from non GPL conform code (so only the other way round
> is allowed).

I understand that LGPL code may not depend on "non-free" code.  
I think the key difference is the plug-in architecture of 
libkspreadexport.  libpoi is *optional* and all other parts of KSpread 
will remain meaningful if libpoi is not supplied.  This may
meet the "good faith effort" required by section 2d) of the LGPL.

Even the GPL *may* be compatible with a Apache Licensed plugin, see:
http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
"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."

> I think the only way, how KSpread can use POI is if you encapsulate the POI
> part in a binary (which can still be Apache 1.1) and you call this binary via
> e.ge. pipes.

This would definitely be cleaner from a licensing standpoint.  If there 
would be no performance/coding time/feature loss, I'm all for it.

So as far as the licensing goes, I would argue that it may be compatible:
QT (we can select QPL license, compatible with Apache)
KDE/KSpread (LGPL license is compatible with Apache licensed *optional* 
plugins??)

I think the best way to clear this up would be to ask the FSF what they 
think.  I'll go ahead and do that, and let list know when I hear back 
from them.

-TJ

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel