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 ?
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:
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.
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.
[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.
Packaged emulators specifically refer to the case where you're selling your own game and wrapping it in an emulator to do so. For example, all the old iD games on Steam are wrapped in DOSBox.
In that specific case, the player has access to all the game files, and it's trivially easy to extract DooM out of the wrapper and play it somewhere else. I would agree that the GPL's "mere aggregation" language probably covers this particular use case - but I use the weasel word because the FSF's FAQ[0] about it is uncertain. This particular sentence comes to mind:
> But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
Pretty much any program whose responsibility it is to host other programs (either OS kernels or emulators) is offering up interfaces that will carry intimate details of the host into the guest. In fact, this is precisely the reason why emulator development is a never-ending rabbit hole of implementing other people's bugs to get games to work. Another example of 'intimate communication' would be something like io_uring, where the OS kernel and user program are writing into ring buffers and trading ownership over subordinate data buffers around.
While the FAQ says a judge would ultimately decide each case on its own, practically speaking judges are going to defer to the guidance of the people who wrote the license unless there are facts to the contrary (e.g. an emulator developer said it's OK to aggregate game and emulator this way and then tried to change their mind). If Stallman says "sharing intimate details of execution constitute combination" then judges will take his side.
Another potential argument comes about if we swap out Steam for, say, the iOS App Store. Apple doesn't provide any ability to extract resources from iOS apps[1], nor do they allow shipping unpackaged emulators[2], so the user cannot meaningfully disaggregate the emulator from the game program as it has shipped on the App Store. Why would this specific case not be combining two programs into one?
[1] They aren't encrypted per se, but you don't have full filesystem access as the owner of the device, so...
[2] Apple doesn't want users downloading third-party code. This actually has nothing to do with the GPL - you ARE allowed to ship GPL code, if you provide custom EULA language that says that the GPL prevails over the App Store EULA.
Interesting how differently how one can view things.
I'd say, emulators are the easiest to defend. First and foremost, they emulated something which existed before. And the fact that there are different hardware and software emulations, several of them completely different to one another internally, proves that the program does not the intimate details of execution. Also, I read somewhere that especially if something existed before is a big difference when judging a GPL program. If a GPL program clones a previously existing behaviour, how can you with a straight face say an aggregate is derivative?
(Of course, there can be other things like GUI integration which muddies things up.)
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.
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.
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.
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.
> 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".
