4 ms·

GCC has resisted modularity for a while because of concerns about enabling proprietary plugins; an unfortunate case of letting ideology come before technical ex

GCC has resisted modularity for a while because of concerns about enabling proprietary plugins; an unfortunate case of letting ideology come before technical excellence. This left a big unmet need and put LLVM in a stronger position to displace GCC purely on technical merit, by offering this capability that GCC didn't want to offer. http://lwn.net/Articles/301135/ http://lwn.net/Articles/301135/

ChuckMcM 15y ago
Reading that article from lwn.net is amazing. The irony of the gcc community users screwing over their customers in order to preserve their ideology, and its parallel in the 'commercial' software business is really amazing. Seriously. "We won't make plug-ins because that would open the door to making money on GCC" vs "We require a key disk to prevent folks from copying our software and using it for free."
- ajross 15y ago
  This is backwards. GCC and the GNU project as a whole exist because proprietary software was "screwing over its customers" in ways rms and the other early FSF people couldn't accept. The "ideology" of free software is (and always has been) the primary motivation, not the "customer" or "technical excellence". You can flame over that if you like (but please don't: just google the older flame wars from the 90's, this is depressingly well-travelled ground), but don't get confused over the motivations of the actors. The FSF has been nothing if not crystal clear about their priorities.
  - ChuckMcM 15y ago
    Not backwards, I think you got it. I lived through the flame wars in the 90s and really resonate with the message "Give us the damn source so we can change it to do what we want!" The irony is that if folks are trying to check in changes into the GCC tree that allow for plug-in modules because that is what they want, and the community is denying those commits because they fear having a plug-in architecture would enable other people to do bad things. Well that is ironic that such changes would be denied based on a potential transgression for some of the users. When I read the argument it sounded like what folks had been arguing on the other side back in the 90's, hence the irony.
