> > > > I was referring to the gray area regarding dynamic linking (once upon a > time there was some legal debate over whether dynamic linking > constituted "use" of a GPL package in the same way as static linking -
Sure, we all agree that dynamic linking is linking...
> The GPL FAQ states that indeed, you can convert an LGPL binary to GPL > without violating the terms of the original LGPL license. But it doesn't > mean that you can link an LGPL library against GPL - you have to change > the license to GPL in this case. > Sure. But changing the license on some files is free and trivial. You just say "The license is X" in the distribution docs.
> So if IMP.em linked against GPL code, > either a 3rd party library or a GPL IMP module, that means we would have > to also convert its license to GPL
Almost: If someone distributes an application which links against IMP.em and GPL code then they have to relicense IMP.em under GPL and we have given them permission to do so (by using LGPL).
> (the only way around that would be > ifdef out the usage of that GPL module, then we could continue to use > LGPL for versions not linked against the GPL code).
The copyright statement is english text, not C++ code, so ifdefs are irrelevant :-) There is no necessary reason for the license to appear in the source at all (very few headers in /usr/include put the license in the actual header).
> Andrej at least wishes to maintain > control over IMP, including the ability to change the license if we so > desire. Linking against GPL code would prohibit that.
Linking against GPL code now has no effect on what we do in the future. We can always relicense it later. All GPL says is that anyone who we give an application which is GPL too must be able to get a copy of the source code and that they can't change the license to anything more restrictive. We can do whatever we want with it.
> So unless there is > really no other way, we should avoid GPL code for now.
Sure, but nor should we reimplement things just because they happen to be GPL.