The strange part is "no derivatives that don't comply with the spec, even if you rename it." It is not free software.
Unfortunately this is something I have to mention every time Shen is mentioned, because I'm irate that, in spite of my interest in it, that both it (and its predecessor Qi) insist on doing something so strange with no apparent legitimate purpose (some kind of bogeyman of fragmentation killing the project).
Shen seems pretty cool, but there are lots of other things out there that are also cool. When licensing is such a big deal, I think its bizarre license is reason to steer away from Shen.
It not being "free software" is pretty debatable imo. Maybe not free with a capitol f, but free enough as an academic language.
For better or worse, it's not that uncommon for licenses to complicate it. To take one prominent example, Microsoft Research's Z3 is completely proprietary: source-code is available but you cannot make any derivative works of it (except in-house without distribution). The famous Q array-processing language is also completely proprietary. Less restrictively, it's common for things to be released under an "academic use only" or "noncommercial use only" license.
And the papers I've read about array languages don't base their languages on Q. I haven't done much reading on theorem provers, but I suspect I'll see a lot more papers about things derived from ACL2 or Coq than from Z3.
Supposedly the bizarro license is due to fear of forking and divergence, but ironically, it's just as likely to have the opposite effect:
If it's a great language, but the current implementation is toxic (as it seems to be), you'll get people writing their own implementations of it, which will inevitably differ, and the lack of a common base will make divergence even more likely. With forks, at least you usually have the option of porting changes between the forks with a smallish amount of effort; with separate implementations, this sort of thing becomes much harder.
They have developed it and don't want it fragmented. Not out of fear of loosing the project, but because they consider rampant forking to be one of the main weaknesses of open source and Linux in particular[1].
Why is it strange to want to avoid dilution and confusion of your product? People can use it, modify it for improved performance, add libraries to it, include graphics and other files as necessary, and even charge money for what they've done with it. Pretty much the only thing you can't do with it is modify it significantly and re-release it as your own personal brand of Shen (whether renamed, or not).
It looks like a lot of work went into it, and they're basically gifting it to the community to use and profit from.
A more open license would be great, sure. But they have a legitimate position here, and they make a reasonable point. It may be myopic in some people's opinion, that's a matter of debate, but I don't see how it can be considered to be absurd.
[1] "Hence the production of derivative non-conforming programs from our source, whether called Shen, Shin, Shine or Shoo, is barred by the license. To give up on this is to give up on the motivation for Shen.
We are therefore not open source. Generally, the diversity and freedom to fork which was lauded as a strength of open source, has turned into the major weakness of Linux. This OS has been burdened by multiple forks, multiple distros, multiple apps for doing the same thing to the point where essentially the same work has been redone over and over again by different groups. The resultant wastage of effort has been huge and the result has been lack of cross platform usability, a lack of uniformity in the user interface, a reliance on complex dependencies and too often, software that reflects the scattering of human resources by displaying broken functionality. Even Linux fans are seeing this. This in turn has given Linux a bad name. We want to avoid all that."
> "Why are you guys so fork paranoid? Do you want everyone to vote for the same political party, too?" -- Theo de Raadt
A witty saying proves nothing, but it might be a good starting point for a discussion. To me, it isn't strange that an author wants to avoid dilution and confusion of their work, we all feel this way at one point or another when producing software.
But, when I pick a community and a language to express myself, I consider several potential future issues. Such as, will this language be around in five years? Will I be able to port it to a platform that few people find to be important/interesting enough? Will I be allowed to experiment with the fundamentals? Will I be allowed to disagree with the original author on how things are done? With a license like this, worries starts to pop up into my head. Since to me software isn't handed down from above, it is an ecosystem of which I am an active a part of.
If the authors don't trust someone else to do what they do better, or different for another purpose. Why should I trust them?
I came here to point this out as well. It just does not make any sense whatsoever to have this license if you are trying to make an open-source project. I get that the idea is to prevent fragmentation, but it is enough to require they don't use the name. The actual license basically excludes anyone who wants to experiment with it. It's not free.
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.
That would mean I can do whatever I want as long as I provide a way to invoke their unmodified interpreter rather than my hacked-up one (i.e., I could build two binaries). My reading of the license (modifying the software is only acceptable for one of three purposes in bold, and "not open source" appears verbatim) doesn't make me confident they'd actually be okay with that, though it'd be a pleasant surprise.
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.
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.
Who decides whether a language I come up with is a port/version/mod of Shen? How much of Shen's features can I include without crossing that threshold? Does that threshold move if I can point to other non-Shen languages as the source of those ideas?
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'm glad that license is the only complaint software enthusiasts have against Shen.
Not all languages have to have the same license. It's open source, since the source is available, and it's free, since you don't have to pay to use it. If you mean that it's not "free" by FSF definition, then just say "it's not Free (tm) FSF(c)".
Very few people have invested enough in Shen to bother finding such pointed complaints. If the implementation is not supported and pushed by something the size and vertically integrated nature of Microsoft or Apple, a cathedral enforced by the license is a huge deterrent for a lot of people.
Not all language implementations have to be open source, and conversely, I don't have to invest my infrastructure in all language implementations, especially ones that choose to hobble their fitness in the form of a dubious and paranoid license, which I think is chosen based on reasoning that may have only been defensible (not even 'good') in 1985 or 1990.
The comparison to "Linux" (by which they mean, distributions, I presume, instead of the kernel, which is definitely a monolithic development effort) is as laughable as worrying about "what if thirty people write TLS libraries in Shen!?" The problem ostensibly addressed by the license is not solved, and so it is nothing more than an albatross.
It's a pity, because the ideas in Shen deserve a better chance than that.
I was trying to find an argument in your post and gave up trying. Is there one? The sum of your argument seems to be that the license is a huge deterrent for people who think like you. I believe you - and?
The license makes the work $free and the only requirement is that if anybody changes it, that it continue to work. Otherwise I can do as I want. Perfectly fair.
Also they seem pretty successful in building a whole series of portable cross-platform versions which compared to the crud I've seen under Linux is a very good start.
"It's a pity, because the ideas in Shen deserve a better chance than that."
I think Shen deserves a better analysis than yours.
The license is such a huge deterrent that very little can be inferred from "the license is the only complaint". Nobody knows whether we would have found the language to be amazing or terrible, if only we hadn't stopped considering it because the only implementation is not open to hacking.
It is a practical problem. The presumption is that the unusual license makes the language's implementation less amenable to survival.
I can't justify a reason to absorb that much risk over the lifetime of maintaining programs written in the Shen language, running on the Shenlanguage.org implementation, which is presumed to be the best. The relatively new implementation is hard enough to swallow, but understandably completely necessary and unavoidable. Considering the typically interested audience of advanced static typing include staid system programmers looking for an edge in correctness in systems that take a long time to build and last a long time afterwards, that's a pretty weighty consideration. It is from this viewpoint I evaluate my dependencies.
So, sorry. I don't think my analysis -- which is something you seem to sneer at -- is without a justified dimension. To be fair, I sneer at the licensing in turn, so all is even.
Hopefully, the authors might understand why so many people may be so hesitant to invest in their platform, doing all the hard work of writing, debugging, and maintaining ports and libraries on such a foundation, as they seem so inclined to ask people to do. Even if the existing authors did all that themselves, proposal of new investment in the platform in organizations at arm's length from Lambda Associates would raise some eyebrows. I could see enormous organizations (like the US DoD or Boeing) being interested.
I'd compare Lambda Associates (the Shen author umbrella organization) as a less entrenched Adacore as things stand.
Given that I don't feel they solve their purported problem anyway (divergent language implementations are not so much a fragmenting force as multiple libraries with inadequate resources doing the same-ish thing, a problem virtually un-treatable by any policy or license) I'd really hope they'll one day see fit to just not be strange with respect to licensing, and change their mind. The observation of another poster -- that this may ironically increase fragmentation, because someone fascinated with the ideas in the language but not the bizarre license -- may be inclined to make something kind-of-not-quite-like Shen rather than contributing to the existing artifact.
The argument is simply again that the unusual license makes the language less amenable to survival because it does not appeal to people like yourself. That's your entire argument wrapped up in an awful lot of words . Yes - and?
BTW if you're going to use words like 'laughable' and 'paranoid', don't complain at people who question your posts as sneering at you.
I can work with this implementation, sell my stuff on it, learn from it, its less restrictive than GPL. You apparently cannot do that because your mindset stops you.
And as regards libraries; the library AFAIK is under BSD. The kernel is under license and the page explains why.
"The analogy that we would like people to carry with them is that of a spinning wheel. The freedom of the wheel to spin depends on there being a fixed hub which at its theoretical geometrical centre point shows zero motion. Our adherence to standards and discipline as system programmers allows you, the applications programmer, to be confident of basing your work on ours."
Is this problem really solved by the license? The example given (Linux distributions) is not a good parallel to a language implementation. As per earlier, this is more like worrying if people will come up with thirty ways to implement TLS -- something they are still free to do. Fragmentation analogous to that cited is not curbed in any way, from what I can see.
The other side of the coin: is the problem a problem? Do similar but incompatible implementations really typically come from a common base? From what I can see, this is Not A Problem -- usually such subtleties are from complete reimplementations and under-specification or just flat out bugs. So why worry about this?
The final concern that I have left unstated, but other posters have also probed at is "if a group of people have the determination to change Shen's semantics and wish to distribute it and maintain it, and people wish to use that, should they be denied? Why should anyone trust the original designing committee over the course of many years, with their only recourse being to start from scratch?"
It's hard to understand what the authors of Shen want to get out of the whole thing, but I'm not only perturbed by their choice of aesthetics in this area, but the apparent fact that the problems ostensibly treated seem very much untreated. It is this latter fact -- that the stated concerns seem to have resulted in a non sequitur decisions -- that leaves me even more confused and disappointed.
I'll finish this concluding: of course the authors are free to do as they will, but I can't read the soundness in their line of reasoning and am simultaneously disappointed by the result, and I'm sorry I've let that disappointment make me snide.
As far as I can see Tarver is applying the US copyright concept of derivative in the license and that means that it would be hard to show that a non-compliant version of Shen was not derivative. You'd have to use clean-room techniques and show that the code you produced wasn't lifted from the sources given. And in addition you would probably get nil support from the people running the project so I'd say the license works pretty well to stop forks. Whether it should stop forks, you can argue, but as a tank-trap its pretty good.
"Do similar but incompatible implementations really typically come from a common base?"
In this instance without the license the answer would certainly be 'yes'. Forking from the existing sources would be the obvious and easy route.
"If a group of people have the determination to change Shen's semantics and wish to distribute it and maintain it, and people wish to use that, should they be denied? Why should anyone trust the original designing committee over the course of many years, with their only recourse being to start from scratch?"
Well that's a tough one. According to Stallman the answer is 'yes' because the originator has no special rights over his work. On the other hand Stallman's idea of freedom is freedom to agree with Stallman. I prefer BSD.
If we imagine that this group know what they are doing then the answer might be 'yes'. However you cannot write this proviso into a license, so you have to allow the half-assed changes along with the good ones and you're back to a free for all.
Pragmatically what I think is that the Shen group are very good; they are the only ones with the expertise and they have a good track record of delivery. The Shen spec looks good. I've read Tarver's book on Qi and from what I can see the whole semantics of the language is mixed in with a bunch of proofs in math'l logic that I for one wouldn't want to mess with. If they drop the ball, we should step in, but If you did have a case for changing the spec, my money would be that the best thing to do is to approach the group and put forward your case.
I'll say one thing for Tarver and what he does; it sure is different. Fifteen years on, with billions of free hours, open source has failed to deliver a popular Linux desktop. Maybe we should start being a little open minded about methodologies and licenses before jumping on people's heads. The important thing is to deliver.
I can insist on engaging with my tools as an unfettered human being and still have so much remaining to learn that I need to triage. If there's a problem here, it isn't mine, and insults are not going to get Shen more traction. It won't be the first tool passed over for being needlessly hacker-hostile.
Right. You never ever engage or use anything that is not open source. Right? Meanwhile out in the real world .....
Your concept of being unfettered tells you that you should have the right to park your tank on somebody else's lawn. Doesn't it hit you that your goal of being unfettered to foobar something you don't understand (and nor do I actually, but I'm humble enough to admit I'm unqualified to hack the Shen kernel) might actually interfere with what the people on that project are trying to achieve? So the end result is that you end up being so fettered by your own attitudes you can't even get to understand what is being gifted for free (in the good old fashioned Anglo-Saxon use of the word). You remain perpetually stuck with yur sense of self-entitlement.
It seems like Shen is a successor to Qi, which if I remember right, had a type system that incorporated full-blown classical logic. If Shen follows in this tradition, then its type system would be significantly more expressive than standard functional type systems. It would allow not only arbitrary predicates on input and output, but also relationships between them. Needless to say, such a type system is Turing-complete, and therefore not guaranteed to terminate.
Systems like this are usually used as theorem-proving systems, not actual production languages. I think Qi was intended to be a practical language that allowed arbitrary proofs about the properties of its programs.
I have not been able to find any reference to this in a quick perusal of Shen's documentation.
Standard type systems are Turing equivalent. This includes the type systems of functional languages like ML and Haskell. In fact, there's a neat correspondence [0] between algebraic data types and propositional logic (examples in Haskell):
union types (data T = mkTA A | mkTB B) <-> logical disjunction (A ∨ B)
product types (data T = mkT A B) <-> logical conjunction (A ∧ B)
function types (type T = A -> B) <-> logical implication (A → B)
the unit type (()) <-> true (⊤)
bottom (⊥) <-> false (⊥)
(And, if you were wondering, that's where the symbol for "bottom" comes from!)
Inference on richer type systems, e.g., systems that support dependent types (types built up from expressions about the values they represent) is in general undecidable, which is why some dependently typed languages (e.g., Coq) have type systems that are not Turing equivalent—the language designers have consciously pared down parts of the type system in order to guarantee that type-checking terminates.
Yes. My response was of course to clarify that "ordinary" type systems are Turing equivalent and incorporate classical logic.
Dependent types correspond to first-order logic in the Curry-Howard interpretation. I don't know much of anything about Shen, so I can't comment further on it specifically.
By the way, limited dependent types can also be implemented in Haskell through type-level programming. The paper that introduced this idea [0] is a good read, and doing some type-level programming is a great way to get to grips with the ins and outs of Haskell's type system. If you're interested in type-level hackery, also be sure to read the HList paper [1].
The argument is that agda is relatively straightforward for haskellers and similarly, coq for ocaml devs to adopt. This is a good succinct example of former. Coq has lots of tutorials
It looks like it's a Lisp or Lisp-like, but with some features I haven't seen in other Lisps: pattern matching; currying-by-default; a built-in type system; and so on. IOW it seems like if Lisp and Haskell had a baby.
I'll admit that, having studied Haskell before Lisp, I really, really like pattern matching. But I don't think this would be enough for me to pick up Shen; I'd probably go with Clojure if I wanted a Lisp.
I think one of the coolest things I have seen is the way that it has full support for what macro expansion gives you in a "normal lisp" but without the use of quasiquotation - instead it utilizes pattern matching.
Second this. What's Shen's hook? I see a lot of prefix notation for function application...seems Scheme-y to me. I thought things had trended away from that.
I think for macro enthusiasts, being able to program the reader directly(with pattern matching) is a good selling point. It also has an inbuilt compiler compiler.
I've bought the Qi book and have been enlighted by the language it describes. I'm looking forward to play a bit with Shen and see how it compares to other lisps.
Yes and it's the 50th most common surname in China, the Chinese word for spirit/god, a character in a pletora of other popular games and fiction, etc etc. Got any other random associations to share with us?
In my google search for 'shen', the language homepage is on 4. position. That's pretty well for an obscure programming language imho. LoL character has 2 results and one video in the first page, so it's not really overpowering other Shens.
Errr, in the search I just did it's #3. But I guarantee you that has a lot more to do with Google's knowledge of what I search for and am (potentially) interested in than anything else.
Unfortunately this is something I have to mention every time Shen is mentioned, because I'm irate that, in spite of my interest in it, that both it (and its predecessor Qi) insist on doing something so strange with no apparent legitimate purpose (some kind of bogeyman of fragmentation killing the project).