> going to sell an open source project under a different license
It's required where you want to sell a restrictively licensed (GPL, say) open source project under a commercial license. If it's licensed under something like the Apache license or BSD, you can do what you want with it. But then, so can everyone else, so you don't have the advantage you would with the dual license and require copyright assignment strategy.
The FSF uses the words lax and permissive to describe licenses which do not have the requirements of the GPL (http://www.gnu.org/licenses/license-list.html), and describe the GPL as a copyleft license. If you want to describe the GPL with a word that is not "copyleft", I guess you would use some word opposite to lax and permissive, like restrictive. So it would only be restrictive relative to the permissive licenses, but in that context, it is restrictive, which is not necessarily a bad thing. Though personally I prefer to describe it as "strict".
I didn't pass any judgment on it, I just said it's more restrictive than a BSD style license. I have opinions on the two licenses, and could probably write a fairly lengthly article on it: "it's complicated".
There are less things you can do with GPLed software than BSD software. Therefore, when comparing GPL and BSD, GPL is more restrictive. There is no need for the doublespeak of calling it anything else in a comparison.
Tell me, how does "robust" translate to "there are more restrictions on what you can do with this"?
BSDL software is usually far more restricted by the time it reaches end users' hands. I wouldn't take much comfort from being able to say all the proprietary software I subsidized was really somebody else's fault.
"It's complicated", and depends on a lot of factors: sometimes the equilibrium tips one way, and a vendor basically 'cleans up', ala Sun Microsystems and BSD Unix (the free ones took years to catch up). I think that is less likely to happen in this day and age, but it's a fascinating subject worthy of books, not merely a few comments on a thread.
GPL is restrictive. It may be unacceptable to put GPLd apps on the App Store because of Apple's regulations, for instance. It makes it impossible to integrate Pixar's new open-sourced code with Blender, because the licenses conflict.
Sure, the problems are caused by the contradictory licenses, but GPL is part of the problem here.
> It makes it impossible to integrate Pixar's new open-sourced code with Blender, because the licenses conflict.
Because Pixar's code is licenced under another restricted licence (MS-PL) which is crafted to be incompatible with GPL.
Apparently Pixar is talking with Ton Rosendaal (Blender development leader) about solving the licence issue so it seems it won't be 'impossible' after all. Likely some sort of dual-licencing solution will take place.
>Which will be great, but this isn't the only project using MS-PL.
It's certainly one of extremely few I've ever come across, and it's the only one which pertains to component/framework code like opensubdiv that I've seen, which is usually not GPL licenced either but rather uses permissive licencing like BSD/MIT.
>And if the GPL didn't include its "strong copyleft" text, there wouldn't be an issue.
That's the whole point of GPL, to keep the source code open. Just like the whole point of MS-PL is to serve proprietary needs while still employing the reciprocal nature of GPL.
And of course when this is shown to be problematic with a simple (GPL v2) license, the answer is to add tons of complications to the license to the point where you can't say that if you read both licenses literally, that the GPL v3 and BSD licenses are compatible.....
I actually kinda like the GPL v2. The GPL v3 license is an abomination however and needs to die.
Before you jump on me about BSD license compatibility, let me add a caveat and explanation. The caveat is that although the texts of the licenses are at least likely incompatible, "everyone" (namely every free software-inclined lawyer I have asked about this issue) agrees that since the intent was to be compatible the GPL v3 should be read to be compatible, but no two lawyers give me the same answers. I have discussed this with both Eben Moglen and Richard Fontana however. Also one cannot dispute that the GPL v3 is clearly compatible with the MIT license since that explicitly allows sublicensing.
The problem has to do with section 7 additional permissions and additional restrictions in the GPL v3, as well as the lack of a sublicensing grant in any of the BSD licenses. The BSD licenses offer a public grant by the software author to all who obtain the source code. However, they allow other intermingled code to be subject to other licensing schemes. This is different from the MIT license which directly allows sublicensing (Author A publishes, I take his work, and change the effective license without changing the software, and sell it to you, offering only some of the rights I received). The GPL v3 arguably requires a sublicensing grant from a permissive license in order to be compatible and the BSD family does not give this sort of license.
So when I talked with Moglen he suggested it would be compatible because you could add whatever additional restrictions you wanted but those would be unenforcible until actual changes were made to the software. Since the license change would be unenforcible, he suggested, the original author would not have his or her copyrights infringed. Richard Fontana however has suggested that this is a bad assumption and that developers must not make such an assumption that this is safe.
Instead Fontana suggests that additional notices should be read broadly enough to include the BSD license (and license grant) as is. However, this guts the idea of additional permissions under the GPL v3 and the requirement that they be legally removable without altering the code. Since you can't reduce the BSD license to (GPL v3 + permissions that can be removed without altering the software), the license is not compatible with the text of the GPL v3.
This means that although the licenses are (everyone agrees) compatible, it isn't at all clear as to what this means. Nor is it clear if I write a BSD license which explicitly states that sublicensing is not permitted and that permissions can only be revoked upon altering the code, whether this would also be compatible.
In short the solution to a license which may have some corner cases is a license that lawyers can argue about endlessly.
I wouldn't say they "compete", at least, not harmfully. Maria and Percona swap patches with each other, and are drop-in replacements for MySQL. Drizzle is an exploration of the idea of paying off as much as possible of MySQL's technical debt and throwing away crufty backwards compatibility. The technical ecology of users and developers around MySQL is healthier than it has ever been.