Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I quite agree here, but to go a step further here:

Lots of people express this fear that BSD-licensing of components will lead to a world where all the big proprietary software just locks everything down. But if you actually work with large software, you end up finding out that it's actually a lot of work to maintain your own fork, and so you start pushing to get more things upstreamed. Because, after all, if your code is private, it's your task to fix it if somebody breaks it, but if it's upstreamed, it's their task to do it.

An interesting datapoint is LLVM/Clang, where, yes, lots of companies have their own proprietary forks of Clang. But for the most part, those companies still upstream gobs of stuff: most of the biggest contributors to the project are the people with the proprietary forks. Furthermore, as I understand it, basically everybody relying on EDG has, or is in the process of, worked to move off of it into Clang. Which, if EDG dies, means that the permissively-license Clang has done more to kill off proprietary compilers than copyleft-licensed GCC has.

The best defense against proprietary software is to make it too expensive for proprietary software to compete, and using a permissive license means you can trick the companies making proprietary software into helping you do that.



> An interesting datapoint is LLVM/Clang

It's also an example of the GPL not preventing corporations from building (and releasing under a more permissive license) non-GPL software.

Before Apple built Clang, they made a GCC plugin[0] which dumped the AST from the GCC frontend, and fed it into the LLVM backend. Sure, they published the source of their GCC modifications under the GPL, but that was nothing compared to the entirely novel backend, which was released under a far more permissive license.

Meanwhile, Stallman handcuffed GNU projects like Emacs for years[1] by refusing to expose GCC's AST in an effort to prevent something like this from happening.

[0]https://dragonegg.llvm.org

[1]https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00...


> Before Apple built Clang, they made a GCC plugin[0] which dumped the AST from the GCC frontend, and fed it into the LLVM backend.

But they didn't! Dragonegg is a GCC plugin, which didn't exist when work started on Clang--GCC plugins date to GCC 4.5, released in 2010, which is the same year that Clang became self-hosting.

The timeline is rather like this: LLVM originally relied on a hacked-up version of gcc 4.2 called llvm-gcc to create LLVM IR from source code. When GCC added support for plugins, there was the attempt to move that frontend to a more reliable framework, and that was Dragonegg. As far as I'm aware, Apple never contributed to the Dragonegg project itself. Dragonegg didn't last that long; by 2014, the project was completely dead. And for most of its life, the biggest interest in Dragonegg was to have some modicum of support for Fortran.

> Meanwhile, Stallman handcuffed GNU projects like Emacs for years[1] by refusing to expose GCC's AST in an effort to prevent something like this from happening.

By the time of that message, RMS's worst nightmare had come true with Dragonegg... only for Dragonegg to have already died due to a lack of demand for it.


You're right, I got Dragonegg mixed up with llvm-gcc. But my point stands – the GPL was completely ineffective at preventing someone from using it to bootstrap a new compiler infrastructure under a more permissive license.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: