Hacker News new | past | comments | ask | show | jobs | submit login

The difference being that vendors forks not compliant with GPL can be legally asked for the changes they haven't sent upstream.



With LLVM they don't need to fork it in the first place. But still, it doesn't matter because ISO compliance is a frontend problem.

The one vendor who forks LLVM and doesn't contribute their biggest patches back is Apple, and if you want bleeding edge or compliance you're not using Apple Clang at all.

If you say "isn't it great vendor toolchains have to contribute back to upstream?" I'm going to say "no, it sucks that vendor toolchains have to exist"


Forcing vendors to contribute back upstream is an attempt at making vendor toolchains not exist.

If a company makes a new MCU with some exciting new instruction set, they need to make a compiler available which supports that instruction set and make that compiler available to their customers.

With LLVM as the base, the vendor could make their toolchain proprietary, making it impossible to integrate it back into LLVM, which means the vendor toolchain will exist until the ISA gets wide-spread enough for volunteers to invest the time required to make a separate production-quality LLVM back-end from scratch.

With GCC as the base, the vendor must at least make their GCC fork available to their customers under the GPL. This, in theory, allows the GCC community to "just" integrate the back-end developed by the vendor into GCC rather than starting from scratch.

Now I don't know how effective this is, or how much it happens in practice that the GCC project integrates back-ends from vendor toolchains. But in principle, it's great that vendors have to make their toolchains FOSS because it reduces the need for vendor toolchains.


Myth: GPL means more companies contribute to GCC

Previous reality: companies write fully proprietary code to avoid GCC

Current reality: companies choose Clang over GCC because of the license and then contribute many of their changes back.


gcc requires that contributors assign copyright to FSF (or at least "certify the Developer Certificate of Origin")[0], so a fork isn't gonna get upstreamed without the approval of the fork's authors. So that limits the benefit from gcc-forks to individuals keeping the fork alive.

[0]: https://gcc.gnu.org/contribute.html#legal


>making it impossible to integrate it back into LLVM

Code getting open source is not impossible. Companies do it all of the time because it's expensive to rebase.


Dude you can't just quote a fraction of a sentence and then argue against that fragment. Read the whole sentence. The part about how "the vendor could make their toolchain proprietary" is kinda important.


My comment was about proprietary software being open sourced.


My comment was about forcing companies to not make proprietary software.


So are you aware how many contributions have actually been upstream by Sony, Nintendo, IBM, ARM, Green Hills, Codegear, TI, Microchip, Codeplay, NVidia, AMD, Intel, HP,.... ?

Because Apple certainly isn't alone.


The question is less what's upstream than what's not.


The question is who is leeching clang while pumping the cash register.


Venders who use llvm quickly discover the cost of mainaining their own fork is too high and end up contributing back.


The point was the whole clang package, and no they don't, plenty of examples.


Except they do, plenty of examples (many already provided)


Examples yes, I provided the examples of everyone taking advantage while not contributing.

I am still waiting for the counter examples regarding clang contributions.


Clang is in git with good tracking of who each contributor is - there are more than 4000.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

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

Search: