Beyond Open Source
Rather, this is an essay about what, as a practical matter, open source can and cannot do. The study of where the rubber meets the road, effectively. There are features and patches and entire open source projects that cannot exist, structurally, under our current system. The ingredients aren’t right. The incentives aren’t right. Let’s poke at that.
[…]
The Type 3 “institutional investment” is obviously strategic; you invest in an open source project for strategic reasons. It’s hard to imagine now, but in Apple’s case, they were down for the count; they were a major OS vendor without their own web browser, with no ability to influence the future of the web. 15 years later they now control the most important browser technology in the world. By uniting all the second-place players onto one team, they were able to defeat the leading player. But an open web was always a collateral benefit of their strategy.
[…]
Docker, however, is wise to the plan. Since they control the underlying open source project, they think they are better positioned, from a brand and strategy perspective, to grow into CoreOS’s space, than CoreOS is positioned to keep it. The result is that issues with hundreds of comments remain open for years because they’re not strategically compatible with Docker’s vision of being a 1-click end-to-end VM management system. Docker doesn’t want to be just a VM killer. They want to be a VM killer plus swallow up a lot of the market for value-added platforms and services.
[…]
The battle over stuff as mundane as what command-line arguments are accepted for the software are part of some larger war that enterprises are waging using OSS contributions as a proxy.
Michael Larabel (via Slashdot):
Richard Stallman has come out against support for basic LLVM debugger (LLDB) support within Emacs’ Gud.el as he equates it to an attack on GNU packages.
Chris Lattner (in 2005):
The patch I’m working on is GPL licensed and copyright will be assigned to the FSF under the standard Apple copyright assignment. Initially, I intend to link the LLVM libraries in from the existing LLVM distribution, mainly to simplify my work. This code is licensed under a BSD-like license [8], and LLVM itself will not initially be assigned to the FSF. If people are seriously in favor of LLVM being a long-term part of GCC, I personally believe that the LLVM community would agree to assign the copyright of LLVM itself to the FSF and we can work through these details.
Why would people be interested in a fork whose primary purpose would be to make the compiler less modular and stop it from interoperating with modules they might want to write?
Because non-modularity is exactly what GCC is supposed to provide in order not to create module boundaries where the reach of the GPL ends.
[…]
[Lattner] did all of the integration work and offered completed patches. These patches were rejected. Partly because bootstrapping from C++ was undesired (GCC now bootstraps from C++), partly because the modularity was undesired in GCC.
Modularity is the main point of LLVM. Chopping it away in order to slap on a GPL that actually stings is pretty much the same as ritual suicide.
I am stunned to see that we had this offer. Now, based on hindsight, I wish we had accepted it.
The license of LLVM is free. We can use that code if we want to.
The problem that LLVM causes for the GNU Project is that, when used, it replaces GCC with a non-copylefted program.
It is good for the parts of GCC to be modular. And it is fine for these modules to be able to link with other programs, too.
What I am worried about is for these modules to be used with nonfree programs by NOT linking them together. That that would lead to proprietary use which ultimately is bad for users’ freedom.
I prioritize users’ freedom above technical merit, and that’s why I wrote GCC. If not for that, I wouldn’t have had to write a C compiler at all -- I could have used one of the proprietary ones.
[GCC] has aided users’ freedom tremendously by leading many companies to release free compilers for their hardware. LLVM has cut off our ability to do that, and that will be a big loss to users’ freedom.
Whatever advantages LLVM may have, they don’t compensate for this big harm.
It’s very simple. Anything that relates to LLVM is a strategic issue, so maintainers should talk with me privately about what to do.
Installing that change would be favorable for Emacs, probably just a little. It would probably be bad for GDB, but I have no idea how much. […] We should do what is best for the GNU system’s goal of giving the users freedom. This means considering what is good for Emacs and what is good for GDB, to make a decision. Then the whole GNU Project should do what is best. That is the responsibility of each GNU package maintainer.
