'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.
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.
You're wrong that the GPL prohibits one from selling software as software. It doesn't. It does make it harder, because anyone can come in and buy one copy to distribute to everyone else, but this happens very often in the non-open-source world too. Maybe you've heard of pirates?
The only difference is legal ability to sue, but then again when your unwanted re-distributors/pirates are the masses whose real-world identities are hard to discover, this difference doesn't mean that much. You can also gain some (though not all) of the same legal rights to sue unwanted re-distributors by trademarking your application, which forces any re-distributors to have to redistribute under a different name (CentOS instead of RedHat) which puts them at a marketing disadvantage.
Is your example of developing a niche feature for a niche domain really the traditional way? I guess so, but since the GPL has been around there have been numerous examples of what-would-have-been-proprietary features still being developed, released, and open sourced. e.g. if you own all the copyright to a GPL program, some niche domain representative can come along and you can sell them a non-GPL license to develop their addon for which they can then resell. As another e.g., look at all the companies who have contributed to the Linux Kernel. The company wants a particular feature because they can use it to make money for some other reason, so they pay developers to write the code which then gets GPL'd. The company still makes money from the code, the developers make money by writing the code, and the users directly, obviously benefit from the code being there as opposed to the company having estimated indirect guesses at how much value they could capture by selling the code for what the market could bear.
Edit: I do agree with you about the irony, though.
>It is an unfortunate byproduct of GPL like licenses that they poison[1] the market for those specialized tools.
Obviously GPL 'poisons' the market for derivative _proprietary_ tools. The whole idea behind GPL is that the end user should have the right to get the source code. If the only way to charge for your work is through artifical scarcity by hiding the source code then no, you can't do that as a derivative of someone else's GPL licenced code.
If we are talking about your own code, then obviously you can licence it both as GPL and offer it through other agreements aswell. Take x264 for instance, the devs are making good money by offering it through a proprietary licence for those who doesn't want to open their source while making it freely available for open source projects under GPL.
And your copy protection analogy is hypocritical. GPL actually prevents the artificial scarcity employed by copy protection, contrary to the market example you described where someone won't create a GCC plugin because they can't keep it proprietary and thus employ artificial scarcity.
There's no point in arguing against GPL not working with proprietary code given that GPL was created to prevent working with proprietary code. That doesn't mean that you aren't allowed to make money with GPL licenced code, only that you can't do that through A) limiting the number of copies the recipient can make of the software, B) denying the recipient the source code should he/she request it.
Obviously this prevents the most traditional way of making money from software which is through artificial scarcity (except the case of when it's truly _your_ code, then you can offer other agreements apart from GPL as in the case with x264), however other ways of making money off open source has emerged like that of Red Hat.
edit: I do agree though that disallowing plugins is ultimately not the way to go since there's alot of possibilities that they offer (and no, I'm not talking about proprietary plugins of which I couldn't care less) and I'm glad that GCC now has a plugin-architecture.
Comments
'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.
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.
You're wrong that the GPL prohibits one from selling software as software. It doesn't. It does make it harder, because anyone can come in and buy one copy to distribute to everyone else, but this happens very often in the non-open-source world too. Maybe you've heard of pirates?
The only difference is legal ability to sue, but then again when your unwanted re-distributors/pirates are the masses whose real-world identities are hard to discover, this difference doesn't mean that much. You can also gain some (though not all) of the same legal rights to sue unwanted re-distributors by trademarking your application, which forces any re-distributors to have to redistribute under a different name (CentOS instead of RedHat) which puts them at a marketing disadvantage.
Is your example of developing a niche feature for a niche domain really the traditional way? I guess so, but since the GPL has been around there have been numerous examples of what-would-have-been-proprietary features still being developed, released, and open sourced. e.g. if you own all the copyright to a GPL program, some niche domain representative can come along and you can sell them a non-GPL license to develop their addon for which they can then resell. As another e.g., look at all the companies who have contributed to the Linux Kernel. The company wants a particular feature because they can use it to make money for some other reason, so they pay developers to write the code which then gets GPL'd. The company still makes money from the code, the developers make money by writing the code, and the users directly, obviously benefit from the code being there as opposed to the company having estimated indirect guesses at how much value they could capture by selling the code for what the market could bear.
Edit: I do agree with you about the irony, though.
>It is an unfortunate byproduct of GPL like licenses that they poison[1] the market for those specialized tools.
Obviously GPL 'poisons' the market for derivative _proprietary_ tools. The whole idea behind GPL is that the end user should have the right to get the source code. If the only way to charge for your work is through artifical scarcity by hiding the source code then no, you can't do that as a derivative of someone else's GPL licenced code.
If we are talking about your own code, then obviously you can licence it both as GPL and offer it through other agreements aswell. Take x264 for instance, the devs are making good money by offering it through a proprietary licence for those who doesn't want to open their source while making it freely available for open source projects under GPL.
And your copy protection analogy is hypocritical. GPL actually prevents the artificial scarcity employed by copy protection, contrary to the market example you described where someone won't create a GCC plugin because they can't keep it proprietary and thus employ artificial scarcity.
There's no point in arguing against GPL not working with proprietary code given that GPL was created to prevent working with proprietary code. That doesn't mean that you aren't allowed to make money with GPL licenced code, only that you can't do that through A) limiting the number of copies the recipient can make of the software, B) denying the recipient the source code should he/she request it.
Obviously this prevents the most traditional way of making money from software which is through artificial scarcity (except the case of when it's truly _your_ code, then you can offer other agreements apart from GPL as in the case with x264), however other ways of making money off open source has emerged like that of Red Hat.
edit: I do agree though that disallowing plugins is ultimately not the way to go since there's alot of possibilities that they offer (and no, I'm not talking about proprietary plugins of which I couldn't care less) and I'm glad that GCC now has a plugin-architecture.