- gillianseed 15y ago
  'Screwing over their customers'? Who are these 'customers'? If you are talking about end users then I fail to see how they are to be served by enhancements being kept in proprietary plugins (which are the historical reasons behind the objection against plugins, which in turn can be illustrated by the attempts of Steve Jobs who while at NeXT tried to circumvent the GPL to have it as a backend for his proprietary ObjC frontend). The whole point of GCC is to have a complete compiler toolchain where all the enhancements are being made available to _all_ end users. Catering for companies who wants a free strong frontend/backend on which to develop their proprietary extensions is obviously NOT what FSF is interested in and I personally agree with their 'ideology' in this case as the last thing I want to see is a situation where developers keep their enhancements proprietary (likely due to the wishes of their companies who see no gain in releasing those enhancements and instead wants to keep those enhancements as a competitive edge). Also I like how GCC enforces patent protection grants to be given by code contributors, something which LLVM does not and I fear is something which could open a big can of worms later down the road. Off course, scoffing at the 'ideology' which lead to the creation of the toolchain that is fueling pretty much the entire open source ecosystem not to mention lots of proprietary projects aswell makes you look pretty stupid in my book. Also GPL is obviously a licence through which numerous companies find it agreeable to cooperatively develop code, hence the success of Linux and GCC.
  - ChuckMcM 15y ago
    Ok, so the point is subtle and perhaps not easily communicated. This example is good though. "The whole point of GCC is to have a complete compiler toolchain where all the enhancements are being made available to _all_ end users." ... "the last thing I want to see is a situation where developers keep their enhancements proprietary." I believe you have correctly expressed a consensus opinion of why it would be 'bad' to allow proprietary plugins. And your claim posits a reason: "(likely due to the wishes of their companies who see no gain in releasing those enhancements and instead wants to keep those enhancements as a competitive edge)." Which is also a common reason given. However what if there was a different reason? What if there is some capability that could be created with a plug-in that is pretty specialized, further that plug-in would require specialized domain knowledge and would only be of use to a small number of GCC users. Traditionally the way the market has created such things is that a person invests their time to create the capability, and they charge a fraction of what it cost them to others to use the capability. The compute the fraction to offset the cost of developing it, and the community benefits by getting access to this capability for a fraction of what it would cost to develop in house, and the developer benefits by having the cost of their efforts covered by the community. In a GPL world where the work would be considered derivative, you remove the opportunity for people to charge for their work, and thus you remove the economic motivation for getting something built. This damages the community as a whole with a somewhat 'invisible' "didn't go there" sort of damage (you only miss something if you had it and then you don't, not if you never had it). It is an unfortunate byproduct of GPL like licenses that they poison[1] the market for those specialized tools. I completely understand the motivation behind the FSF and GCC communities for wanting to keep GCC available for all. But you have to also note that people who sell software make very much the same arguments in defense of copy protection. They (the software producers) argue that they want everyone to have the same experience and they can't control that experience if people are out there making bootleg copies and changes they don't know about. So they deny something their customers want "software unburdened by loathsome copy protection" to preserve their stated goal of giving everyone the same experience with their software. So if the FSF and GCC communities are denying something their customers want "modularized GCC tools for easy customization through plug-ins" in order to preserve their stated goal of giving everyone the same experience with their software, well it strikes me as ironic. [1] Sorry for inflammatory way that sounds, my thesaurus is coming up blank on terms that mean 'something which kills an existing organism and keeps it dead'. Using 'nuke' seemed worse.
- _delirium 15y ago
  I don't think they were worried about people making money on GCC (you can sell various services built around it, even proprietary IDEs that call out to it, etc.). They were more worried that it would open the door to GCC becoming no longer all-free: users might find that, like with the Linux kernel before the "no unfree firmware" crusade, they de-facto had to use proprietary modules to get various things working, despite the core being free. The hope of the GCC devs was that by making it a choice of "open-source it and link, or don't come at all", they would push at least a few would've-been-proprietary-modules into becoming free software in order to be able to work with GCC. Whether it worked or not, I'm not sure. The copyleft strategy's success is a fairly complex game-theory problem that's pretty specific to the costs/benefits/alternatives of each party in each situation. The whole point is to try to force a sort of quid pro quo: you can use my free software as long as you open up yours too. As with any quid-pro-quo proposal, whether the other person accepts depends on a lot of factors. edit: digging for some examples, I think the D front-end may have been open-sourced as a result of that policy, to give D a second compilation route (besides the official Digital Mars D compiler).
  - saurik 15y ago
    (NeXT's Objective-C front-end is also a commonly cited example.)

ChuckMcM 15y ago

Reading that article from lwn.net is amazing. The irony of the gcc community users screwing over their customers in order to preserve their ideology, and its parallel in the 'commercial' software business is really amazing. Seriously. "We won't make plug-ins because that would open the door to making money on GCC" vs "We require a key disk to prevent folks from copying our software and using it for free."

ajross 15y ago
This is backwards. GCC and the GNU project as a whole exist because proprietary software was "screwing over its customers" in ways rms and the other early FSF people couldn't accept. The "ideology" of free software is (and always has been) the primary motivation, not the "customer" or "technical excellence". You can flame over that if you like (but please don't: just google the older flame wars from the 90's, this is depressingly well-travelled ground), but don't get confused over the motivations of the actors. The FSF has been nothing if not crystal clear about their priorities.
- ChuckMcM 15y ago
  Not backwards, I think you got it. I lived through the flame wars in the 90s and really resonate with the message "Give us the damn source so we can change it to do what we want!" The irony is that if folks are trying to check in changes into the GCC tree that allow for plug-in modules because that is what they want, and the community is denying those commits because they fear having a plug-in architecture would enable other people to do bad things. Well that is ironic that such changes would be denied based on a potential transgression for some of the users. When I read the argument it sounded like what folks had been arguing on the other side back in the 90's, hence the irony.
gillianseed 15y ago
'Screwing over their customers'? Who are these 'customers'? If you are talking about end users then I fail to see how they are to be served by enhancements being kept in proprietary plugins (which are the historical reasons behind the objection against plugins, which in turn can be illustrated by the attempts of Steve Jobs who while at NeXT tried to circumvent the GPL to have it as a backend for his proprietary ObjC frontend). The whole point of GCC is to have a complete compiler toolchain where all the enhancements are being made available to _all_ end users. Catering for companies who wants a free strong frontend/backend on which to develop their proprietary extensions is obviously NOT what FSF is interested in and I personally agree with their 'ideology' in this case as the last thing I want to see is a situation where developers keep their enhancements proprietary (likely due to the wishes of their companies who see no gain in releasing those enhancements and instead wants to keep those enhancements as a competitive edge). Also I like how GCC enforces patent protection grants to be given by code contributors, something which LLVM does not and I fear is something which could open a big can of worms later down the road. Off course, scoffing at the 'ideology' which lead to the creation of the toolchain that is fueling pretty much the entire open source ecosystem not to mention lots of proprietary projects aswell makes you look pretty stupid in my book. Also GPL is obviously a licence through which numerous companies find it agreeable to cooperatively develop code, hence the success of Linux and GCC.
- ChuckMcM 15y ago
  Ok, so the point is subtle and perhaps not easily communicated. This example is good though. "The whole point of GCC is to have a complete compiler toolchain where all the enhancements are being made available to _all_ end users." ... "the last thing I want to see is a situation where developers keep their enhancements proprietary." I believe you have correctly expressed a consensus opinion of why it would be 'bad' to allow proprietary plugins. And your claim posits a reason: "(likely due to the wishes of their companies who see no gain in releasing those enhancements and instead wants to keep those enhancements as a competitive edge)." Which is also a common reason given. However what if there was a different reason? What if there is some capability that could be created with a plug-in that is pretty specialized, further that plug-in would require specialized domain knowledge and would only be of use to a small number of GCC users. Traditionally the way the market has created such things is that a person invests their time to create the capability, and they charge a fraction of what it cost them to others to use the capability. The compute the fraction to offset the cost of developing it, and the community benefits by getting access to this capability for a fraction of what it would cost to develop in house, and the developer benefits by having the cost of their efforts covered by the community. In a GPL world where the work would be considered derivative, you remove the opportunity for people to charge for their work, and thus you remove the economic motivation for getting something built. This damages the community as a whole with a somewhat 'invisible' "didn't go there" sort of damage (you only miss something if you had it and then you don't, not if you never had it). It is an unfortunate byproduct of GPL like licenses that they poison[1] the market for those specialized tools. I completely understand the motivation behind the FSF and GCC communities for wanting to keep GCC available for all. But you have to also note that people who sell software make very much the same arguments in defense of copy protection. They (the software producers) argue that they want everyone to have the same experience and they can't control that experience if people are out there making bootleg copies and changes they don't know about. So they deny something their customers want "software unburdened by loathsome copy protection" to preserve their stated goal of giving everyone the same experience with their software. So if the FSF and GCC communities are denying something their customers want "modularized GCC tools for easy customization through plug-ins" in order to preserve their stated goal of giving everyone the same experience with their software, well it strikes me as ironic. [1] Sorry for inflammatory way that sounds, my thesaurus is coming up blank on terms that mean 'something which kills an existing organism and keeps it dead'. Using 'nuke' seemed worse.
_delirium 15y ago
I don't think they were worried about people making money on GCC (you can sell various services built around it, even proprietary IDEs that call out to it, etc.). They were more worried that it would open the door to GCC becoming no longer all-free: users might find that, like with the Linux kernel before the "no unfree firmware" crusade, they de-facto had to use proprietary modules to get various things working, despite the core being free. The hope of the GCC devs was that by making it a choice of "open-source it and link, or don't come at all", they would push at least a few would've-been-proprietary-modules into becoming free software in order to be able to work with GCC. Whether it worked or not, I'm not sure. The copyleft strategy's success is a fairly complex game-theory problem that's pretty specific to the costs/benefits/alternatives of each party in each situation. The whole point is to try to force a sort of quid pro quo: you can use my free software as long as you open up yours too. As with any quid-pro-quo proposal, whether the other person accepts depends on a lot of factors. edit: digging for some examples, I think the D front-end may have been open-sourced as a result of that policy, to give D a second compilation route (besides the official Digital Mars D compiler).
- saurik 15y ago
  (NeXT's Objective-C front-end is also a commonly cited example.)