LGPL is a bad practice

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 (more copyleft).

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.

The bad practice of LGPL comes from a different source than my problems with GPL: the concept of linking. LGPL defines its borders by the ability to replace the library that may be impossible in some languages.

  • Interpreters. I removed this section after re-reading LGPL and its explanations. Since programs for interpreters are always source code, including uglified forms, you can always replace the library with an updated or patched version. LGPL here seems fine.

  • 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 be licensed under LGPL. Will this glue code be interpreted as "Library Header Files"?

  • 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.

Comments

Comments powered by Disqus