[Olsr-dev] olsrd 0.5.5 released
Sat Feb 9 21:35:12 CET 2008
On Feb 9, 2008 9:02 PM, Andreas Tønnesen <(spam-protected)> wrote:
> On Feb 9, 2008 7:45 PM, Bernd Petrovitsch <(spam-protected)> wrote:
> I never understood the linking-to-GLP-code issue the way that Holger(and others)
> seem to do.
> Dynamic linking trough a user-edited configuration file cannot really be
> controlled in any way. So as long as we do not:
> I Link to the plugin statically
> II Load the plugin by default(default config)
> I really would never have figured this to be a problem. Yes, a GPL plugin
> is distributed with the olsrd source, but so what? We do not use it/link
> to it per-se. The user can change the olsrd configuration in a way that
> causes the library to be loaded, but that is really the users problem...
> (AFAIK the quagga plugin is not loaded by default)
> Am I wrong about this? Can a BSD application NOT include a GPL licensed
> shared library in the source distribution??
Can I apply the GPL when writing a plug-in for a non-free program?
If the program uses fork and exec to invoke plug-ins, then the
plug-ins are separate programs, so the license for the main program
makes no requirements for them. So you can use the GPL for a plug-in,
and there are no special requirements.
If the program dynamically links plug-ins, and they make function
calls to each other and share data structures, we believe they form a
single program, which must be treated as an extension of both the main
program and the plug-ins. This means that combination of the
GPL-covered plug-in with the non-free main program would violate the
GPL. However, you can resolve that legal problem by adding an
exception to your plug-in's license, giving permission to link it with
the non-free main program.
"Wo kämen wir hin, wenn alle sagten, wo kämem wir hin, und niemand
ginge, um einmal zu schauen, wohin man käme, wenn man ginge." (Kurt
More information about the Olsr-dev