4 ms·

kinda. not really. but I think this is an important point about the gpl. it hinges on this notion of 'linkage' which is a specific technical implementation whic

kinda. not really. but I think this is an important point about the gpl. it hinges on this notion of 'linkage' which is a specific technical implementation which is partially on its way out. but I don't see why it would be a concern here? you're saying to develop a non-gel application on top a gpl-d genera? I guess so.

cmrdporcupine 3y ago
GPL3 kinda cleans this up a bit, doesn't it?
kazinator 3y ago
Lisps have linkage via symbols. Loading a shared library on Unix via dlopen() is just a frankenstein version of loading a compiled Lisp file. Linkage is a very abstract concept; it just means name references in this piece here connect with name definitions in that piece over there. The tech may change, but the concept won't easily go away. Function bindings being established or replaced, and used by code in other files, is linkage. If you load a proprietary compiled file (.fasl or whatever) into a GPLed Lisp program/image such that either uses symbols in the other, that is a GPL violation. However, a given Lisp can spell out exceptions to the rule. Like that a proprietary module may be used, provided it only uses certain symbols (in the module -> program direction), and certain registration mechanisms for its code being hooked in (program -> module direction). If it uses GPL symbols then it must be GPLed. Likewise, if the program is hacked to bypass the GPL-free module registration mechanism, so that it calls some proprietary symbols directly, that is also a GPL violation. Same as Linux kernel .ko modules, basically. If you hack the kernel to call some function in a proprietary .ko, then that's a tainting situation. A .ko calling non-GPL functions, likewise. A proprietary .ko's module_init function being called by the kernel is not a GPL violation, and that module_init calling a non-GPL symbol to register something is also okay.
gumby 3y ago
> it hinges on this notion of 'linkage' which is a specific technical implementation which is partially on its way out. The GPL does not care about linkage status. The GNU Library license, which I originally wrote, is for cases such as this, and the lispm code could be licensed that way. I don't understand what you mean by "partially on its way out".

cmrdporcupine 3y ago

GPL3 kinda cleans this up a bit, doesn't it?

kazinator 3y ago

Lisps have linkage via symbols. Loading a shared library on Unix via dlopen() is just a frankenstein version of loading a compiled Lisp file. Linkage is a very abstract concept; it just means name references in this piece here connect with name definitions in that piece over there. The tech may change, but the concept won't easily go away. Function bindings being established or replaced, and used by code in other files, is linkage. If you load a proprietary compiled file (.fasl or whatever) into a GPLed Lisp program/image such that either uses symbols in the other, that is a GPL violation. However, a given Lisp can spell out exceptions to the rule. Like that a proprietary module may be used, provided it only uses certain symbols (in the module -> program direction), and certain registration mechanisms for its code being hooked in (program -> module direction). If it uses GPL symbols then it must be GPLed. Likewise, if the program is hacked to bypass the GPL-free module registration mechanism, so that it calls some proprietary symbols directly, that is also a GPL violation. Same as Linux kernel .ko modules, basically. If you hack the kernel to call some function in a proprietary .ko, then that's a tainting situation. A .ko calling non-GPL functions, likewise. A proprietary .ko's module_init function being called by the kernel is not a GPL violation, and that module_init calling a non-GPL symbol to register something is also okay.

gumby 3y ago

> it hinges on this notion of 'linkage' which is a specific technical implementation which is partially on its way out. The GPL does not care about linkage status. The GNU Library license, which I originally wrote, is for cases such as this, and the lispm code could be licensed that way. I don't understand what you mean by "partially on its way out".