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.
http://www.shenlanguage.org/Documentation/shendoc.htm