Plugin Arch. for KDevelope 2.0
Richard Dale
Richard_Dale at tipitina.demon.co.uk
Mon Jul 30 15:47:18 UTC 2001
On Mon, 30 Jul 2001, you wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am Montag, 30. Juli 2001 15:37 schrieben Sie:
> > Java makes it easier to distinguish between using the api, and deriving
> > works from the sources of the code behind the api. To me, writing a plugin
> > in C++ counts as just using the api, and not deriving from the code. The
> > fact that you have to include headers of source code to use an api with
> > C++, is a language problem - it shouldn't need to cause a license problem
> > too.
>
> Ralf cited a very interesting text from the FSF.( GPL FAQ) If you are running
> a GPL program and link dynamicly the plugin and it makes some calls to the
> program, the plugin must be GPL or compatible.
> How do you have solved the java intergration? Are the Java classes in the
> some addresspace and make some communication with KDevelop? If yes they must
> be GPL as I understand it.
They use JNI which is a special kind of dynamic linking, in the same address
space. The distinction 'same address space' sounds a bit contrived to me - what
about background thread code which might not need to interact with the main
thread other than via the scheduler, or an app made up of several processes
communicating via data structures in shared memory?
I would certainly like people to be able to use any license they like, for the
Java sources they write using the bindings I've produced. Perhaps the Qt and KDE
java bindings need to be LGPL'd, rather than GPL'd. And the KDevelop
Java plugin api should have an identical license to what gets decided for the
C++ one.
I would have thought that a 'plugin' can't be part of the main program
by definition - it wouldn't be a plugin otherwise :-). You could structure your
program out of dynamically called KParts (to minimise memory usage or
whatever), in exactly the same manner technically as gideon, but not publish the
apis. It would then not have a plugin api, and any code using these internel
apis would need to conform to the GPL. Linux has loadable kernel modules which
are allowed to be non-GPL - KDevelop plugins seem to be in the same category of
components as those to me.
-- Richard
-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«
More information about the KDevelop-devel
mailing list