May 09, 2012
"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:qlxeqfqyzlezwqerrkxn@forum.dlang.org...
> On Wednesday, 9 May 2012 at 19:58:14 UTC, Michaël Larouche wrote:
>>  What if I want to submit a change or a fix to the langage that require
>> to change the backend too ?
>
> There's nothing stopping that right now!
>
> The only thing the backend license really prohibits is distributing it yourself.
>

Even that's not entirely true (and it does annoy me a little that it keeps getting repeated). The only thing it prohibits is distributing it yourself *without prior approval*. And considering that Walter's always been extremely reasonable about granting such requests (since the prior approval is only required because *his* hands are tied on that matter by...uhh...was it Borland?), it's really a non-issue.

> Doing a personal fork, modifying it, and doing a pull request or a patch back upstream happens in practice somewhat normally.


May 09, 2012
On 09/05/12 23:47, deadalnix wrote:
> And even more practical : I can't bundle dmd with an IDE for D to provide an
> easy setup for a user. I can't create a repository where dmd sit in to make it
> easy t install on linux. This make it harder for beginner to get started with D.

Actually, "You can't bundle it with an IDE" was one of the exact examples I thought of making.

> Walter is arming his baby by trying to protect it.

I don't think this is Walter's intention as I believe he has worked quite hard to get that code open sourced.  AFAIK it's a constraint inherited from Digital Mars' past contractual obligations regarding that code.

May 09, 2012
On Wednesday, 9 May 2012 at 21:33:16 UTC, deadalnix wrote:
> I'm sorry but one would invest time in something he isn't even sure to be able to use himself.

Of course you can use it yourself! That's personal use,
not distribution.


Now, I get the annoyance in not distributing it (without
permission) - it bugs me with the D-> JS fork too.

But it isn't /that/ big of a deal. It doesn't impact
the development model.
May 09, 2012
On 09/05/12 23:38, Nick Sabalausky wrote:
> "Joseph Rushton Wakeling"<joseph.wakeling@webdrake.net>  wrote in message
> news:mailman.465.1336596027.24740.digitalmars-d@puremagic.com...
>>
>> The reason for proposing this is that currently if I wish to hack on
>> Druntime or Phobos, I _have_ to use DMD.  True parity of the open-source
>> compilers would be contributors being able to use their compiler of
>> choice.
>
> I didn't realize that was currently an issue. I agree, that ability would be
> nice.

Yesterday or the day before I pulled the latest Phobos into my dev branch and tried to compile it, only for some unittests to fall over rather nastily.  Of course, it was because the latest Phobos updates relied on some recent updates to DMD and/or Druntime: I had to pull and compile the latest versions of those before Phobos would compile and pass tests.

It's unlikely that GDC and/or LDC could pick up those sorts of updates quickly enough to not impact on developers, unless there's a deliberate policy of keeping feature parity.  So that means (for now) there's no way that one can reliably hack on Phobos using one of the fully open source compilers.

> Especially if/when we finally get good support for ARM-based phones
> and tablets (back in my day, we called them PDAs), as that would be
> completely non-DMD.

Yea, ARM support seems important to me too, both for phones, tablets etc. and for much of the new upcoming server solutions.  I also fancy coding with D on a Raspberry Pi. :-)

> Maybe, but I suspect most "not OSS" complaints would be coming from people
> who don't even know that much about D, and are just knee-jerking over "The
> main compiler's backend isn't OSS?!? Well fuck that, then!"

