Daniel Russel wrote: > What we would be doing would doing would not be in a grey area.
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 - the argument going that the actual link against GPL code was not done by the distributor but by the user themselves when they run the program; but it seems to have been settled that dynamic and static linking are legally the same thing here, which IMHO is the only sensible conclusion).
> They key > thing is that anything that is LGPL can be automatically "upgraded" to > GPL just by linking against a GPL (see the GPL compatibility matrix in > the GPL FAQ). So we can release most of IMP under LGPL but anyone can > make the choice to make their program GPL just by using a GPL module.
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. 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 (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). That is really academic though, because IMP is not LGPL licensed, so we don't have that "upgrade option". It may become so (and that is certainly my position) but it is by no means certain. 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. So unless there is really no other way, we should avoid GPL code for now.
Ben