You'd hope that that these folks could at least do a GPL-style/copyleft license, which would effectively prevent (non-negotiated) commercial use anyways, while still enabling the open source community to enhance and distribute?
The industry has gone beyond “catching up” to surpassing the values of the Lisp Machine and Genera. Any grand ideas of this era have been considered, and either mined, reimplemented, and exploited or simply rejected as being past their time.
The lack of a Lisp machine or environment like Genera is not holding Lisp (much less the entire modern family of Lisp-y languages) back. And modern IDEs are off the charts, even if they don’t check every single box of what Genera has to offer.
As an industry, we’ve not just stood on the shoulders of giants of the past like Genera, we’ve stepped off and up and moved ahead.
I’ve seen the Genera image that’s floating around, it ran in a VM of some kind. There’s a couple YouTube videos of demonstrations, and maybe I’ve seen the wrong ones, but I’ve just seen them as interesting but not necessarily compelling. It would be wonderful to see a thorough review from a modern perspective.
And, yea, they should set the system free. It’s pushing 50 years old, and we’re in “internet” time, so who knows how much that is in “No one knows you’re a dog” years.
But I took the time to get SLIME set up, with SBCL, and it seems like a completely different world. I’ve used languages with dynamic loading and REPLs before, and it seems like we still have something to learn from Lisp. Like, the experience is far from ideal—Lisp has its own problems. But it is just so damn nice to redefine a function in a running system, without having to then get the system back into the state that I need. I’ve used IDEs with dynamic code patching, and I’ve used Python systems that reload modules, but there have always been problems with the ergonomics.
https://learn.microsoft.com/en-us/visualstudio/debugger/edit...
To be clear—I’m not making the argument that people should be writing programs in Lisp. Just that there are some things to learn from the way Lisp development works.
In the past, when I’ve used the various edit-and-continue tools, it felt it was just cutting some time out of the edit-compile-run cycle. The Lisp system feels more like a workbench, where you create fixtures to try things out while you are building the system.
There's plenty of mature options both commercial and free, and to me, many years ago,they have a similar feeling.
It doesn't simply replace a function binding; it actually replaces code and puts the instruction pointer of existing threads that were running that code into some similar location in the new code. (Which is pretty amazing, to be sure).
What's going on in Lisp code reloading is something a lot pedestrian; just new functions are replacing old ones. Thread which are in the middle of running the old functions continue with those ones. When the last thread is done executing a function, it can be garbage collected.
I don't work with life-critical software and yet auditors demand that every code-change to production is peer reviewed and linked to a jira item.
Something like Fix & Continue in Visual Studio is good for testing out smaller changes. By comparison, something like SLIME + Lisp is powerful enough to use for developing new features. The running system on your developer workstation is mostly synchronized with the source code on disk because the interface you use for making changes is the editor. This synchronization is not perfect, but that’s why you have your unit tests and CI/CD pipeline.
If you're implying that this isn't thread safe, you're wrong. Edit and continue works just like how you described Lisp code reloading. Works just fine in production if you're crazy enough to push a debug build.
I dunno why Lisp people keep advertising ancient and widely distributed tech as revolutionary. Eg have you looked at LLVM XRay? It's yet another "self modifying C code hack", except it's explicitly designed to work in production on release builds: https://llvm.org/docs/XRay.html
I don't buy it. What in the world actually traces its roots to Genera in any way, outside of the Lisp microcosm?
I don't think the roots are going to be source code-based, but based on cultural transfer.
But the idea of Java being Lisp influenced is questionable. Though they had Guy Steele, who said something about bringing C programmers halfway to Lisp, pretty much the the only Lisp idea in Java is garbage collection.
The JVM is hostile against the efficient implementation of Lisp-like languages; it doesn't let you pack tag fields into pointer values.
>But the idea of Java being Lisp influenced is questionable. Though they had Guy Steele, who said something about bringing C programmers halfway to Lisp, pretty much the the only Lisp idea in Java is garbage collection.
Java also has some dynamicism through classloaders and reflection.
>The JVM is hostile against the efficient implementation of Lisp-like languages; it doesn't let you pack tag fields into pointer values.
It's a good trade off for Java, pointer coloring is used by ZGC for example.
Maybe PowerShell can also be described as using some of the same concepts of manipulating data as the Genera UI.
Dan Weinreb wrote an object-oriented database at Symbolics -> Objectstore was founded by former Symbolics people. Their C++ database was said to be influenced by Symbolics Statice.
Patrick Dussud from TI went to Microsoft. Dave Moon went to Apple. Gary Palter worked for Clozure. Steele worked for SUN on language design (Java, Fortress, ...). Weinreb later went to ITA -> worked on the flight search engine written in Lisp. There are a bunch of other examples.
A bunch of language infrastructure or even language designs was influenced.
Why do I still have a clunky character-mode terminal instead of a Listener that can display rich text, images, mousable forms? Just think what we'd have today if we'd worked on that paradigm for 30 years instead of fetishizing the limitations of 70s minicomputers.
Why is it that when I type a command into said terminal and forget a parameter, I have to delete it, or open another window to type 'man', whereas on Genera I can hit <help> and view (rich, hypertext) documentation for a specific parameter, inline, while still typing in the command? That little feature was a revelation.
Genera's fluid, ergonomic developer experience is something we are turning away from more and more these days. Programming is increasingly surrounded by the most tedious bureaucratic and administrative work. The hoops I have to jump through before I can start creating something in a programming language are only increasing. If people had paid attention to Genera and to Lisp machines it wouldn't be like this.
And I've only mentioned surface aspects of the user experience. I haven't talked about being able to debug anything, or the idea that what look like applications are actually "substrates" that I can potentially use as APIs for my own work. We haven't scratched the surface yet.
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.
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.
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.
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".
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
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.
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.
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.
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/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.
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?
[0] https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.htm....
[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.
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.)
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.