June 14, 2014
Nick Sabalausky, el 14 de June a las 02:06 me escribiste:
> >>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.

Not really, the standard library is included into user code (because of the templates), and that's the reason why it needs to be under a very permissive license. The compiler, on the other hand, doesn't, and one could agree is good to force people wanting to build products using the compiler FE to contribute changes back. I guess the main purpose of this is encourage proprietary tools based on the FE, but if that's the case, there are better licenses for this, like the LGPL, which let proprietary tools to link code against the DMD FE without having to release their code under a free license.

With Boost, anyone can create a tool with DMD FE, improve the DMD FE in the process and distribute the modified DMD FE without offering the source code of the DMD FE to the received, which kind of sucks. In practice I guess not many people would do that, but I think it would have been a nice gesture to ask contributors how they feel about this license change, even when I think technically you are somehow giving up your rights to Digital Mars when contributing to DMDFE and thus they can do whatever they want with the code, legally speaking.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
Every 5 minutes an area of rainforest the size of a foot ball field Is eliminated
June 14, 2014
Dmitry Olshansky, el 14 de June a las 18:18 me escribiste:
> 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.

Except is completely invalid!

No free license restrict commercial use. What using boost enable is only proprietary use, i.e. changing the DMD FE and keeping the changes private, even if you distribute the binary with the compiled DMDFE. As I said before, there are licenses that allow anyone linking your code to non-free code, but you still have to provide the source code of the modified DMDFE if you distribute it. An example is LGPL.

> >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.

So, really, I all those 5 points are invalid.

All the license change allows is people using the work of others without contributing back, without any real necessity like with the standard library that contains templates or code that gets copy&pasted into the users code.

OK, as a side effect of this, this might encourage companies not to use D but to develop tools based on DMDFE, but companies that are too lazy or to BAD not to contribute the changes back, which I'm not sure is such a good idea.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
PITUFO ENRIQUE ATEMORIZA CATAMARCA, AMPLIAREMOS
	-- Crónica TV
June 14, 2014
On Saturday, 14 June 2014 at 17:07:58 UTC, Leandro Lucarella wrote:
> OK, as a side effect of this, this might encourage companies not to use
> D but to develop tools based on DMDFE, but companies that are too lazy
> or to BAD not to contribute the changes back, which I'm not sure is such
> a good idea.

I believe it is good thing. Standard tool chain should be as permissive as possible, with no expectations from the potential users whatsoever. If someone goes with proprietary closed solution and succeeds - it is their choice and risk to do so.
June 14, 2014
On 6/14/2014 3:58 AM, Joakim wrote:
> 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.

Well, GPL and Artistic are both OSI anyway.

June 14, 2014
On 6/14/2014 10:18 AM, Dmitry Olshansky wrote:
> 14-Jun-2014 04:46, Walter Bright пишет:
>>
>> 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.
>

Uhh, *no*.

Scenario A:
--------------------------
Them: "What license does D use?"

Us: "Well, it depends if you're talking about the compiler or Phobos, the standard library. Phobos is licensed under Boost, whereas the compiler is dual-licensed under both Artistic and one of the many GPLs. (Although the compiler's backend is a source-publicly-available proprietary due to insurmountable historical IP reasons. But GDC/LDC are fully OSS.)"

Them: "Uhh...what? And WHY? And WTF?"

Us: "You see, blah blah blah inclusion into user code blah blah Phobos templates blah blah blah GPL alternative blah blah GDC blah blah..."

Them: "Jeesus, nevermind..."
--------------------------

Scenario B:
--------------------------
Them: "What license does D use?"

Us: "Boost. (Although the compiler's backend is a source-publicly-available proprietary due to insurmountable historical IP reasons. But GDC/LDC are fully OSS.)"

Them: "Huh. Weird, but whatever."
--------------------------

I'll take B, thanks. ;)

June 14, 2014
On Saturday, 14 June 2014 at 17:17:34 UTC, Dicebot wrote:
> On Saturday, 14 June 2014 at 17:07:58 UTC, Leandro Lucarella wrote:
>> OK, as a side effect of this, this might encourage companies not to use
>> D but to develop tools based on DMDFE, but companies that are too lazy
>> or to BAD not to contribute the changes back, which I'm not sure is such
>> a good idea.
>
> I believe it is good thing. Standard tool chain should be as permissive as possible, with no expectations from the potential users whatsoever. If someone goes with proprietary closed solution and succeeds - it is their choice and risk to do so.

And if they do so, it's beneficial to D overall.
June 14, 2014
On 6/14/2014 11:03 AM, Nick Sabalausky wrote:
> I'll take B, thanks. ;)

Right on, Nick.

And there's another advantage I neglected to mention - it allows DMDFE code to be moved into Phobos without issues.
June 14, 2014
On Saturday, 14 June 2014 at 18:43:59 UTC, Walter Bright wrote:
> And there's another advantage I neglected to mention - it allows DMDFE code to be moved into Phobos without issues.

I don't think Nick's argument is particularly compelling, but the DDMD <-> Phobos connection definitely makes the change very worthwhile in my opinion.

David
June 14, 2014
On 14 June 2014 19:03, Nick Sabalausky via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> On 6/14/2014 10:18 AM, Dmitry Olshansky wrote:
>>
>> 14-Jun-2014 04:46, Walter Bright пишет:
>>>
>>>
>>> 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.
>>
>
> Uhh, *no*.
>
> Scenario A:
> --------------------------
> Them: "What license does D use?"
>
> Us: "Well, it depends if you're talking about the compiler or Phobos, the standard library. Phobos is licensed under Boost, whereas the compiler is dual-licensed under both Artistic and one of the many GPLs. (Although the compiler's backend is a source-publicly-available proprietary due to insurmountable historical IP reasons. But GDC/LDC are fully OSS.)"
>
> Them: "Uhh...what? And WHY? And WTF?"
>
> Us: "You see, blah blah blah inclusion into user code blah blah Phobos templates blah blah blah GPL alternative blah blah GDC blah blah..."
>
> Them: "Jeesus, nevermind..."
> --------------------------
>
> Scenario B:
> --------------------------
> Them: "What license does D use?"
>
> Us: "Boost. (Although the compiler's backend is a source-publicly-available proprietary due to insurmountable historical IP reasons. But GDC/LDC are fully OSS.)"
>
> Them: "Huh. Weird, but whatever."
> --------------------------
>
> I'll take B, thanks. ;)
>

You should really practise explaining things in a more succinct manner. ;-)

When I look at a project, my first question is never "What license does it use?" - that should be of little importance to anyone using D.

If you wish to contribute, your question should be smarter, reword the question to "Does this project allow me freely study, modify and re-distribute it's code, and does it guarantee that any contributions I make are released under the same freedom as I get when I received the software?"

June 14, 2014
14-Jun-2014 22:03, Nick Sabalausky пишет:
> On 6/14/2014 10:18 AM, Dmitry Olshansky wrote:
>> 14-Jun-2014 04:46, Walter Bright пишет:
>>>
>>> 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.
>>
>
> Uhh, *no*.
>
> Scenario A:
> --------------------------
> Them: "What license does D use?"

Me: WAT? Language is not a product in itself. What license C++ use then?
In short, everything they care about was and is Boost.

-- 
Dmitry Olshansky