Am 19. August 2020 19:27:09 MESZ schrieb Roman Gilg <[email protected]>:
On Wed, Aug 19, 2020 at 6:01 PM Sandro Andrade <[email protected]>
wrote:
On Sun, Aug 16, 2020 at 5:11 AM Roman Gilg <[email protected]> wrote:
>
> Hi,
Hi Roman,
> * Proprietary code static linking LGPL code is not practically
doable.
> [5] See also above ZeroMQ exception.
This is a topic every now and then pops around when discussing
licensing issues. The FSF is pretty clear in stating the providing
object files are enough to enable users to relink with different
versions of the LGPL library. I see some projects using LGPL + static
linking exceptions and I've read all the things regarding "work based
on the library" vs "work which uses the library", header
dependencies,
and so on but such LGPL exceptions look more like a clarification
point than a thing not already covered by LGPL.
I really don't see the point of comments like "If you statically link
a LGPL library, then the application itself must be LGPL. We have had
our lawyer double-check on this in the past. Dynamically linking to a
LGPL library is the only way to avoid becoming LGPL", presented in
the
stackoverflow link [5] you provided.
Could you elaborate a bit why this is not practically doable or
legally incorrect?
Hi Sandro,
no I can't. I was just rephrasing what I read in some sources online
and asking here for educated opinions on if this interpretation is
right or wrong. Thanks for taking the time to "debunk" some of the
myths floating around.
Do you see it the same way in regards to the usage of templates in C++
libraries licensed under the LGPL? Is this also a "non-issue" in the
end?
I think all of this is pretty much a non issue. You are looking at this
from the position of an engineer. But licenses are legal-speech and
would be interpreted by a judge. Most likely a judge does not have the
technical knowledge to understand the differences.
It is very unlikely that a judge would understand the implications of
different linker flags (static vs. dynamic linking). Anybody without a
high technical background won't understand that. What matters more is
the intention of the license. And that is clear. It's the "lesser" gpl.
And it would be interpreted like that. The (l)gpl was written with C in
mind. Adapting it to other languages is difficult for us, but probably
not for a legal person. A template library is a library. That it is kind
of static linking is an implementation detail. And here the intention
matters: if one would have wanted the gpl restrictions one would choose
gpl as license. But using lgpl clearly states that one doesn't want the
gpl restrictions to hold.
Granted all of that has not been tested in a court. Thus if one wants to
be clear it might make sense to dual license or use class path
exceptions, etc. But for our frameworks it's a non issue as we always
stated the intention: allow users of Qt's commercial license to use our
libraries. If a copyright holder would turn into a McHardy he would
hopefully lose at court, especially if we as the community would
contradict the claims.
Cheers and IANAL
Martin
