Proper license for plugins

[Marcus Breese]

This is usually done with an LGPL or Apache style license, depending
on your goals.  I appologize, I've only started reading this thread.

Basically, the crux is how the plugins are linked.  If they require
code from the container to be linked in, then the container's license
must be compatible with commerical or open-source plugin licenses.  If
you'd like to keep the container as viral open-source, then the LGPL
would be appropriate.  In this case, plugins could be whatever license
the author would wish.  This is an inversion of the typical
application/library interaction, where the library is usally LGPL, but
I don't see that as a problem.

At least, that is my reading of the LGPL, I could be very wrong.

If you don't care about commercial derivatives of your container code,
then a more liberal license might be better suited (Apache, BSD, AFL).

In this case, what really matters is the interface.  How the interface
is licensed and accessed (language dependent) matters.

Oh, IANAL, etc...

Marcus Breese


On Mon, 17 Jan 2005 10:36:47 -0800, Kelly Anderson <kelly at acoin.com> wrote:
> I appreciate your replies on this apparently complex subject. I've learned
> a lot from your answers, and most particularly the additional details that
> you might need to help me make a more informed decision.
> 
> To clarify based upon your feedback, what I'm thinking about is creating a
> "base" or "core" program that can be dynamically "modified" with one or
> more DLL type plug-ins. These plug-ins would function in an analogous way
> to the old inside-out OLE widgets. That is, they can (temporarily and
> dynamically) modify the menus of the containing program, swap out the main
> contained view entirely, but they don't modify the code of the container
> per se since it's all done dynamically at runtime.
> 
> My objective is to create a "shell" for a particular kind of program (in
> the particular case I have in mind, it's an email shell) that contains a
> default implementation (a simple email client in a DLL that would itself be
> released under something like the BSD license and would serve as an example
> program) but which can be modified for specific uses. For example, you
> might create a special plug-in for lawyers that added features to allow
> them to keep track billing clients for time spent on email. I would want
> people to be able to create and sell these plug-ins as commercial code or
> as open source code. There are cases where someone might put a huge amount
> of effort into developing a plug-in that they might want to be able to sell
> to someone else.
> 
> Of course, if someone wanted to release a plug-in as GPL, BSD or whatever,
> that is all right with me as well.
> 
> While I agree with most of the basic points made by the open source and
> free software folks, I do not share RMS's apparent hatred for the
> commercial environment. Without commercial software, there would be no way
> for me to feed my family. I like seeing them eat. I see that there is room
> for both open source and closed source programs. However, the effort
> required to create the container is part of what I would see as the old
> style precompetitive collaboration that occurred in the 50s and 60s to
> develop the building blocks like compilers and operating systems. After
> that, it was open season for commercial development.
> 
> This link was particularly informative, thank you:
> 
> >http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface
> 
> This additional language could work, but if you add this, is it REALLY
> still GPL? And if the controlled interface allows you to change the
> containing program's menus and such is it really in the spirit of what was
> imagined by the GNU people?
> 
> -Kelly
> 
>