On Tuesday, 7 July 2020 at 09:28:26 UTC, Guillaume Piolat wrote:
> On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote:
>> That's right, it's not about the licensing. It's that the DLF should control the code it distributes.
>>
>> Businesses will not want to commit to a balkanized project.
>>
>
> From a business point of view, having slightly more correct string to float conversion holds very little value. I'll stick with sscanf thanks...

For a high tech real markets (airspace, automotive, science, military-industrial complex) having a correct decimal literal parsing has a little but absolutely mandatory value. If SpaceX is lending a rocket, they want it located on the platform, something around wouldn't make sense. Note, that these companies hold a huge amount of the legacy C/C++ code and they are potential Dlang markets. But only if Dlang will be able to match C exactly for numeric code. Otherwise merging C/C++ code would have a huge negative impact on them.

On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote:
> On 7/5/2020 5:46 AM, Joseph Rushton Wakeling wrote:
>> On Sunday, 5 July 2020 at 11:07:55 UTC, 9il wrote:
>>> There is no risk for DMD and DFL to depend on a Mir's Boost licensed library. If something happens with Mir or Mir change the license, DFL will be able to fork the required code at any point in the Boost licensed part of git history.
>> 
>> Can't speak for Walter or the D foundation here, but I'm not sure the concern is really about licensing.  It's about putting in place a required dependency on code where maintenance decisions are outside the hands of the D Foundation.
>
> That's right, it's not about the licensing. It's that the DLF should control the code it distributes.
>
> Businesses will not want to commit to a balkanized project.
>
> The proposal is for Mir to become a central required component of DMD and Phobos. This means it needs to become part of the D Language Foundation.

These don't serve my business needs. DLF doesn't serve my business needs. DLF blocks the initiatives my business needs. For the current state of things being a part of DLF codebase for Mir is nonsense.

On 7/7/20 7:13 AM, 9il wrote:
> On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote:
>> On 7/5/2020 5:46 AM, Joseph Rushton Wakeling wrote:
>>> On Sunday, 5 July 2020 at 11:07:55 UTC, 9il wrote:
>>>> There is no risk for DMD and DFL to depend on a Mir's Boost licensed library. If something happens with Mir or Mir change the license, DFL will be able to fork the required code at any point in the Boost licensed part of git history.
>>>
>>> Can't speak for Walter or the D foundation here, but I'm not sure the concern is really about licensing.  It's about putting in place a required dependency on code where maintenance decisions are outside the hands of the D Foundation.
>>
>> That's right, it's not about the licensing. It's that the DLF should control the code it distributes.
>>
>> Businesses will not want to commit to a balkanized project.
>>
>> The proposal is for Mir to become a central required component of DMD and Phobos. This means it needs to become part of the D Language Foundation.
> 
> These don't serve my business needs. DLF doesn't serve my business needs. DLF blocks the initiatives my business needs. For the current state of things being a part of DLF codebase for Mir is nonsense.

Guys, this is all open source, all licensed identically. There are ways to solve this. Practically speaking, just because DMD depends on Mir, doesn't mean that Mir has control over how the dependency works. DMD can depend on a specific version of Mir, upgraded when reasonable (i.e. it should take a PR change to DMD for upgrading which code exactly is depended on) and if something changes in the future, you can fork it, or move back to using libc. This way, the code is only maintained in one place unless something catastrophic happens.

In this sense, the DLF *does* control which code is used, as well as if it were in the DMD repository itself.

We have a boost license for a reason.

-Steve

On Tuesday, 7 July 2020 at 10:58:25 UTC, 9il wrote:
>> From a business point of view, having slightly more correct string to float conversion holds very little value. I'll stick with sscanf thanks...
>
> For a high tech real markets (airspace, automotive, science, military-industrial complex) having a correct decimal literal parsing...

Phobos is the stdlib of the language. Mir is not.
Likewise, you've made the std.experimental.allocator on DUB depends on mir-core... stdlib shouldn't depend on non-stdlib, there isn't anything to debate on this point.

On Tuesday, 7 July 2020 at 12:14:16 UTC, Guillaume Piolat wrote:
> [snip]
>
> Likewise, you've made the std.experimental.allocator on DUB depends on mir-core...

