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 th

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.