www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd front end now switched to Boost license

reply Walter Bright <newshound2 digitalmars.com> writes:
https://github.com/D-Programming-Language/dmd/pull/3655
Jun 12 2014
next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
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.
Jun 12 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Jun 12 2014
prev sibling next sibling parent Andrew Edwards <ridimz yahoo.com> writes:
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
Jun 13 2014
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Jun 13 2014
next sibling parent reply "Mathias LANG" <pro.mathias.lang gmail.com> writes:
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 ?
Jun 13 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Jun 13 2014
next sibling parent reply "Joakim" <dlang joakim.airpost.net> writes:
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.
Jun 14 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Jun 14 2014
prev sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
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
Jun 14 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2014 9:02 AM, Leandro Lucarella wrote:

 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.


Yes, it allows people to use DMDFE for whatever they want, including closed 
source proprietary tools.

I understand very well how upsetting someone taking your code, creating a CSPT 
and making money off of it without acknowledging you or contributing back to
it. 
This happened to me with my game Empire. It's a long and convoluted story, and
I 
won't bore you with it, just suffice to say I am not a stranger to how you feel 
about it.

But D is different from a game in that it has network effects - the more 
adoption it gets, the more momentum for adoption it accrues. By giving up a 
slice of the pie the pie more than grows enough to compensate.

In other words, the D community still gains even if there are a few CSPTs made 
from the front end.
Jun 14 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
Jun 13 2014
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Jun 14 2014
next sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
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
Jun 14 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Jun 14 2014
parent reply "Kapps" <opantm2+spam gmail.com> writes:
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.
Jun 14 2014
parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Kapps, el 14 de June a las 18:19 me escribiste:

 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.


Not if they don't contribute back the changes (at least compared to
using a license that allows them to build proprietary tools by linking
to DMDFE but forcing them to contribute back the changes to DMDFE
itself). I find hard to believe companies willing to do a full closed
source proprietary tool are willing to use DMDFE with Boost license but
not with LGPL.

In any case, I clarify once more that probably in practice this makes a
very tiny difference because usually you have to be too stupid to
maintain a fork instead of contributing changes back and let upstream
take care of all the updates, so I think that will hardly happens, this
is more a ethical issue than a practical issue.

I just wanted to point out that there might be more ethical licenses to
achieve the same effect (allowing companies to build proprietary tools
on top on DMDFE).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
¿Cómo estais? ¿Cómo os senteis hoy 29 del membre de 1961 día en que
conmemoreramos la nonésima setima nebulización del martir Peperino
Pómoro junto al Rolo Puente en la ciudad de Jadad?
	-- Peperino Pómoro
Jun 14 2014
parent Ben Boeckel via Digitalmars-d-announce writes:
On Sun, Jun 15, 2014 at 02:20:11 +0200, Leandro Lucarella via
Digitalmars-d-announce wrote:

 I just wanted to point out that there might be more ethical licenses to
 achieve the same effect (allowing companies to build proprietary tools
 on top on DMDFE).


There's MPL which is source-file-based copyleft (rather than link-time
copyleft).

--Ben
Jun 15 2014
prev sibling parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Saturday, 14 June 2014 at 17:07:58 UTC, Leandro Lucarella 
wrote:

 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.


The frontend was dual-licensed under the Artistic license, which 
also allows such proprietary use, so nothing has really changed.  
Rather than having two licenses, the Artistic license to allow 
linking against the proprietary dmd backend and the GPL to allow 
linking against the gcc backend, the dmd frontend now has a 
single Boost license that allows both, since the Boost license is 
considered GPL-compatible.

 From the standpoint of what the frontend's license allows, not 
much has changed, but the simplicity and clarity of the Boost 
license puts the frontend on firmer footing.

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.
Jun 14 2014
parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Joakim, el 14 de June a las 19:31 me escribiste:

 On Saturday, 14 June 2014 at 17:07:58 UTC, Leandro Lucarella wrote:

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.


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

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
El techo de mi cuarto lleno de galaxias
Jun 14 2014
parent "Joakim" <dlang joakim.airpost.net> writes:
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.
Jun 15 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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. ;)
Jun 14 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jun 14 2014
parent reply "David Nadlinger" <code klickverbot.at> writes:
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
Jun 14 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/14/2014 2:47 PM, David Nadlinger wrote:

 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,


Granted, it isn't a very big technical/legal argument, but I don't think 
those are the only important criteria. The thing is, D's licensing 
overall (DMDFE/DMDBE/LDC/GDC/Phobos) is kinda complicated. So any 
simplification, as long as it doesn't restrict anyone, is a net 
improvement, even if it isn't earth-shattering.


 but the DDMD
 <-> Phobos connection definitely makes the change very worthwhile in my
 opinion.


Yea, I agree too, I hadn't thought of that one either.
Jun 14 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 14 June 2014 at 19:27:44 UTC, Nick Sabalausky wrote:

 don't think those are the only important criteria. The thing 
 is, D's licensing overall (DMDFE/DMDBE/LDC/GDC/Phobos) is kinda 
 complicated. So any simplification, as long as it doesn't 
 restrict anyone, is a net improvement, even if it isn't 
 earth-shattering.


Indeed. Having a single license makes the project look focused 
rather than a conglomerate moving in different directions.
Jun 15 2014
prev sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
David Nadlinger, el 14 de June a las 18:47 me escribiste:

 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.


Agreed, so far this looks like the most important gain from the change,
and I can see some sense on using the boost license instead of something
like lgpl.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
Ambition makes you look pretty ugly
Jun 14 2014
prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d-announce writes:
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?"
Jun 14 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/14/2014 2:52 PM, Iain Buclaw via Digitalmars-d-announce wrote:

 On 14 June 2014 19:03, Nick Sabalausky via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 Uhh, *no*.

 Scenario A:
 --------------------------
 [..snip..]
 --------------------------

 Scenario B:
 --------------------------
 [..snip..]
 --------------------------

 I'll take B, thanks. ;)


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


I should! Heck, even I've noticed that.

I used to pride myself on terse writing. Then (for other reasons) I 
decided I needed to improve my writing skills. Verbosity became a bad 
side effect of that ;)
Jun 14 2014
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Jun 14 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/14/2014 2:52 PM, Dmitry Olshansky wrote:

 14-Jun-2014 22:03, Nick Sabalausky пишет:

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


 Me: WAT? Language is not a product in itself.


While that's technically true, people often think of them as complete 
products anyway. Esp with so many of the newer languages now having a 
"main"/"official" compiler/lib.


 What license C++ use then?
 In short, everything they care about was and is Boost.
Jun 14 2014