Is that not an example of how Steve thinks it should work? Both are Boost licensed. mir-core has no external dependencies. Ilya could split the parse/bignum packages to a separate repo with no other dependencies and then public import them in mir-algorithm and just normally import them elsewhere.

> stdlib shouldn't depend on non-stdlib, there isn't anything to debate on this point.

Walter's original comment was about adding it to DMD. He may have intended Phobos, but I read it as DMD.

On Tuesday, 7 July 2020 at 12:33:40 UTC, jmh530 wrote:
> On Tuesday, 7 July 2020 at 12:14:16 UTC, Guillaume Piolat wrote:
>> [snip]
>>
>> Likewise, you've made the std.experimental.allocator on DUB depends on mir-core...
>
> Is that not an example of how Steve thinks it should work? Both are Boost licensed. mir-core has no external dependencies. Ilya could split the parse/bignum packages to a separate repo with no other dependencies and then public import them in mir-algorithm and just normally import them elsewhere.
>
>> stdlib shouldn't depend on non-stdlib, there isn't anything to debate on this point.
>
> Walter's original comment was about adding it to DMD. He may have intended Phobos, but I read it as DMD.

Eh, it looks like parse.d depends on std. So it wouldn't make sense to add to DMD since then the compiler would depend on the standard library.

On Tuesday, 7 July 2020 at 12:35:57 UTC, jmh530 wrote:
> On Tuesday, 7 July 2020 at 12:33:40 UTC, jmh530 wrote:
>> On Tuesday, 7 July 2020 at 12:14:16 UTC, Guillaume Piolat wrote:
>>> [...]
>>
>> Is that not an example of how Steve thinks it should work? Both are Boost licensed. mir-core has no external dependencies. Ilya could split the parse/bignum packages to a separate repo with no other dependencies and then public import them in mir-algorithm and just normally import them elsewhere.
>>
>>> [...]
>>
>> Walter's original comment was about adding it to DMD. He may have intended Phobos, but I read it as DMD.
>
> Eh, it looks like parse.d depends on std. So it wouldn't make sense to add to DMD since then the compiler would depend on the standard library.

All std.* dependencies in Mir are minor and can be replaced in a day.

On Tuesday, 7 July 2020 at 12:14:16 UTC, Guillaume Piolat wrote:
> On Tuesday, 7 July 2020 at 10:58:25 UTC, 9il wrote:
>>> From a business point of view, having slightly more correct string to float conversion holds very little value. I'll stick with sscanf thanks...
>>
>> For a high tech real markets (airspace, automotive, science, military-industrial complex) having a correct decimal literal parsing...
>
> Phobos is the stdlib of the language. Mir is not.
> Likewise, you've made the std.experimental.allocator on DUB depends on mir-core... stdlib shouldn't depend on non-stdlib, there isn't anything to debate on this point.

Mir is stdlib for my business. Phobos is not. It wasn't me who proposed to use Mir code in DMD. I have heard Walter. There isn't anything to debate on this point.

On Tuesday, 7 July 2020 at 12:04:43 UTC, Steven Schveighoffer wrote:
> On 7/7/20 7:13 AM, 9il wrote:
>> [...]
>
> Guys, this is all open source, all licensed identically. There are ways to solve this. Practically speaking, just because DMD depends on Mir, doesn't mean that Mir has control over how the dependency works. DMD can depend on a specific version of Mir, upgraded when reasonable (i.e. it should take a PR change to DMD for upgrading which code exactly is depended on) and if something changes in the future, you can fork it, or move back to using libc. This way, the code is only maintained in one place unless something catastrophic happens.
>
> In this sense, the DLF *does* control which code is used, as well as if it were in the DMD repository itself.
>
> We have a boost license for a reason.
>
> -Steve

Exactly. Thank you

On Tuesday, 7 July 2020 at 07:49:02 UTC, Walter Bright wrote:
> Businesses will not want to commit to a balkanized project.

It's been ages since I worked on a software project for a business that didn't have many random third (and fourth and fifth and sixth and seventh.....) party dependencies. Trying to remove or avoid them would universally encounter pushback from management. "Don't reinvent the wheel" they say.

It is really absurd.


But anyway this whole debate is moot because if you like the code, you can simply copy/paste it (with attribution as required by Boost copyright of course) into your own files. You keep full control and get all the benefits of using it.