LGPL is a bad practice
######################

:category:  Misc
:date:      2023-01-02 16:30:00 +0200
:tags:      licensing, lgpl, copyleft

TL;DR: Don't use LGPL, avoid library-based copyleft in general.

The closest acceptable no-brainer replacement should be `GNU GPL`_ with `Classpath Exception`_,
but the concept of library-based copyleft itself is flawed.
It's better to consider MPL_ (less copyleft) or `full GPL <GNU GPL_>`__ (more copyleft).

.. TEASER_END

First I want to point out
that I don't want to advocate against the GNU GPL here even if I don't like it
and that in the past I even released `an LGPL licensed package`__ once.

.. __: link://slug/journald-native

.. note:: *Why jounrald-native is LGPL?*
   To be in sync with libsystemd.
   That's the only reason, I don't care otherwise.

The bad practice of LGPL comes from a different source than my problems with GPL: the concept of linking.
LGPL defines its borders by dynamic linking that may be meaningless in many languages, or maybe in most languages outside of C and C++ world.

* Interpreters. What would be legally considered linking?
  If LGPL'd library stays in a package form it's technically ok but where the borders are?
  Can I copy a file under LGPL into the source tree?
  Can building a phar_ file be considered a static linking process?
  What if I take a library and compile it with HipHop_ or KPHP_?
  Only questions here, even GPL/Classpath won't help.

* Modern weird statically compiled languages (Go).
  Since there is no dynamic linking, LGPL is functionally equivalent to GPL.

* Languages where dynamic linking is OK (Rust).
  Depending on the generated binary there may be a C-style interface + proper compilable interface for the language itself.
  (like cdylib + extern or IDK, I don't code Rust, sorry)
  There would be a big question if this glue code would also licensed under LGPL.

* Misunderstanding may happen even in C/C++ world, imagine a template or macro-only library somehow licensed under LGPL.

All these examples make edge cases for LGPL enforcement very unclear.
On the contrary, file based copyleft (MPL_, EPL_) and project based copyleft (`GNU GPL`_) have more or less clearly defined borders.

.. _phar: https://www.php.net/manual/en/book.phar.php
.. _HipHop: https://en.wikipedia.org/wiki/HipHop_for_PHP
.. _KPHP: https://vkcom.github.io/kphp/

.. _MPL: https://www.mozilla.org/en-US/MPL/
.. _EPL: https://www.eclipse.org/legal/epl-2.0/
.. _GNU GPL: https://www.gnu.org/licenses/gpl-3.0.en.html
.. _Classpath Exception: https://www.gnu.org/software/classpath/license.html