> > What is the final outcome of the license issue?

> The libkspreadexport is GPL2.
> So far, for the excel filter, it's only a framework, so GPL2 also.

Thanks, I asumed this already ;-)

> In a week or too, POI will be integreted in the framework, but called as a

> library, and this library is Apache license 1.1.

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 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.

> Also, it is java and gcc (gcj) dependant. If javac, ant and also gcc is
not on 
> the end user box, then the library can not be created, and the excel
filter 
> shall be disable.

I'm fine with that. This is still better than what we have today.

To be clear, I like your work.
But there is no way that I will agree that we will bind it in a non GPL
conform way. Onto KDE was trown enough mud in the QT 1.x times, which we need to
avoid at any circumstance.

So, do you think it's possible to split the filter into 2 parts. One is the
part which comunicates between KSpread and the binary (which then can be
LGPL) and the other one is the binary, a framework around POI (which is propabely
Apache 1.1 licenced and doesn't use i.e. QT and kdelibs) and accessed via
pipes?

I don't know of pipes are the best, if you have better alternatives, just
use them. But you cannot link them.

And of course I'm not a lawyer and one of the FSF, I only have read the
articles/FAQs from FSF.

Philipp

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!

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