Plugin Arch. for KDevelope 2.0

[Ralf Nolden]

On Monday, 30. July 2001 10:43, you wrote:

> Ok, good topic. I think we should discuss and decide now wether we allow
> commercial plugins,closed source, open source or freeware plugins for
> KDevelop 3.0.  I think with more and more third parties will develop
> plugins this issue will be raised sometimes and we should have an answer.
> I would like to have following agreement:
>
> It is allowed to develop commercial or freeware software (GPL,BSD..) but
> the plugin must be available with sourcecode. (maybe open source
> compatible?) There are many reason for this.
> 1) Personaly I don't want a situation where Gideon is running on FreeBSD on
> Alpha (this should be possible) but the plugin is only available on
> Linux/i386.
> 2) If there is a bug the user can fix it and don't need to wait for a new
> release
> 3) The libraries will sometimes not binary compatible (you know Linux is
> sometime really uncool on this issue), with sourcecode you can make an
> recompile and use it with new Gideon version.
>
> Ok, this are my thoughts about plugin licensing. Would do you think?

Moin Sandy and the others,

well, my opinion on this is that we should allow any closed source plugins. 
The problem I see is that we should need to clear out if this is possible at 
all with our GPL licensing, that means, can a commercially developed plugin 
be used with the GPL'ed gideon or not ? I should write to RMS concerning this 
issue so I get a clear answer that we can put into the package as a readme 
and into the manuals. The templates for projects should be free of use for 
any kind of development like we have until now for kdevelop, so that we can 
answer questions like "can I develop closed source software with kdevelop ?" 
"Yes, you can.".

The reason I vote for even allowing closed source stuff is that if we want to 
enforce free licensing it will be very easy to do but on the other hand that 
means that for example a company like Siemens who wants to add an 
inhouse-plugin would be required to publish it. As they don't want to do that 
for reasons that go beyond our scope, we're putting bricks in their way to 
deploy and use kdevelop in that area. Imagine them to add a plugin for 
scientific calculations that makes that very easy to handle. It isn't much of 
a use for us and the general mass of the developers, but for their 
competitors. With gideon open for all kinds of development, we just should 
make clear that (as said, if possible) commercially developed, closed source 
plugins can be written and used.

If someone wants to make money with a plugin for gideon, well, go ahead I'd 
say. The free software movement will probably deploy possibly useful plugins 
and maybe write a free replacement if desired, so I quite don't see the point 
of prohibiting commercial development or enforcing an open source license, 
although I generally prefer that. 

I think we're the party that is responsible for taking care of a clear API 
for writing plugins and providing: The framework of gideon, the plugin api, 
development facilities by default provided for languages that we support (C, 
C++, Java, Perl, Python, PHP, anything else yet ?). Then we have done our job 
in the best way we could do and still keep everything open for enhancements. 
I'd see third-party software developers who want to write plugins for gideon 
as our partners and they may or may not have a different opinion on free 
software that we have. Limiting our possible partner's possibilities would 
mean (to me, if I were a partner of that kind), go away, we don't want 
"unfree" software!. That would also affect the development of closed 
source/need-to-pay-for applications/plugins for the KDE desktop because an 
enforcement of opensource kdevelop plugins to the producers of software 
implicitely would give them the message that they can only deal with KDE by 
means of opensource/free software. That would be the wrong message I'd say.

Sandy, I see the good meaning of your proposal, but the thing is that we're 
providing our stuff the way we want, what everyone else wants to do should be 
their freedom. (free in the sense of free to choose, not free beer :))

Any objections ? comments ? 

Ralf
>
> Ciao!
> Sandy
>
> --
> for verifying my signature or send encryted emails:
> ftp://fara.cs.uni-potsdam.de/stud/smeier/public_key
>
>
> -
> to unsubscribe from this list send an email to
> kdevelop-devel-request at kdevelop.org with the following body: unsubscribe
> »your-email-address«

-- 
We're not a company, we just produce better code at less costs.
--------------------------------------------------------------------
Ralf Nolden
nolden at kde.org

The K Desktop Environment	The KDevelop Project
http://www.kde.org		http://www.kdevelop.org


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