taotree

My understanding is that would be fine so long as the default distributable will run Shen according to the spec. Keep in mind, you can do a LOT of extensions and still run standard Shen. For example, the existing shen-clisp, you can seamlessly call clisp functions by typing them in all caps. I think it would be interesting for someone in this conversation to suggest something that they might want to do to the language that would not allow standard Shen to run also.

The license is for the software--the Shen implementation. If you don't use the Shen implementation provided, then you're not subject to the license. If you create a port/version/mod of Shen then you are using the software. The way ports of Shen are created is by implementing Klambda. The provided Shen implementation compiles Shen to Klambda, which your port then compiles to a host language. So, unless you really want to clean-room reimplement the entire Shen language (which is NOT how porting is intended to be done) then you're using the software that is subject to the license.

I think the license is worded rather poorly and that's unfortunate. I think it would be better worded as this: if you create a port/version/mod of Shen, it must be able to execute spec-compliant Shen code. That's it. You can do all the changes, experimentation, etc. so long as it is somehow capable of executing stock Shen code, it's allowed. I think that means that you can even have a flag that toggles between "standard-compliant" and "everything-works-different" because anyone with Shen code can set the flag to "standard-compliant" and run their code. So that situation would be fully compliant with that license.