25 ms·

The GPL does not prohibit commercial use at all. Often when historical stuff like this is released for "non-commercial use", they're not just talking about not

The GPL does not prohibit commercial use at all. Often when historical stuff like this is released for "non-commercial use", they're not just talking about not using the code itself in your own non-open-source product, but they mean "you can't run your business on this software." The GPL certainly doesn't stop a commercial entity from downloading and using a GPL-licensed accounting package such a GnuCash to keep track of their company finances.

jasonjayr 3y ago
Having never used a lisp machine, and only having a basic understanding of it -- but if the whole system is a lisp image + apps are just calling into the OS as if they were lisp functions, woulden't a 'pure GPL' be problematic becuase EVERYTHING running in it would have to be GPL? Are there clear linking boundaries in symbolics lisp between apps + the OS ?
- convolvatron 3y ago
  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".
- kazinator 3y ago
  The Linux kernel shows that you can have GPL symbols and non-GPL symbols. Perhaps more relevantly, here is an example of a GPL-ed Lisp implementation which has special provisions that allow proprietary programs to be redistributed which use it: https://clisp.sourceforge.io/impnotes/faq.html#faq-licensing https://clisp.sourceforge.io/impnotes/faq.html#faq-licensing One notable rule is that applications that access symbols non-portable internal packages (considered to be CLISP extensions) must comply with the GPL. FFI is one of those packages. So this probably means that a proprietary application that extends CLISP via FFI (e.g. to call its own proprietary library) must split off that piece away from the application and make it GPL. I'm guessing that the rest of the code, which depends on the CLISP+extension, doesn't have to be GPL.
  - kevin_thibedeau 3y ago
    GPL treats isolated processes and shared libs as a license firewall. That doesn't happen in Lisp world.
    - em-bee 3y ago
      a different definition could be applied here, which would be fine because it would not be an additional restriction but less restriction than what the GPL would demand. on the other hand, not having this boundary would mean that a lot of commercial use would be prevented, which would work in favor of those who originally were looking for a non-commercial license.
    - kazinator 3y ago
      If a GPLed shared library is loaded into a process, everything in it has to be compatibly licensed. GPL-incompatible applications that dynamically load a GPLed library and use it optionally can probably get away with it. If you make a proprietary program which can optionally use a GPLed dynamic library, which you don't ship with the program, you're likely untouchable in court, if your attorney argues the point with a tongue more silver than the other guys' attorney.
    - kmeisthax 3y ago
      It doesn't. You can trip the GPL on anything that makes your code and the GPL-covered code form the same "program." What that term means exactly is strategically ambiguous; but it definitely does NOT mean "same address space." Shared libraries are very much NOT a firewall either, Stallman explicitly said otherwise[0] and Lesser GPL is there specifically for people who want it the other way round. Linux is special - it's licensed with an exception that says user space never trips the GPL. Linus has also further interpreted said exception to mean that code that only touches user space equivalent APIs can live in kernel space without tripping GPL. They even have DRM[1] that enforces this interpretation on LKMs. Absent that exception, who knows. The GPL copyleft is deliberately written to be as strong as copyright laws are, and we live in a legal environment where APIs can by copyrighted. So it's entirely plausible to argue that a GPL operating system trips its copyleft on all software written for it. A less hypothetical example: packaged emulators. If you sell a proprietary game wrapped inside a GPL emulator, that's a single program now, and you're violating GPL. However, while several emulator developers have had their work used in exactly this way, none of them have been willing to demand a relicense of the game their emulator was packaged with. [0] https://sourceforge.net/p/clisp/clisp/ci/default/tree/doc/Why-CLISP-is-under-GPL https://sourceforge.net/p/clisp/clisp/ci/default/tree/doc/Wh... [1] Digital Rights Management. Yes, Linus could actually sue a driver vendor that circumvented the Linux kernel linker licensing rules under DMCA 1201. GPLv3 explicitly contravenes such interpretations of the code, but well, Linus ain't touching that license with a ten foot pole.
- amno 3y ago
  As long as you don't distribute it, you are OK.
  - actionfromafar 3y ago
    For GPLv2
    - pxc 3y ago
      And also GPLv3. It's only AGPL that has stipulations for software you don't distribute t ok others.
cmrdporcupine 3y ago
I mean I guess I should have explicitly said "derived distribution for commercial projects" but I kinda thought that was obvious since nobody is going to use Genera as is, it would require substantial upgrading to make it useful for the 21st century. Which would be a derived work under GPL and require publication of sources if distributed etc. etc. GPL makes a lot of sense to me for something like this. Nobody is going to make money off Symbolic's old IP, but if they somehow were, clauses in the GPL3 or some variant of a copyleft license would likely force them to contribute back.

