4 ms·

TL;DR Why relicense? ... First, it is unclear how to apply the LGPL’s statement about dynamic linking to a language like Racket, where macro expansion can cop

TL;DR Why relicense? ... First, it is unclear how to apply the LGPL’s statement about dynamic linking to a language like Racket, where macro expansion can copy code from libraries to applications, and where applications are typically bundled with the Racket runtime and libraries. Second, some organizations unfortunately are unwilling to use software licensed under any variant of the GPL. The first, dynamic linking exception, could maybe be patched up with some effort by FSF resulting in a new LGPL license. The second is more of a developers voting with their feet thing.

mumblemumble 7y ago
> The first, dynamic linking exception, could maybe be patched up with some effort by FSF resulting in a new LGPL license. It could, but the LGPL is already a compromise on the FSF's stated goals, and I can't imagine they'd want to erode the LGPL's ability to encourage people to open source products that rely on open source software even further.
pritambaral 7y ago
> The first, dynamic linking exception, could maybe be patched up with some effort by FSF resulting in a new LGPL license. The Common Lisp world already has something like this, the "LLGPL"[1], but it's use is discouraged[1] because (among other reasons): > 2. In 2004, the Free Software foundation affirmed that "the LGPL works as intended with all known programming languages" and that "LGPL contains no special provisions for inheritance, because none are needed." There is no need for the linking and inheritance provisions that are in the [LLGPL]. 1: https://www.cliki.net/LLGPL https://www.cliki.net/LLGPL
phoe-krk 7y ago
> First, it is unclear how to apply the LGPL’s statement about dynamic linking to a language like Racket, where macro expansion can copy code from libraries to applications, and where applications are typically bundled with the Racket runtime and libraries. Linking exception, same as with GCC. Parts of GCC and GNU standard library make themselves into the produced binaries, but the license explicitly allows the resulting binaries to be licensed under any license the author wants.
samth 7y ago
I think it's genuinely unclear how something like the LGPL should work in a system with macro expansion and ahead-of-time compilation, where the compiled code will contain copies of the bodies of macros. The FSF discussion of the LGPL and other languages focuses on Java, which has basically none of the tricky issues at play here.

mumblemumble 7y ago

> The first, dynamic linking exception, could maybe be patched up with some effort by FSF resulting in a new LGPL license. It could, but the LGPL is already a compromise on the FSF's stated goals, and I can't imagine they'd want to erode the LGPL's ability to encourage people to open source products that rely on open source software even further.

pritambaral 7y ago

> The first, dynamic linking exception, could maybe be patched up with some effort by FSF resulting in a new LGPL license. The Common Lisp world already has something like this, the "LLGPL"[1], but it's use is discouraged[1] because (among other reasons): > 2. In 2004, the Free Software foundation affirmed that "the LGPL works as intended with all known programming languages" and that "LGPL contains no special provisions for inheritance, because none are needed." There is no need for the linking and inheritance provisions that are in the [LLGPL]. 1: https://www.cliki.net/LLGPL https://www.cliki.net/LLGPL

phoe-krk 7y ago

> First, it is unclear how to apply the LGPL’s statement about dynamic linking to a language like Racket, where macro expansion can copy code from libraries to applications, and where applications are typically bundled with the Racket runtime and libraries. Linking exception, same as with GCC. Parts of GCC and GNU standard library make themselves into the produced binaries, but the license explicitly allows the resulting binaries to be licensed under any license the author wants.

samth 7y ago

I think it's genuinely unclear how something like the LGPL should work in a system with macro expansion and ahead-of-time compilation, where the compiled code will contain copies of the bodies of macros. The FSF discussion of the LGPL and other languages focuses on Java, which has basically none of the tricky issues at play here.