3 ms·

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'r

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.

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.