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".

It does not matter how you twist it, GPL is more restrictive, than MIT or BSD. And that's without going into you "freedom of usera" FUD.

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".

You can call it more "robust", "strict" or a number of other words that more precisely reflect the GPL role and goals.

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"?

> There are less things you can do with GPLed software

Yes. You won't be able to restrict your users with GPL.

"Robust" because the software, once licensed under it, will remain free.

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.

I don't know that is true. I would bet that Greenplum and EnterpriseDB have smaller marketshare, for example, than official PostgreSQL.

"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. And if the GPL didn't include its "strong copyleft" text, there wouldn't be an issue.

It's coercion which tries to make everything freer, but in this case made things less free.

>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.

"Robust" is spin. "Restrictive" is neutral and factual.

Haven't we had enough annoying GPL vs BSD license arguments in the past 20 years?

"Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them." -- the guidelines