I'm pleased people have gt something out of the opening
cahoter of TBoS. But the book was never designed to be read online, except
as a preview and a quick lookup/reminder of features.
For intensive prolonged reading, the route to purchasing
the hardcopy is linked to the front page.
Anybody discouraged from buying by the very limited hurdle
getting the book will completely fail at the more substantial
hurdle of understanding it.
Expecting everything for free, and creators giving in to
that demand shapes character. Systems
which reward minimal effort, maximal demand,
and zero reciprocity end up selecting for the worst traits
in both readers and communities.
It wasn't at all what I was expecting. The thread actually opened with a conversation on post-WWII British aircraft manufacturing of all things and got in automated reasoning. ChatGPT made a clever remark on group theory which prompted the paper. From then on the rest followed very quickly. The whole thing was mind-blowing really and archiving it and going away was the only thing to do. I was getting sleep problems.
As regards the research I think the best thing to do in these cases is to feed ChatGPT the paper and start where we left off. This seems to work but it is a bit too early to gauge how well this will work.
What happens when a scientist spends a week in continuous, serious dialogue with an artificial intelligence — and finds their health, their thinking, and even their loyalties changed?
I skimmed these responses, I'd say that most of them are the result of not reading the material in the
essay or nit-picking or ad hominem remarks. I really tried to find something of real worth.
'His argument rests on the claim that "most open source code is poor or unusable." When most people refer to Open Source Software, they're referring to serious projects
like the Linux kernel, Apache, PostreSQL, Firefox, etc. They're not referring to random crap on Github.
I'm afraid this in an attempt to redefine open source and is an example of the 'isolated points fallacy' covered in the essay. Open source includes everything with an open source license. To say OS is successful by defining all projects that do not succeed as not part of OS is simply to coin a tautology.
'Is there any special reason to believe that closed source is any better? If we can count the sea
of abandonware on Github, then we get to count the mountain of "interesting" code that remains
internal to large companies, or worse, the stuff that actually got released on unsuspecting customers.'
Again covered in the essay
'Proprietary software vendors typically make money by producing software that people want to use.
This is a strong incentive to make it more usable. (It doesn’t always work: for example, Microsoft, Apple,
and Adobe software sometimes becomes worse but remains dominant through network effects. But it works
most of the time.)
With volunteer projects, though, any incentive is much weaker. The number of users rarely makes any financial
difference to developers, and with freely redistributable software, it’s near-impossible to count users anyway.
There are other incentives — impressing future employers, or getting your software included in a popular OS —
but they’re rather oblique.'
What an absurd dichotomy. Even if you work full time on open source, you probably can't be a major contributor
to more than a handful of large projects, at most; many people specialize in just one. But you probably use dozens to hundreds of open source programs. So for any project with a modicum of popularity, of course the number of people who use the software without contributing dwarfs the number of contributors.
That would be true even if everyone worked full time on open source.
A giver is a person who gives as much or more than he takes. A taker is one who takes more than he gives.
Define it in relation to open source as a whole and the dichotomy is valid. There are users and corporations
who take far more from OS collectively than they give back. Is this hard to grasp?
'The vast majority of comments that take issue with it in this thread thus far are nitpicks about minor points,
and almost none address the essential thrusts of Tarver’s argument, all of which are actually quite cogent.'
That's basically right and that's why after 20 years the OS movement is still stuck where ESR left it.
I'm afraid you don't really understand licenses. A license like BSD gives you the rights to distribute the software subject to certain provisions. It does not give you the right to change the license. I can't really spend any more time on this but I'm sure people around you can point you in the right direction.
Your understanding is wrong I'm afraid. You cannot license software you have not written or over which you have no ownership. It is unfortunate that some people believe that the BSD license in itself gives people the rights to relicense the work under GPL. It does not.
This misunderstanding arose from a deliberate attempt by the FSF to co-opt the open software movement by trying to relicense BSD work under GPL without seeking the author's permission. The attempt was successfully challenged by Theo de Raadt in 2007 (http://undeadly.org/cgi?action=article&sid=20070913014315) and the ensuing discussion in which Stallman was thoroughly educated in the law of copyright can be found here.
Harold is I'm afraid bullshitting you. I really have to say lying, because at this stage there is no other word to use. Check for yourself, the files are all 3 clause BSD.
> There was no prior discussion that I can remember
Actually, Harold, you are either very stupid or have Alzheimer's or are a liar. In fact there was a very long discussion, initiated by me, about GPL and BSD to which you contributed a long irrelevant rambling reminiscence about Stallman. In it I discussed this very point and there was no dispute from you - nor from anyone else as to the legal point I was making.
In fact there were two weeks of open discussion in which I went into detail reiterating the same points several times and leaving the space open for debate precisely so we could have a common understanding. And we all, that is, everybody who actually is making a code contribution, came to an agreement about the law. And strangely we did not miss your sunny personality one bit.
And after that Shen went to BSD and these copyright points were put into a brief paragraph to remind the people involved what copyright law means and we discussed how to present this to be clear. After we went to BSD. And you were and are mainly irrelevant to that process.
And really these paragraphs are not written for you, because I regard you as pointless. It is written for those on the outside. Shen is BSD.
Again Harold, a falsehood. Since you have contributed to two threads with the same misinformation, I'll make this clear, not for you, but for everybody else.
Shen is under BSD and anybody who downloads it can see this. The 1/3 page of comment in the pdf is simply pointing out copyright law, mainly for platform holders (and you're not one having sent no code). Everything was thrashed out in fine detail and agreed on before the change.
For other hackers, none of this will register with Harold who will simply continue to spout as he likes to do and write emails to me, but everybody else can find out for themselves by downloading.
I'm not going to feed your self-importance by entering into public correspondence with you. This is all I'm going to write. If others want to get down with you, they can.
Yes, it does Harold and this is not the first or probably the last time you have placed misinformation about the Shen project online. All the files have the same standard 3 clause BSD license.
But it is the very last time that I will have any public connection with you and whatever you have to say on this thread or in email will not be read by me.
A small change to a large body of work does not give you copyright over the work itself. no matter how original your change is. At most only over the change itself.
Stallman's statement 'The FSF is not involved in this dispute' (about the appropriation of BSD under GPL) might be interpreted as a statement of ignorance (I don't know what is going on) or as a disclaimer of involvement (I know what is going on, but the FSF is not involved). I find both interpretations to be straining the bounds of credibility and certainly Stallman knew after Theo wrote to him.
But this is not the important issue that the thread is focused on - which are the relations between BSD and GPL. Stallman defends the appropriation of BSD code under GPL (at great length) based on a faulty interpretation of law and that interpretation needs to be put right.
The analogy of any of this to 9/11 or slavery seems rather silly.
I'll also add that I'll be asking for volunteer contributions on the Shen news group to help assemble this test suite. So people who want to expedite us here can do so.
Not really the same. That's rather like saying because I have a chassis and some wheels and an engine piled in the garage, I have a car. They have to be connected together in the right way to make Shen. Shen is available under Clojure and has been for about 2 years.
I'll also add that IMO there is a difference between having these features in a library and having them in the language standard. Common Lisp for instance, has had pattern-matching in various forms, but if you look at the code contributions on comp.lang.lisp these extensions are not often used.
I would say that the performance of Shen is very much a function of the platform and the person who did the port. The Merlin compiler in Qi II would, as doall points out, outpace the output of a Lisp programmer. I've yet to put all that technology into Shen.
Also, credit to the 2011 Shen committee members who ported Shen to so many platforms, the versatility of being being able to traffic Shen code across languages is what made Aditya's work and talk possible.
The license was introduced before Shen was issued in September 2011 (the license came out in June) and for a year or so the only specification was Shendoc (now Shendoc 16). The understanding was that Shen was specified in that document and what was not covered by Shendoc was covered by 'Functional Programming in Qi'. Later a hurriedly introduced text 'The Book of Shen (first edition)' (TBoS) was produced to fill a gap (2012) and this year (January 2014) a more thorough 2nd edition of TBoS (> 400 pages) was published which fixes the language standard very thoroughly. This is currently the canonical standard. You can find a link to that book on the Shen home page.
Shen is now very stable and has been for nearly two years. At my suggestion, I posited that it might be better to move the standard to a computable series of tests and this was floated to the 2011 committee that is responsible jointly for all the ports.
Such a change requires the unanimous consent of all the people involved and it seems we have this and a reworded simplified license.
The only obstacle is the work needed to put this test suite together. I've suggested that this suite might be assembled in Github, though for legal reasons the final version must be put in a publicly accessible but tamper-proof place.
Since the type-integrity given out by the system is not better than the strength of the kernel, we take kernel work very seriously. There is already a suite of 126 tests that I run every Shen port through and 2011 members echo these tests. But this informal test suite needs to be amped up to several hundred tests to approach what I consider to be an adequate test suite. It is very boring but important work. So far I have begun assembling all the programs in TBoS into this suite.
These license issues really only affect people who are deeply involved in kernel work and as far as application programmers are concerned, I doubt that it affects them much at all. As far as graphics, concurrency, FFI etc. and add-ons are concerned there are no restrictions. Likewise none on closed source work.
The issue here was not that the port was closed; but that people helped to build it and gave their time for free on the assumption it was going to be free and readable. My post
I have a clear policy of not contributing my time to closed (for money) software unless I am being paid as a consultant. I do not have any objection as such to closed source software.
Anybody discouraged from buying by the very limited hurdle getting the book will completely fail at the more substantial hurdle of understanding it.
Expecting everything for free, and creators giving in to that demand shapes character. Systems which reward minimal effort, maximal demand, and zero reciprocity end up selecting for the worst traits in both readers and communities.