4 ms·

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

by 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
  Right, I am giving to separate reasons. The thing is, the second is a real benefit, but it's hard to convince my boss of it, because he winds up being afraid that we'll be releasing technology that our competitors could use. The first is an unquestionable reason; it's a lot easier to get him to agree if it's a legal requirement. So even though the real reason why it benefits the company is the second, the first provides the leverage to tip the scales in favor of releasing the code. If the code were BSD licensed, we would likely never ship it upstream, because of his fear that our competitors will take advantage of it. And there's an additional, third factor in play: if you release it under the GPL, you don't have to worry about your competitors making a proprietary fork of it, thus taking advantage of your work while keeping their own secret. So that further tips the scales. Sure, with GPL you may be required to release your modifications, but at least you know that by doing so, you won't be giving your competitors a major advantage if they then build something proprietary on it. And finally, in many cases with GPLed licenses, you can keep your own code proprietary. Just write a separate application, rather than linking it with the GPLed components. That's how most of what my company does works; we sell a system based on Linux and many other GPLed components, but we tune it to the hardware we sell, and have our own proprietary management tools on top of it that make it integrate well into our market. This is why the LGPL or more permissive licenses are generally preferred for libraries (with very few exceptions, such as readline), which are designed to be reused regardless of the license of the application, while the GPL works so well for components like the kernel, system services, and so on.
pbsdp 13y ago
It's not really clear that Linux's market position is thanks to the GPL, or because Linux was able to move ahead in the marketplace while BSDs were encumbered by the AT&T lawsuit at a most critical point in time, or some other facet of history.

by lambda 13y ago

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
Right, I am giving to separate reasons. The thing is, the second is a real benefit, but it's hard to convince my boss of it, because he winds up being afraid that we'll be releasing technology that our competitors could use. The first is an unquestionable reason; it's a lot easier to get him to agree if it's a legal requirement. So even though the real reason why it benefits the company is the second, the first provides the leverage to tip the scales in favor of releasing the code. If the code were BSD licensed, we would likely never ship it upstream, because of his fear that our competitors will take advantage of it. And there's an additional, third factor in play: if you release it under the GPL, you don't have to worry about your competitors making a proprietary fork of it, thus taking advantage of your work while keeping their own secret. So that further tips the scales. Sure, with GPL you may be required to release your modifications, but at least you know that by doing so, you won't be giving your competitors a major advantage if they then build something proprietary on it. And finally, in many cases with GPLed licenses, you can keep your own code proprietary. Just write a separate application, rather than linking it with the GPLed components. That's how most of what my company does works; we sell a system based on Linux and many other GPLed components, but we tune it to the hardware we sell, and have our own proprietary management tools on top of it that make it integrate well into our market. This is why the LGPL or more permissive licenses are generally preferred for libraries (with very few exceptions, such as readline), which are designed to be reused regardless of the license of the application, while the GPL works so well for components like the kernel, system services, and so on.

pbsdp 13y ago

It's not really clear that Linux's market position is thanks to the GPL, or because Linux was able to move ahead in the marketplace while BSDs were encumbered by the AT&T lawsuit at a most critical point in time, or some other facet of history.