3 ms·
This suggests that the FSF should create a GPL-licensed fork a Clang/LLVM. Such a fork could continue to receive all upstream improvements (since they're under
by antientropic 12y ago
This suggests that the FSF should create a GPL-licensed fork a Clang/LLVM. Such a fork could continue to receive all upstream improvements (since they're under a more liberal license), but not the other way around - the upstream project would not be able to use patches licensed under the GPL. Thus (in theory) it could end up being strictly superior to the original.
- hga 12y agoDidn't we go all over this when a hostile GPL re-licensing of a (painfully) reverse engineered OpenBSD driver was attempted? I'm not sure what you could do, that would also be attractive for people to use and contribute to, that would add enough GPL content to make such a thing fly even in theory. Maybe add a bunch of the GCC backends to LLVM? That's where it's most conspicuously behind GCC. There's also the precedent of GCC derived pre-Clang front ends, although I don't know how many of the non-C and C++ GCC front ends are seriously important (there's Ada, but that's got its own complexities).
- phkahler 12y ago>> This suggests that the FSF should create a GPL-licensed fork a Clang/LLVM. To do that you need developer support for the fork, so it won't happen now. It won't happen until enough people are sufficiently upset with the current development path, and if/when that happens it will probably not be due to the license.
- maxlybbert 12y agoThis is a common FSF tactic. It doesn't always end well (both GNU TLS, and GNU Mach come to mind). Not necessarily because they do bad things, but because they aren't able to get enough people using the software to make a significant improvement.