dmd front end now switched to Boost license

[Joakim via Digitalmars-d-announce]

On Sunday, 15 June 2014 at 01:08:00 UTC, Leandro Lucarella wrote:
> Joakim, el 14 de June a las 19:31 me escribiste:
>> The frontend was dual-licensed under the Artistic license, 
>> which
>> also allows such proprietary use, so nothing has really 
>> changed.
>
> Mmm, even when is true that the Artistic license is a bit more
> permissive than the GPL in some aspects, I think is hardly 
> suitable for
> doing serious proprietary software (that you intent to sell).
>
> From the artistic license that was distributed by DMD:
> "You may not charge a fee for this Package itself. However, you 
> may
> distribute this Package in aggregate with other (possibly 
> commercial)
> programs as part of a larger (possibly commercial) software 
> distribution
> provided that you do not advertise this Package as a product of 
> your
> own."
>
> Is a bit hairy, I don't think any companies would want to do 
> proprietary
> tools using the artistic license :)
>
> https://github.com/D-Programming-Language/dmd/blob/083271a415716cf3e35321f91826397d91c0a731/src/artistic.txt

I was referring to this clause from the Artistic license:

"4. You may distribute the programs of this Package in object 
code or
executable form, provided that you do at least ONE of the 
following:

     a) distribute a Standard Version of the executables and 
library files,
     together with instructions (in the manual page or equivalent) 
on where
     to get the Standard Version."

So you could have always distributed a modified, closed ldc with 
the frontend under the Artistic license- it would have to be ldc 
as the dmd backend is proprietary- as long as you also provided 
an unmodified ldc along with it.

I don't think the part of the Artistic license you excerpted 
would apply to such a modified program, but even if the 
advertising part applied, I doubt any commercial user would care. 
  Usually those who take your code _don't want_ to advertise where 
they got it from. ;)

>> I realize you prefer the LGPL, to force others to contribute 
>> back to
>> the frontend if they modify and distribute it, but the Boost 
>> license
>> is much simpler and as Walter points out, proprietary use can 
>> help
>> D's adoption.
>
> Again, I think from the practical point of view is the same. If 
> you use
> boost license and tons of proprietary tools come out CHANGING 
> the DMDFE
> and not contributing back, then the D community might get a 
> boost
> because the have better tools but they are missing the 
> contributions, so
> is hard to tell if the balance would be positive or negative. 
> If they
> don't change the DMDFE (or contribute back the changes), then 
> using
> boost or LGPL are the same, because it doesn't matter.

Having better-quality paid tools would be a big boost, whether 
they released their patches or not.  You point out that 
commercial users could always link against a LGPL frontend as a 
library and put their proprietary modifications in their own 
separate library, but that can be very inconvenient, depending on 
the feature.

Also, I've pointed out a new model on this forum before, where 
someone could release a closed, paid D compiler but have a 
contract with their customers that all source code for a 
particular binary will be released within a year or two.  This 
way, you get the best of both worlds, revenue from closed-source 
patches and the patches are open-sourced eventually.  Such mixed 
models or other experimentation is possible under the freedom of 
more permissive licenses like Boost, but is usually much harder 
to pull off with the LGPL, as you'd be forced to separate all 
proprietary code from the LGPL frontend.