<p><br>
On Jun 26, 2013 9:00 PM, "Joakim" <<a href="mailto:joakim@airpost.net">joakim@airpost.net</a>> wrote:<br>
><br>
> On Wednesday, 26 June 2013 at 19:26:37 UTC, Iain Buclaw wrote:<br>
>><br>
>> From a licensing perspective, the only part of the source that can be "closed off" is the DMD backend.  Any optimisation fixes in the DMD backend does not affect GDC/LDC.<br>
><br>
> This is flat wrong. I suggest you read the Artistic license, it was chosen for a reason, ie it allows closing of source as long as you provide the original, unmodified binaries with any modified binaries.  I suspect optimization fixes will be in both the frontend and backend.<br>

></p>
<p>Code generation is in the back end, so the answer to that is simply 'no'.<br><br></p>
<p>>> You should try reading The Cathedral and the Bazaar if you don't understand why an open approach to development has caused the D programming language to grow by ten fold over the last year or so.<br>
>><br>
>> If you still don't understand, read it again ad infinitum.<br>
><br>
> Never read it but I have corresponded with the author, and I found him to be as religious about pure open source as Stallman is about the GPL.  I suggest you try examining why D is still such a niche language even with "ten fold" growth.  If you're not sure why, I suggest you look at the examples and reasons I've given, as to why closed source and hybrid models do much better.<br>

></p>
<p>Then you should read it, as the 'cathedral' in question was GCC - a project started by Stallman. :)<br><br></p>
<p>>> Think I might just point out that GDC had SIMD support before DMD. And that Remedy used GDC to get their D development off the ground.  It was features such as UDAs, along with many language bug fixes that were only available in DMD development that caused them to switch over.<br>

>><br>
>> In other words, they needed a faster turnaround for bugs at the time they were adopting D, however the D front-end in GDC stays pretty much stable on the current release.<br>
><br>
> Not sure what point you are trying to make, as both gdc and dmd are open source.  I'm suggesting closing such patches, for a limited time.<br>
></p>
<p>Closing patches benefit no one.  And more to the point,  you can't say that two compiler's implement the same language if both have different language features.<br></p>
<p>>>> I see no reason why another "upcoming" project like D couldn't do the same. :)<br>
>><br>
>><br>
>> You seem to be confusing D for an Operating System, Smartphone, or any general consumer product.<br>
><br>
> You seem to be confusing the dmd compiler to not be a piece of software, just like the rest, or the many proprietary C++ compilers out there.<br>
></p>
<p>You seem to think when I say D I'm referring to dmd, or any other D compiler out there.<br><br></p>
<p>><br>
>> - The language implementation is open source. This allows anyone to take the current front-end code - or even write their own clean-room implementation from ground-up - and integrate it to their own backend X.<br>

><br>
> Sort of.  The dmd frontend is open source, but the backend is not under an open source license.  Someone can swap out the backend and go completely closed, for example, using ldc (ldc used to have one or two GPL files, those would obviously have to be removed).<br>

></p>
<p>The backend is not part of the D language implementation / specification. (for starters, it's not documented anywhere except as code).<br></p>
<p>>> - The compiler itself is not associated with the development of the language, so those who are owners of the copyright are free to do what they want with their binary releases.<br>
>><br>
>> - The development model of D on github has adopted a "pull, review and merge" system, where any changes to the language or compiler do not go in unless it goes through proper coding review and testing (thank's to the wonderful auto-tester).  So your suggestion of an "open core" model has a slight fallacy here in that any changes to the closed off compiler would have to go through the same process to be accepted into the open one - and it might even be rejected.<br>

><br>
> I'm not sure why you think "open core" patches that are opened after a time limit would be any more likely to be rejected from that review process.  The only fallacy I see here is yours.<br>
></p>
<p>Where did I say that? I only invited you to speculate on what would happen if a 'closed patch' got rejected.  This leads back to the point that you can't call it a compiler for the D programming language if it derives from the specification / implementation. <br>
</p>
<p>><br>
>> DMD - as in refering to the binary releases - can be closed / paid / whatever it likes.<br>
>><br>
>> The D Programming Language - as in the D front-end implementation - is under a dual GPL/Artistic license and cannot be used by any closed source product without said product releasing their copy of the front-end sources also.  This means that your "hybrid" proposal only works for code that is not under this license - eg: the DMD backend - which is not what the vast majority of contributors actually submit patches for.<br>

><br>
> Wrong, you have clearly not read the Artistic license.<br>
></p>
<p>I'll allow you to keep on thinking that for a while longer...<br></p>
<p>>> If you strongly believe that a programming language can't be big (as in 1M users) without being partly closed source, I suggest you do your research better.<br>
><br>
> I have done my research and provided examples: you provide none.  I suggest it is you who needs to research this topic.  Start with reading the Artistic license. :)<br>
></p>
<p>All I've seen from you from my skim,  snore, skip,  skim are projects started by multi-millionaire companies who have both resource, influence, and marketing behind them.  The contributors who have helped design and shape the D programming language are neither of these. </p>