4 ms·

What's interesting is that while Juniper's software is proprietary, they've still contributed patches and funded dedicated upstream development. This is somethi

by pbsdp 13y ago

What's interesting is that while Juniper's software is proprietary, they've still contributed patches and funded dedicated upstream development. This is something enabled by not being required to share more than what they're comfortable with sharing.

cperciva 13y ago
Not just Juniper, either. Most large users of FreeBSD contribute patches back -- the great success of BSD as a license is the recognition that if you use open source, it makes sense to contribute back any non-proprietary improvements, without needing any "encouragement" from the license.
- runeks 13y ago
  > Most large users of FreeBSD contribute patches back -- the great success of BSD as a license is the recognition that if you use open source, it makes sense to contribute back any non-proprietary improvements, without needing any "encouragement" from the license. I've had the same thoughts recently. At some point it must simply become unmanageable to maintain a fork, at least if you want to enjoy updates to master. But I suspect Sony might not be interested in future updates to FreeBSD, since they will probably prefer working on a static platform, and since the hardware will remain the same as well.
  - cperciva 13y ago
    Two answers come to mind about that. First, according to wikipedia, the PS4 has been in development since 2008 -- long before FreeBSD 9.0 was released -- so the "enjoy updates to master" argument would have applied during the development cycle even if not after the product is released. Second, even if they're dealing with a mostly static platform, I'm sure there would be some changes -- in hardware, replacing components with newer/cheaper ones, and in software, patching security vulnerabilities -- so there would still be some incentive to make merging easy (although not as much as if they were continuing development, to be sure). Of course, for all I know, they might be planning a PlayStation 5 based on FreeBSD 11.0 to be launched in 2017, in which case they would have very good reasons to merge as much non-proprietary work upstream.
- 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.
lambda 13y ago
Sure, but there are lots more companies that have contributed patches and funded dedicated upstream development for the Linux kernel, in part because they knew that their competitors couldn't just take it and release a proprietary product built on top of it without revealing their changes. As a developer who works with a boss who has a somewhat equivocal position on open source software, I'm glad for the GPL requirements on the software that we modify and ship. He likes to use open source software, and in theory likes to pay lip-service to contributing change upstream, but when push comes to shove he's always worried that we'll let competitors get a jump on us. With GPL licensed software, I can always make the argument that we have to release the source code anyhow, so we might as well push the changes upstream and avoid the pain of maintaining a fork. With other software, well, it's always somewhere far down on the priority stack to actually release the code, and so we wind up maintaining patch stacks for years and shipping with major security vulnerabilities because we're afraid to update as it will take a lot of work to port our changes forward.
- profquail 13y ago
  You're giving two entirely separate reasons for why it makes sense for you to contribute patches upstream: * You're modifying GPL'd software, which means you're required to release the source code including your modifications. * Pushing the patches upstream reduces the costs to your business in the long-term, because it avoids the need to maintain separate branches for your own changes. IMO, the second reason is a much bigger win for businesses, and exactly the reason permissive licenses (BSD, Apache 2.0) are getting more and more popular. Permissive licenses allow businesses to collaborate on code which is going to be common within and across industries (reducing development costs and time-to-market) while allowing them to keep some other parts of their code private.
  - the_gipsy 13y ago
    I guess that he works on something SaaS, web probably, where you aren't distributing the software, so there you are not obligued to release your modification.
  - lambda 13y ago
fabjan 13y ago
Companies using GPLed software also don't have to share more than they're comfortable with sharing, or they would not be doing it. They are just comfortable with a bit more than other companies.

by pbsdp 13y ago

cperciva 13y ago

Not just Juniper, either. Most large users of FreeBSD contribute patches back -- the great success of BSD as a license is the recognition that if you use open source, it makes sense to contribute back any non-proprietary improvements, without needing any "encouragement" from the license.

runeks 13y ago
> Most large users of FreeBSD contribute patches back -- the great success of BSD as a license is the recognition that if you use open source, it makes sense to contribute back any non-proprietary improvements, without needing any "encouragement" from the license. I've had the same thoughts recently. At some point it must simply become unmanageable to maintain a fork, at least if you want to enjoy updates to master. But I suspect Sony might not be interested in future updates to FreeBSD, since they will probably prefer working on a static platform, and since the hardware will remain the same as well.
- cperciva 13y ago
  Two answers come to mind about that. First, according to wikipedia, the PS4 has been in development since 2008 -- long before FreeBSD 9.0 was released -- so the "enjoy updates to master" argument would have applied during the development cycle even if not after the product is released. Second, even if they're dealing with a mostly static platform, I'm sure there would be some changes -- in hardware, replacing components with newer/cheaper ones, and in software, patching security vulnerabilities -- so there would still be some incentive to make merging easy (although not as much as if they were continuing development, to be sure). Of course, for all I know, they might be planning a PlayStation 5 based on FreeBSD 11.0 to be launched in 2017, in which case they would have very good reasons to merge as much non-proprietary work upstream.
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.

lambda 13y ago

Sure, but there are lots more companies that have contributed patches and funded dedicated upstream development for the Linux kernel, in part because they knew that their competitors couldn't just take it and release a proprietary product built on top of it without revealing their changes. As a developer who works with a boss who has a somewhat equivocal position on open source software, I'm glad for the GPL requirements on the software that we modify and ship. He likes to use open source software, and in theory likes to pay lip-service to contributing change upstream, but when push comes to shove he's always worried that we'll let competitors get a jump on us. With GPL licensed software, I can always make the argument that we have to release the source code anyhow, so we might as well push the changes upstream and avoid the pain of maintaining a fork. With other software, well, it's always somewhere far down on the priority stack to actually release the code, and so we wind up maintaining patch stacks for years and shipping with major security vulnerabilities because we're afraid to update as it will take a lot of work to port our changes forward.

profquail 13y ago
You're giving two entirely separate reasons for why it makes sense for you to contribute patches upstream: * You're modifying GPL'd software, which means you're required to release the source code including your modifications. * Pushing the patches upstream reduces the costs to your business in the long-term, because it avoids the need to maintain separate branches for your own changes. IMO, the second reason is a much bigger win for businesses, and exactly the reason permissive licenses (BSD, Apache 2.0) are getting more and more popular. Permissive licenses allow businesses to collaborate on code which is going to be common within and across industries (reducing development costs and time-to-market) while allowing them to keep some other parts of their code private.
- the_gipsy 13y ago
  I guess that he works on something SaaS, web probably, where you aren't distributing the software, so there you are not obligued to release your modification.
- lambda 13y ago

fabjan 13y ago

Companies using GPLed software also don't have to share more than they're comfortable with sharing, or they would not be doing it. They are just comfortable with a bit more than other companies.