This is my fear as well. :-(
May 09, 2012
On Wednesday, 9 May 2012 at 20:59:11 UTC, Mehrdad wrote:
> What about SNN.lib, which has no source code (even assembly code) available whatsoever?

Well, the source is available if you buy it. $45 I think.
May 09, 2012
On Wednesday, May 09, 2012 17:52:39 Nick Sabalausky wrote:
> (since the prior approval
> is only required because *his* hands are tied on that matter by...uhh...was
> it Borland?),

Semantec. They own the backend that dmd uses.

- Jonathan M Davis
May 09, 2012
On Wednesday, May 09, 2012 23:47:57 deadalnix wrote:
> Le 09/05/2012 23:31, Joseph Rushton Wakeling a écrit :
> > On a more practical level, the inability of 3rd parties to distribute DMD could have an effect in limiting points of access to the software, with corresponding effects on the possible channels of contribution. The ability to scale up the number of distribution and contribution channels is going to be increasingly important as D develops.
> 
> And even more practical : I can't bundle dmd with an IDE for D to provide an easy setup for a user. I can't create a repository where dmd sit in to make it easy t install on linux. This make it harder for beginner to get started with D.
> 
> I can't even fork dmd. And this is probably the most important one.
> 
> FOSS typically work in a dictatorship manner. This is ok, because the dictator HAVE TO do the right thing, or the project will fork and a new dictator will take the lead.
> 
> Having a non open source compiler as reference implementation is a major issue. Unless you are microsoft, google or some other huge company, you can't afford that.
> 
> Walter is arming his baby by trying to protect it.

Umm. No. While Walter is the original creator of the backend, it was owned by the company that released it (Zortech) not him. Semantec bought Zortech, so they own the compiler. Digital Mars uses it with their permission (via licensing or leasing or whatever they did). So, Walter is bound by the license that Semantec uses for the backend.

http://en.wikipedia.org/wiki/Zortech http://en.wikipedia.org/wiki/Digital_Mars

Walter can give redrisribution permissions if you ask (which he typically does quite freely), but I don't believe that he can give blanket permissions, and he definitely can't change the license. He's tried. As I understand it, if Walter could make the backend GPL, he would, but he can't.

- Jonathan M Davis
May 09, 2012
On Wed, 09 May 2012 17:39:36 -0400, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:

> On 09/05/12 23:06, Steven Schveighoffer wrote:
>> So... Use GDC instead?
>
> .... and if I want to hack on Druntime or Phobos ... ? :-)
>
> [cf. what I was told here ... http://www.digitalmars.com/d/archives/digitalmars/D/learn/Hacking_on_Phobos_34765.html#N34770 ]

For what purpose?  To get it included in phobos/druntime?  DMD.  But it will percolate to gdc afterwards.

But that's not exactly a problem with distribution, is it?  If you're hacking phobos or druntime for purposes of improving phobos or druntime, why do you need to distribute snn.lib?

If you just want to distribute programs, and you don't want to distribute snn.lib with them (which you are free to do BTW), then use gdc.

-Steve
May 09, 2012
On Wednesday, May 09, 2012 23:00:16 Joseph Rushton Wakeling wrote:
> On 09/05/12 21:43, deadalnix wrote:
> > Le 09/05/2012 21:19, Nick Sabalausky a écrit :
> >> "deadalnix"<deadalnix@gmail.com> wrote in message news:jodll6$14eu$1@digitalmars.com...
> >> 
> >>> I'd that the most important part of FOSS isn't the license but the process. And we are not here yet.
> >> 
> >> How so?
> > 
> > We have a botleneck in accepting contributions.
> 
> To an extent that seems to parallel most projects with a small team of core developers -- if you don't have enough people with the right combination of expertise, understanding and time commitment, it's difficult to effectively cope with the volume of bug reports, feature requests and potential new contributors.
> 
> That said, I don't think you can entirely divorce contribution issues from the licence. One of the things that allows FOSS projects to scale effectively is that they have multiple distribution channels and (often) multiple partially independent development teams. E.g. if you take the Linux kernel, you have many different distros, many of which have internal kernel dev teams; you have multiple different ways to get a working copy of the kernel (the kernel.org website, your distro of choice, your Android mobile phone, your web host, your embedded device ...), all of which create corresponding points of entry for contribution.
> 
> That spread of 3rd-party distribution and modification _does_ rely on the licence, as those suppliers need to be able to freely work on the code without needing to go through a single upstream point of contribution, and they need to have certainty that the permission to do so is not conditional or potentially able to be rescinded.

The only thing that isn't fully open source is the dmd backend, and dmd gets more pull requests than druntime and Phobos combined (it's also the project with the biggest bottleneck, because _everything_ goes through Walter rather than a small group of developers). So, I don't think that the license is negatively impacting us at all as far as contributions go. It was having the source in svn rather than in git up on github which was the real problem. We've gotten _way_ more contributions (especially to dmd) ever since we put it all up on github.

- Jonathan M Davis
May 09, 2012
On 10/05/12 00:23, Steven Schveighoffer wrote:
> On Wed, 09 May 2012 17:39:36 -0400, Joseph Rushton Wakeling
> <joseph.wakeling@webdrake.net> wrote:
>> .... and if I want to hack on Druntime or Phobos ... ? :-)
>
> For what purpose? To get it included in phobos/druntime? DMD.

Well, yes, that's my point.  If I want to contribute to Phobos/Druntime, I _have_ to use a partially-proprietary program.  To me, that's an irritation.  To other potential contributors, it's a blocking factor.

> But that's not exactly a problem with distribution, is it? If you're hacking
> phobos or druntime for purposes of improving phobos or druntime, why do you need
> to distribute snn.lib?

I didn't say I did.  I'm just observing that contributing to the heart of the D project requires me to install and use proprietary code.

To me that's a tolerable compromise as (as you say) the changes percolate to the fully open source solutions, and in any case DMD is in practice very open.  But there are people who _aren't_ willing to make that compromise, and others who will be put off before they even realize that compromise is possible.