Plugin Arch. for KDevelope 2.0

[Richard Dale]

On Tue, 31 Jul 2001, you wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am Montag, 30. Juli 2001 17:47 schrieben Sie:
> >
> > 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 
> Yes, but if you allow this you break the philosophy of GPL. One of the main 
> point in GPL is, that every extension and enhancement to a program should be 
> available under GPL. Our plugins are extensions of the program (they wan't 
> run without it) so they must be GPL if they want to be legal. (See GNU GPL 
> FAQ) Maybe we can make an exception but then I think than we don't need the 
> GPL anymore as we removed one of the main part. 
I must go and read the FAQ. But I think the point I'm trying to make is that
the GPL shouldn't need to extend to cross program boundaries where levels of
abstraction are changing. The code for interfacing a KDE widget with java
runtime and wrapping a widget to implement an api, has nothing to do with using
the api to write java KDE widget application code. So people could send me all
their interesting widget application code, and it could never be used to
enhance the bindings (apart from helping to find bugs). 

I think the boundary between the main KDevelop code, and the code in a plugin
is more blurred. There isn't a change in abstraction - plugin code could end up
being used by the main app's code and vice versa. And the KDevelop codebase
includes plugins, which must be at the same level of abstraction. But declaring
an api to be public is in itself making an abstraction of some sort.

It would be bad if nobody could write commericial Linux apps because the kernel
is GPL'd. But it seems accepted by everyone, other than Microsoft, that you
can mix GPL and non-GPL code in the same app, when you write an application
which makes kernel calls. I think the reason for this is that kernel code
doesn't have any relation to the code in typical applications running in the
user space.

> I can understand your intention very good, but if we really want closed 
> source plugins in KDevelop, we must change the license (not only for the 
> interface) but then it's not a GPL project anymore in my opinion. :-(
I think I'll carry on putting GPL headers in any stuff I write then, and
only think about other licenses if it causes some problem for somebody
else. Only :-( for the suits...

In practice, I can't see closed source KDevelop plugins doing very well because
developers like to have source they can change. A closed source company would
be at risk from someone hacking together an open source replacement, and losing
them all their market share overnight. Also I use a PowerPC machine, and I bet
they wouldn't run on that, or any unusual architecture.

-- Richard

-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«