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 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.
CommentsComments powered by Disqus