3 ms·

The even greater success of GPL as a license is that it not only makes sense to contribue back, but you have to. This is much more efficient for good contributi

by devcpp 13y ago

The even greater success of GPL as a license is that it not only makes sense to contribue back, but you have to. This is much more efficient for good contributions flowing from everywhere. The fact that good non-GPL alternatives like BSD exist kind of destroys it though.

testbro 13y ago
I'd wager that there are a lot of in-house re-implementations of GPL software because the license isn't permissive enough. I think the fact that good non-GPL alternatives exist supports my hypothesis; given the choice between GPL and reinvent the wheel, it's feasible for someone to take the latter path.
epistasis 13y ago
At my company we use and contribute back to projects with BSD-like licenses. When using GPL projects we treat them as if they were proprietary binary distributions, never looking at, changing, or contributing back code, and will use an alternative project with a BSD-like license if it looks like the code is getting to be a key part if a system that we may need to enhance. We would use GPL if we wanted to release code but didn't want it to be tooooo useful to our competitors. Edit: I forgot my key point, which was that GPL is less useful in "most" cases (IMHO, YMMV, etc), but is successful because of good "marketing" and it being the most talked about license with the most vocal and ardent supporters.
- lambda 13y ago
  > When using GPL projects we treat them as if they were proprietary binary distributions, never looking at, changing, or contributing back code Why? If you are OK with contributing back to the upstream project, why avoid doing so if the license is GPL? > We would use GPL if we wanted to release code but didn't want it to be tooooo useful to our competitors. Exactly. With the GPL, even once you do release your changes, you know that your competitors can't create a proprietary fork that builds on your work without benefiting you. It gives you a quid pro quo, while there's always worry when contributing to a BSD licensed project that a competitor may make a proprietary fork and you'll be left either continuing to push changes that benefit them without getting anything back, or making your own proprietary fork and now defeating the whole purpose of sharing changes. Basically, permissive licenses lose at the prisoner's dilemma; GPL acts as a way to force cooperation, allowing your both to win. Remember, most of the time development is not a zero-sum game. You can gain market share by taking it from a competitor, or by increasing the size of the market. Working together on shared components helps to reduce the cost to increase the size of the market. Coming out with proprietary new features that your competitor doesn't have may increase the size of the market, or it may just steal marketshare from your competitor. And if it steals marketshare from your competitor, they have an incentive to retaliate in kind, developing proprietary features that they don't share and which steals customers from you. Here's an example. To make the numbers simple, I'm going to assume big enterprise software, that you sell for a lot of money to a few customers. Let's say that you have two companies, Colorful Chapeau and Suzie, selling an open source system called Van Pelt (sufficiently customized, including support, perhaps with certified hardware, etc. to turn it into an actual business). For the sake of argument, to make the numbers simple, let's say it's enterprise software, sold at a high price to small number of customers. Each of them has 100 customers, who each pay $100,000 a year for the software and support, giving them a $10M a year budget (yes, I'm ignoring actual profits and the actual cost of support an whatnot; this is a simplified example). Now, there are two major new features, A and B, that are the next big things in the industry. There are 50 more customers that would buy the systems if either A or B were added; plus, 25 customers would switch from one company to the other if they were able to add A or B and the other company isn't. Finally, there are an additional 50 new customers who would buy a system which had A and B (on top of the ones who need just A or B). So, if Colorful Chapeau releases A, and in the kindness of their own heart, decides to push the changes upstream despite Van Pelt being BSD licensed, Suzie can spend all of their development budget on B, and release a product that incorporates A and B. 25 customers defect from Colorful Chapeau to Suzie because Suzie offers B and Chapeau doesn't. No customers defect from Suzie to Chapeau, as Suzie offers both A and B. There are 50 new customers which needed A, but both companies offer it, so they each get 25 new customers due to that. Suzie gets 25 new customers who wanted B. Suzie gets 50 new customers which needed A and B. So Chapeau is left in the same place; with 100 customers, after all of that development effort. Suzie is now up to 225 customers; with some stolen from Chapeau, and some new. But of course, due to that expected outcome, Chapeau wouldn't do that; their stockholders would revolt. Instead, they would develop A as a proprietary feature. Suzie would develop B as a proprietary feature. Chapeau would get 50 new users, plus 25 defections, and minus 25 in the other direction, and Suzie the same, leaving them at 150 customers each. The last 50, who are holding out for a system that has A and B, are left to wait another year while Suzie and Chapeau spend duplicate effort copying each others features. The two companies are each left with less revenue, and the users lose out as no one offers A and B for another year. Now, what happens if Van Pelt were released under the GPL instead of the BSD license? Well, releasing a proprietary feature is no longer an option. Colorful Chapeau can develop A, and Suzie can develop B, and they can both offer A and B. They will each split the 50 new customers who need A, 50 new customers who need B, and 50 new customers who need both, and will have no defections. They each now have 175 customers, and all customers can now take advantage of A and B. Now, of course the real world is more complex than this; there can be multiple actors, benefits will not be so symmetric, full on leeches can sell the same bundled support and services without developing any new features of their own, people can sell bundles of GPLed and proprietary software as long as they don't link, the GPL does allow you to develop in secret and then do a big release to get a jump on your competitors, forks can interfere with actually sharing A and B in the same codebase, etc. But you can see how there is substantial economic value to the GPL. In development, just like the prisoner's dilemma, given a fixed strategy for your competitor, defecting is better than cooperating. But both players cooperating is better than both players defecting. So if you have an independent competitor that you can't trust, and permissively licensed software, you will likely default to defecting (not sharing code). I suspect the cases in which permissively licensed software does the best are the ones in which the features it offers aren't a significant competitive advantage, but instead the software is more of a cost-center (something you need, but it isn't terribly important what you pick, so you might as well pick the cheapest). There the economic benefits of cooperation become more important, while you don't have as much of the reason to be afraid of sharing your code, as it won't lose you any customers or allow a competitor to gain customers that they otherwise couldn't have.

by devcpp 13y ago

testbro 13y ago

I'd wager that there are a lot of in-house re-implementations of GPL software because the license isn't permissive enough. I think the fact that good non-GPL alternatives exist supports my hypothesis; given the choice between GPL and reinvent the wheel, it's feasible for someone to take the latter path.

epistasis 13y ago

At my company we use and contribute back to projects with BSD-like licenses. When using GPL projects we treat them as if they were proprietary binary distributions, never looking at, changing, or contributing back code, and will use an alternative project with a BSD-like license if it looks like the code is getting to be a key part if a system that we may need to enhance. We would use GPL if we wanted to release code but didn't want it to be tooooo useful to our competitors. Edit: I forgot my key point, which was that GPL is less useful in "most" cases (IMHO, YMMV, etc), but is successful because of good "marketing" and it being the most talked about license with the most vocal and ardent supporters.

lambda 13y ago
> When using GPL projects we treat them as if they were proprietary binary distributions, never looking at, changing, or contributing back code Why? If you are OK with contributing back to the upstream project, why avoid doing so if the license is GPL? > We would use GPL if we wanted to release code but didn't want it to be tooooo useful to our competitors. Exactly. With the GPL, even once you do release your changes, you know that your competitors can't create a proprietary fork that builds on your work without benefiting you. It gives you a quid pro quo, while there's always worry when contributing to a BSD licensed project that a competitor may make a proprietary fork and you'll be left either continuing to push changes that benefit them without getting anything back, or making your own proprietary fork and now defeating the whole purpose of sharing changes. Basically, permissive licenses lose at the prisoner's dilemma; GPL acts as a way to force cooperation, allowing your both to win. Remember, most of the time development is not a zero-sum game. You can gain market share by taking it from a competitor, or by increasing the size of the market. Working together on shared components helps to reduce the cost to increase the size of the market. Coming out with proprietary new features that your competitor doesn't have may increase the size of the market, or it may just steal marketshare from your competitor. And if it steals marketshare from your competitor, they have an incentive to retaliate in kind, developing proprietary features that they don't share and which steals customers from you. Here's an example. To make the numbers simple, I'm going to assume big enterprise software, that you sell for a lot of money to a few customers. Let's say that you have two companies, Colorful Chapeau and Suzie, selling an open source system called Van Pelt (sufficiently customized, including support, perhaps with certified hardware, etc. to turn it into an actual business). For the sake of argument, to make the numbers simple, let's say it's enterprise software, sold at a high price to small number of customers. Each of them has 100 customers, who each pay $100,000 a year for the software and support, giving them a $10M a year budget (yes, I'm ignoring actual profits and the actual cost of support an whatnot; this is a simplified example). Now, there are two major new features, A and B, that are the next big things in the industry. There are 50 more customers that would buy the systems if either A or B were added; plus, 25 customers would switch from one company to the other if they were able to add A or B and the other company isn't. Finally, there are an additional 50 new customers who would buy a system which had A and B (on top of the ones who need just A or B). So, if Colorful Chapeau releases A, and in the kindness of their own heart, decides to push the changes upstream despite Van Pelt being BSD licensed, Suzie can spend all of their development budget on B, and release a product that incorporates A and B. 25 customers defect from Colorful Chapeau to Suzie because Suzie offers B and Chapeau doesn't. No customers defect from Suzie to Chapeau, as Suzie offers both A and B. There are 50 new customers which needed A, but both companies offer it, so they each get 25 new customers due to that. Suzie gets 25 new customers who wanted B. Suzie gets 50 new customers which needed A and B. So Chapeau is left in the same place; with 100 customers, after all of that development effort. Suzie is now up to 225 customers; with some stolen from Chapeau, and some new. But of course, due to that expected outcome, Chapeau wouldn't do that; their stockholders would revolt. Instead, they would develop A as a proprietary feature. Suzie would develop B as a proprietary feature. Chapeau would get 50 new users, plus 25 defections, and minus 25 in the other direction, and Suzie the same, leaving them at 150 customers each. The last 50, who are holding out for a system that has A and B, are left to wait another year while Suzie and Chapeau spend duplicate effort copying each others features. The two companies are each left with less revenue, and the users lose out as no one offers A and B for another year. Now, what happens if Van Pelt were released under the GPL instead of the BSD license? Well, releasing a proprietary feature is no longer an option. Colorful Chapeau can develop A, and Suzie can develop B, and they can both offer A and B. They will each split the 50 new customers who need A, 50 new customers who need B, and 50 new customers who need both, and will have no defections. They each now have 175 customers, and all customers can now take advantage of A and B. Now, of course the real world is more complex than this; there can be multiple actors, benefits will not be so symmetric, full on leeches can sell the same bundled support and services without developing any new features of their own, people can sell bundles of GPLed and proprietary software as long as they don't link, the GPL does allow you to develop in secret and then do a big release to get a jump on your competitors, forks can interfere with actually sharing A and B in the same codebase, etc. But you can see how there is substantial economic value to the GPL. In development, just like the prisoner's dilemma, given a fixed strategy for your competitor, defecting is better than cooperating. But both players cooperating is better than both players defecting. So if you have an independent competitor that you can't trust, and permissively licensed software, you will likely default to defecting (not sharing code). I suspect the cases in which permissively licensed software does the best are the ones in which the features it offers aren't a significant competitive advantage, but instead the software is more of a cost-center (something you need, but it isn't terribly important what you pick, so you might as well pick the cheapest). There the economic benefits of cooperation become more important, while you don't have as much of the reason to be afraid of sharing your code, as it won't lose you any customers or allow a competitor to gain customers that they otherwise couldn't have.