This is considered a dick move for a project to make, often this means any non-trivial changes to existing code will be under the more restrictive licence, with no backward compatibility, preventing such changes from being incorporated by the original authors or anyone perusing a fork of the originally permissive codebase.

A common example of this kind of behaviour is GPL proponents forking BSD or other similiarly licensed software, and exclusively wrapping their contributions to it under the GPLv3.

People throw around the phrase "cognitive dissonance" lot, too loosely probably. But BSD folks who constantly tout the virtues of their license for the things that it allows downstream developers to do and then complain when someone actually exercises those options are the single best real world example of cognitive dissonance that I've ever encountered.

That's like saying that you can't be mad about someone not repaying you a loan because you haven't written up a legal contract defining the conditions. Or like saying it's hypocritical to defend free speech and criticize someone for what they've said.

Just because you don't agree with an action doesn't mean you must find it ethical to use the Force of Law to punish it.

It's nothing at all like that.

A license change certainly shouldn't happen lightly, or without consulting the community. In this case, it looks like an extensively considered decision with substantial community feedback.

And patent lawsuits hurt, so as reasons to change licenses go, that seems like a pretty good one.

> A common example of this kind of behaviour is GPL proponents forking BSD or other similiarly licensed software, and exclusively wrapping their contributions to it under the GPLv3.

A much more common example is a proprietary software vendor taking a lax licensed project and creating a proprietary fork of it. Of course, BSD proponents don't mention the far more common case (because it wouldn't help the narrative that GPL proponents only spend their time relicensing code).

Why you don't have a problem with proprietary forks but do have a problem with copyleft forks is beyond me. Especially since sometimes copyleft forks are created because the developers made so many changes that it stands in its own right as a separate project (and the developers feel that user freedom trumps upstreamability).

The proprietary "forks" are often not distributed as source, they're either internal forks, or simply part of a larger product. The difference is that proprietary forks of permissive code is often kept in sync with upstream and you only ever learn of its existence when they decide to contribute back patches. They typically have the courtesy of making those available under the original license terms for everyone to benefit from.

Internal forks are not subject to the GPL requirements anyway, so that can't be an argument against it.

In fact, licenses that do not permit private copies of the modified software are not considered free software according to the FSF[1] (which I agree with).

[1]: https://www.gnu.org/licenses/license-list.en.html#NonFreeSof...

> The difference is that proprietary forks of permissive code is often kept in sync and you only learn of its existence if they decide to contribute back patches. They typically have the generosity of making those available under the original permissive licence.

This sounds like cherry-picking to me. "If they decide to contribute back patches" is something that is not up to you -- and the same logic applies to copyleft forks just as much as it applies to proprietary forks (the quotes are not necessary, proprietary forks of lax licensed software are forks like any other kind of fork). Just because someone has used a license that gives users freedom should not be construed as it being a contribution to you.

> They typically have the generosity of making those available under the original permissive licence.

They also typically have the "generosity" of not providing source code to users, meaning that the users have no freedom when using the software. But hey, at least you got some marginally useful patches that probably aren't all that great. Yay.

Also, please note that some projects do dual-license their changes. I don't understand why you're so salty on this topic.

> Especially since sometimes copyleft forks are created because the developers made so many changes that it stands in its own right as a separate project (and the developers feel that user freedom trumps upstreamability).

That "user freedom" you mention, which you had when you forked the original permissive codebase to GPLv3, is now lost on those new users you have wanting to make a similar change. It was certainly free enough for you then. It's a dick move ideological statement to push the notion of GPL "user freedom".

The freedom to relicense software is not under the free software definition, so the users have lost no freedoms. The only people that have lost some freedom are distributors of software, which are not the group of people the GPL is trying to protect.

This is all quite funny, because usually lax license advocates say "if you like the GPL then just relicense it because we give you that freedom" but then turn around and say "it's a dick move to relicense our code". If you didn't want people to relicense your code, don't use a license that permits it -- simple as that.

Why is this a dick move?

It only applies to further work done on the project. By licensing your work under a BSD/MIT/etc. style license you explicitly gave anyone permission to use the work in nearly any way they wanted, including as part of a Apache, GPL3, or even completely proprietary closed-source project.

If everyone else on a project decides to use a different license than you picked for their future hard work, that's their choice, not yours.

I said it was a dick move, not an invalid one. The person is choosing to licence their contributions with an arbitrary set of additional restrictions.

And like any other choice, it's not inherently free from criticism.

The whole point of the switch to Apache 2.0 was the patent grant. The old code will not be effectively under the Apache 2.0 license as far as this clause is concerned because the patent grant is a restriction on the copyright holder, not the user. You can't just take the fact that the authors of some parts of the code agreed not to sue you for patents they implemented in their respective contributions and then force everybody else not to sue you for their own patents.

I'm not suggesting that it's perfect. I'm just suggesting that from a legal point of view, the current license grants enough permissions that they don't have to have unanimous agreement from every copyright holder; the scenario painted in the linked email couldn't happen as written.

(They may still want unanimous agreement, either to have more code under the new license or to confirm community consensus.)