jasonjayr 3y ago

Having never used a lisp machine, and only having a basic understanding of it -- but if the whole system is a lisp image + apps are just calling into the OS as if they were lisp functions, woulden't a 'pure GPL' be problematic becuase EVERYTHING running in it would have to be GPL? Are there clear linking boundaries in symbolics lisp between apps + the OS ?

convolvatron 3y ago
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".
kazinator 3y ago
The Linux kernel shows that you can have GPL symbols and non-GPL symbols. Perhaps more relevantly, here is an example of a GPL-ed Lisp implementation which has special provisions that allow proprietary programs to be redistributed which use it: https://clisp.sourceforge.io/impnotes/faq.html#faq-licensing https://clisp.sourceforge.io/impnotes/faq.html#faq-licensing One notable rule is that applications that access symbols non-portable internal packages (considered to be CLISP extensions) must comply with the GPL. FFI is one of those packages. So this probably means that a proprietary application that extends CLISP via FFI (e.g. to call its own proprietary library) must split off that piece away from the application and make it GPL. I'm guessing that the rest of the code, which depends on the CLISP+extension, doesn't have to be GPL.
- kevin_thibedeau 3y ago
  GPL treats isolated processes and shared libs as a license firewall. That doesn't happen in Lisp world.
  - em-bee 3y ago
    a different definition could be applied here, which would be fine because it would not be an additional restriction but less restriction than what the GPL would demand. on the other hand, not having this boundary would mean that a lot of commercial use would be prevented, which would work in favor of those who originally were looking for a non-commercial license.
  - kazinator 3y ago
    If a GPLed shared library is loaded into a process, everything in it has to be compatibly licensed. GPL-incompatible applications that dynamically load a GPLed library and use it optionally can probably get away with it. If you make a proprietary program which can optionally use a GPLed dynamic library, which you don't ship with the program, you're likely untouchable in court, if your attorney argues the point with a tongue more silver than the other guys' attorney.
  - kmeisthax 3y ago
    It doesn't. You can trip the GPL on anything that makes your code and the GPL-covered code form the same "program." What that term means exactly is strategically ambiguous; but it definitely does NOT mean "same address space." Shared libraries are very much NOT a firewall either, Stallman explicitly said otherwise[0] and Lesser GPL is there specifically for people who want it the other way round. Linux is special - it's licensed with an exception that says user space never trips the GPL. Linus has also further interpreted said exception to mean that code that only touches user space equivalent APIs can live in kernel space without tripping GPL. They even have DRM[1] that enforces this interpretation on LKMs. Absent that exception, who knows. The GPL copyleft is deliberately written to be as strong as copyright laws are, and we live in a legal environment where APIs can by copyrighted. So it's entirely plausible to argue that a GPL operating system trips its copyleft on all software written for it. A less hypothetical example: packaged emulators. If you sell a proprietary game wrapped inside a GPL emulator, that's a single program now, and you're violating GPL. However, while several emulator developers have had their work used in exactly this way, none of them have been willing to demand a relicense of the game their emulator was packaged with. [0] https://sourceforge.net/p/clisp/clisp/ci/default/tree/doc/Why-CLISP-is-under-GPL https://sourceforge.net/p/clisp/clisp/ci/default/tree/doc/Wh... [1] Digital Rights Management. Yes, Linus could actually sue a driver vendor that circumvented the Linux kernel linker licensing rules under DMCA 1201. GPLv3 explicitly contravenes such interpretations of the code, but well, Linus ain't touching that license with a ten foot pole.
amno 3y ago
As long as you don't distribute it, you are OK.
- actionfromafar 3y ago
  For GPLv2
  - pxc 3y ago
    And also GPLv3. It's only AGPL that has stipulations for software you don't distribute t ok others.

cmrdporcupine 3y ago

I mean I guess I should have explicitly said "derived distribution for commercial projects" but I kinda thought that was obvious since nobody is going to use Genera as is, it would require substantial upgrading to make it useful for the 21st century. Which would be a derived work under GPL and require publication of sources if distributed etc. etc. GPL makes a lot of sense to me for something like this. Nobody is going to make money off Symbolic's old IP, but if they somehow were, clauses in the GPL3 or some variant of a copyleft license would likely force them to contribute back.