On Tuesday, 16 September 2014 at 16:35:41 UTC, Joakim wrote:
As I said, I think you're focusing on the license too much, as any open source license allows forking, though you're right that the MIT/BSD licenses usually provide more incentive to do so. Regardless of the license, some here view fragmenting dialects as a problem, ie the specter of fragmentation exists whatever the open source license chosen.

Ok, but is it then ok if a "forked syntax" looks like Algol? Is it still an unhealthy fork? Why does it matter whether DMD or clang is underneath?

Walter keeps stating that he wants the forum behaviour to be professional. To me that means that the team that publish a product stands behind it in public, that includes the license, then keep the bickering internal to the team. If you sell an item with an instruction manual, you don't blame the user for pushing the wrong button if the instruction manual was flawed. You fix the instruction manual!

X11 was published under MIT style license. It was (partially?) funded by a consortium. Member companies got advance access to the source so they could ship physical X displays with the latest X version before the public got access. This is to me captures the spirit of BSD/MIT style licenses. You get to do what you want, no strings attached, but the primary concern is to be commercial friendly.

Semiotics matter. And MIT/BSD is associated with a tradition and a set of expectations, and so is GPL.

1. From MIT/BSD I expect commercial friendly to be first concern, community secondary. I expect the community to be more carefree.

2. From GPL I expect community friendly to be first concern, commercial secondary. I expect the community to be more emotionally involved.

I think there is some anecdotal evidence that GPL projects often are better at grooming/growing their communities and that the GPL forks are merged back after a while (xemacs/se linux?), while BSD fork more easily and cooperate by copy-pasting back and forth between forks?

muddied the waters. However, I think automated syntax translation might be a worthwhile solution for such syntax fragmentation these days.

Yes, that is probably right.

Walter is well aware of the tradeoffs, as he's had his own code misappropriated before and still thinks the potential benefits of closed tools are worth it:

Yeah sure, I already pointed out that I am certain that the implications of the license choice was deliberate to the original author.

Reply via email to