https://github.com/D-Programming-Language/dmd/pull/3655

On Friday, 13 June 2014 at 00:31:32 UTC, Walter Bright wrote:
> https://github.com/D-Programming-Language/dmd/pull/3655

Glad to hear it. Boost is such a simple license.

On 13/06/14 02:31, Walter Bright wrote:
> https://github.com/D-Programming-Language/dmd/pull/3655

Awesome. Thanks for opening up to a less restrictive license.

-- 
/Jacob Carlborg

On 6/12/14, 8:31 PM, Walter Bright wrote:
> https://github.com/D-Programming-Language/dmd/pull/3655


Seems you missed a few:

https://github.com/D-Programming-Language/dmd/search?q=Artistic+License&ref=cmdform

13-Jun-2014 04:31, Walter Bright пишет:
> https://github.com/D-Programming-Language/dmd/pull/3655

It's probably nice to have less restrictive license, but what we aim to achieve with that?

Make commercial companies contribute to DMD more freely?
	There is no problem even with GPL.
Let them build and sell their own products out of DMDFE?
	Highly unlikely to be a profitable anyway, and we'd better get back the patches.


-- 
Dmitry Olshansky

On Friday, 13 June 2014 at 11:31:10 UTC, Dmitry Olshansky wrote:
> 13-Jun-2014 04:31, Walter Bright пишет:
>> https://github.com/D-Programming-Language/dmd/pull/3655
>
> It's probably nice to have less restrictive license, but what we aim to achieve with that?
>
> Make commercial companies contribute to DMD more freely?
> 	There is no problem even with GPL.
> Let them build and sell their own products out of DMDFE?
> 	Highly unlikely to be a profitable anyway, and we'd better get back the patches.

Wild guess: DMD in fedora, debian et al. repositories ?

On 6/13/2014 4:31 AM, Dmitry Olshansky wrote:
> It's probably nice to have less restrictive license, but what we aim to achieve
> with that?

1. Boost is the least restrictive license

2. Minimize friction for adopting D

3. Harmonization with usage of Boost in the runtime library

4. Allow commercial use of DMDFE (so what if someone does? It'll drive even more adoption of D!)

5. Boost is well known and accepted

On 6/13/2014 8:15 PM, Mathias LANG wrote:
> On Friday, 13 June 2014 at 11:31:10 UTC, Dmitry Olshansky wrote:
>> 13-Jun-2014 04:31, Walter Bright пишет:
>>> https://github.com/D-Programming-Language/dmd/pull/3655

Heh, I had been under the impression was already Boost. :P

>>
>> It's probably nice to have less restrictive license, but what we aim
>> to achieve with that?
>>
>> Make commercial companies contribute to DMD more freely?
>>     There is no problem even with GPL.
>> Let them build and sell their own products out of DMDFE?
>>     Highly unlikely to be a profitable anyway, and we'd better get
>> back the patches.
>
> Wild guess: DMD in fedora, debian et al. repositories ?

I doubt it. First, it's the backend that's not technically OSI, frontend was (apparently) GPL. Second, I can't imagine any Linux distro rejecting GPL - they'd have to boot the kernel and core utils, too.

Boost has kinda become the favored "D" license anyway, Phobos etc., so it probably has a lot to do with that. Kinda weird to have the compiler and stdlib under different licenses.

On Saturday, 14 June 2014 at 06:07:08 UTC, Nick Sabalausky wrote:
> I doubt it. First, it's the backend that's not technically OSI, frontend was (apparently) GPL. Second, I can't imagine any Linux distro rejecting GPL - they'd have to boot the kernel and core utils, too.

Actually, the frontend was dual-licensed under the Artistic license and the GPL and dmd binaries were provided under the former, as the GPL doesn't allow linking against a non-GPL backend.  The GPL alternative was likely for gdc to link the frontend against the GPL'd gcc backend.

14-Jun-2014 04:46, Walter Bright пишет:
> On 6/13/2014 4:31 AM, Dmitry Olshansky wrote:
>> It's probably nice to have less restrictive license, but what we aim
>> to achieve
>> with that?
>

I do not want to come across as rude but from pragmatic standpoint it's not interesting. I'm not opposing it (after all I agreed to change it), I just don't see any valuable gains.

> 1. Boost is the least restrictive license

This gains nothing in and by itself. 4 speaks of potential adv, which realistically is not something we desperately want. Maybe as a proactive move, that I could understand.

>
> 2. Minimize friction for adopting D

Let's not deluge ourselves, it does nothing to do that unlike many other things. Changing license of G++ frontend to boost won't make people adopt C++ any faster.

The only place of friction is backend, and opening FE for commerce doesn't help it.

> 3. Harmonization with usage of Boost in the runtime library
>

In other words simplify licensing, but again compiler and runtime library do not have to have anything in common. There is no issue to begin with.

> 4. Allow commercial use of DMDFE (so what if someone does? It'll drive
> even more adoption of D!)

The only strictly valid point. Making commercial compilers and tools on D front-end is the only solid result this move enables.

> 5. Boost is well known and accepted

All of licenses are well known. Again by itself it's not interesting, it won't make dmd any more easy to get into FOSS distros.

-- 
Dmitry Olshansky