Red Hat's issues in considering the D language

[Matthias Klumpp via Digitalmars-d]

To clarify this point on the list:

On Thursday, 22 December 2016 at 10:40:32 UTC, Kagamin wrote:
> On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei 
> Alexandrescu wrote:
>> https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b
>
> Aren't requirements for packaging and recent versions mutually 
> exclusive? The packaged version will undergo version freeze and 
> will be older than the recent version no matter what you 
> package.

This is true when the distribution is frozen, but there is a time 
when we will just get new software versions in there as soon as 
they are released.
But the much more important point for us is support and 
maintainability. The reference compiler will have a much bigger 
development team and higher focus of attention. Additionally, 
people will likely build their code with that compiler and might 
not test with other compilers.
So, if we then take D code and build it with a configuration 
upstream didn't test, and then encounter a bug, this will be an 
additional obstacle to overcome when communicating with upstream.
Furthermore, the compiler package - once frozen - will have to be 
supported for many years, and a bigger team behind it helps in 
finding issues and fixing them. Additionally, people learning D 
will told "use DMD" and won't find it in their distribution, 
which is annoying for them (they think D isn't well supported, 
while our LDC/GDC packages are less used).

Those are all points which make it useful to have a completely 
free compiler as reference compiler and in the distribution.

On the point of "free" being ideological: It of course is also an 
ideological issue, but that's not the only point.
See this excerpt from the DMD backend license:
```
The Software is copyrighted and comes with a single user license,
and may not be redistributed. If you wish to obtain a 
redistribution license,
please contact Digital Mars.
```

This alone makes it impossible for use and all our derivatives to 
legally redistribute the software. Adding it to a distro is a 
no-op.
Also, licenses restricting modification of software or 
proprietary software in general makes it impossible for use to 
deliver security fixes, and also makes integrating the software 
into the system much harder and sometimes impossible.

For GDC: Being part of GCC would be very awesome there, because 
then the Toolchain team of the respective distributions could 
easily make the D compiler available and maintain it (as done 
with e.g. gccgo for the Go language). At time we patch in GDC and 
Debian, but it looks like Red Hat will not go that way on 
RHEL/Fedora (and I completely understand why they don't want to 
do that).
Anyway, it's great to hear that the GDC Phobos isn't as old 
anymore as it was when I wrote the first version of the list :)

> Confusing claim that he can't use dmd given that he says he 
> uses it.

Huh? Where is this stated?