Plugin Arch. for KDevelope 2.0

[Ralf Nolden]

On Monday, 30. July 2001 11:53, you wrote:

As a sidenote, a commercial vendor is responsible for providing a working 
version of their plugin for what they support. Its their customers that don't 
get that certain affected plugin to work and not kdevelops fault if it 
doesn't but the company that produced it. So generally companies will 
probably ship the sourcecode with their product to ensure that the customer 
can adapt the code to his system if needed. Otherwise they're limiting their 
customer base anyway.

Ralf
> 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«