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
--
http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle