Hacker News Reader

Comment by LukeShu | Hacker News Reader

There has been out-of-tree GCC support for D for several years. I wonder what has changed that they're letting it in to the official repository.

View on HN

The reference compiler got open sourced about 2 months ago.

https://news.ycombinator.com/item?id=14060846

How does this work exactly from a licensing perspective? Will they merge the dmd sources into the gcc tree? Does this mean that the D compiler in gcc will now be GPL(v?) licensed? This is certainly possible since dmd is licensed permissively.

https://github.com/dlang/dmd/blob/master/LICENSE.txt

I don't mean this to start a fight over licenses I'm just curious how it works when gcc lets other projects in.

I don't see how dmd would be mergable with gcc, completely different backends. gdc however is a different story.

Although the recent DMD backend license change does not affect GDC, GDC is not a complete standalone implementation of a D compiler.

GDC (and LDC, the LLVM D compiler) use the frontend (lexer, parser,semantic) provided by the DMD reference compiler. GDC and LDC then map the AST produced by the frontend to something GCC and LLVM understand.

The DMD frontend has always been boost licensed. So the licensing question is valid here as we'll include boost frontend code into GCC. But I don't really have an answer to the question ;-)

In general, it's possible to create a combined work made from parts with different licenses, provided that the licenses are compatible. So if you have part A licensed under, say, the MIT license, and part B licensed under the GPL, then the combined work falls under the GPL (due to the GPL "virability", and since the GPL and MIT are compatible in the sense that the GPL restrictions are a superset of MIT ). You can still later on extract part A and distribute that under the MIT license.

I don't know the details of the D compiler frontend that has now become part of GCC, but I'd imagine its something like that. E.g. the GCC Go frontend is, AFAIK, BSD licensed.

The reference compiler is unrelated.

The frontend has been Free Software since the beginning. The reference backend was only Open Source (not freely redistributable).

So, alternative backends were plugged to the frontend, LLVM and GCC. They all share the same frontend still, although LLVM and GCC slightly lag behind the reference in version (LLVM is nearly in sync).

This announcement is official recognition after Iain and helpers did the grunt work consistently for years now.

> The reference backend was only Open Source (not freely redistributable).

Free redistributibility is part of the Open Source Definition. It is literally the first item: https://opensource.org/osd-annotated

I think they meant lower case "open source" (as in the source is open (anyone can read/compile it)). There are plenty of software that are open source but not freely distributable, such as Unreal Engine.

"open source", no matter the capitalization, means what the OSI has defined. Unreal Engine is neither Open Source nor open source. It is simply proprietary. To say otherwise is a practice known as "open washing" that companies use to appear community friendly when in fact they are not.

This. While OSI may not have been successful in getting an official trademark on the phrase "Open Source", in practice almost everybody treats "Open Source" or "open source" as meaning what the Open Source Definition states. Other "source available" approaches are more correctly termed "shared source" or something.

Since when does "open-source" mean "community-friendly"? Why insist on using words that don't say what you want them to mean, when you can use ones that do?

The usual term for that sort of arrangement would be "shared source".

I've seen "source-available" as well. But yes, it's not "open source" if it's proprietary source that you can only look at.

You can do a lot more than look at it. You can modify it, compile it, share your modifications, and share your binaries with your game.

The one major thing you can't do is redistribute the base source code. That's a big thing, and disqualifies it from being open source, but let's not pretend there is no value in the source code access.

The first time I said that on HN somewhere else I got quite a flak. I don't know when OSI's definition became mainstream. The first time I heard open source, it meant the same as what you said. Nowadays you have to use a different term for that.

Collins still has the old definition "free to use or modify". Merriam-Webster and Oxford has since included "redistribution" in the definition.

The term "shared source" is not in any dictionary though.

> I don't know when OSI's definition became mainstream. The first time I heard open source, it meant the same as what you said. Nowadays you have to use a different term for that.

The notion that the phrase "open source" started out with broader definition but was later revised by OSI is itself revisionism.

OSI's definition is important because the phrase "open source" originates with the folks behind OSI—the term did not exist before 1998 when they created it. The phrase resulted from a public awareness effort leading up to the release of the Mozilla code on March 31, because the only alternative that had legs at the time was the FSF's term "free software", which had marketability problems. A few months later, a bunch of those involved in the brainstorming session where "open source" was coined went on to start the OSI as an advocacy group primarily concerned with:

a) marketing the term "open source" to get the public to adopt it en masse

b) advocating for the adoption of open source ideals themselves

To sum up, there has never been a time when "open source" meant something besides how the OSI defined it, except for sloppy usage in instances of someone co-opting the OSI's term but not their definition for it.

(Disagree with whether it's a good definition or not, but telling history and facts wrong is something to be avoided.)

I wrote a blog post about that:

http://jordi.inversethought.com/blog/5-things-we-have-forgot...

"Shared source" seems to originate from Microsoft, from the time period before it embraced OSS proper. At least the first time I've seen it in any context was the "shared source CLI", which was released under the look-but-do-not-touch license as a reference implementation to back the ECMA CLI and C# standards.

https://en.wikipedia.org/wiki/Shared_Source_Common_Language_...

That said, it's a surprisingly good term, because it's so accurate - the source is shared with you, but there isn't much you can do with it other than look at it.

> unrelated

Pedantically, you are correct. But making the whole thing Free Software has cleared up a lot of confusion about this issue, and has undoubtedly helped. Perception matters.

My guess is that is also why. gcc wants to be assured there are sufficient maintainers. If a crew has been maintaining out-tree-support with a good track record, that demonstrates maintainability.

Is this what happened to gcj, lack of maintainers? I always thought it was a shame support for it lapsed, a to native java compiler would be awefully nice to have.

Could be. I don't know the specifics. I do know that the bar is pretty high, in general, before gcc will commit. I think that simply goes with the territory with such a large project where a lot of people depend on it to just work.

For example, an acquaintance plays (at least used to) a large role in the AVR (8 bit) back-end. He went to a gcc summit to lobby for avr-gcc being upgraded to a support tier where functional (not performance) regressions would be release show-stoppers. His argument: Over a million downloads per month. It took that much to get the gcc steering committee to even consider it. gcc is a big project, they can't afford to make commitments lightly.

The out of tree codebase - was extensively updated with development being led by Ian Buclaw. Ian has given some presentations on all the changes and updates at the recent D language conference - Dconf 2017. see https://www.youtube.com/watch?v=g-5T4zlc_bc

I think the main factor is that the primary contributor to GDC (Iain) made a giant push for this to happen in the last 6-12 months. Just look at this graph: https://github.com/D-Programming-GDC/GDC/graphs/contributors

Great work, Iain!!!

>> I wonder what has changed that they're letting it in to the official repository.

<sarcasm (or something)> Because they need an alternative to the mess that is C++ and Rust is already married to LLVM.</sarcasm>

Reply on news.ycombinator.com