MPL2 instead of LGPL

[Sandro Andrade]

On Sun, Aug 16, 2020 at 5:11 AM Roman Gilg <subdiff at gmail.com> 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?

Cheers,
Sandro