Why is this a problem? If a GPL fork becomes more popular, you can switch your own license to GPL too, and then take the changes back. The real risk of using a pushover license is that someone makes a proprietary fork, in which case you are locked out of their changes forever, which is the exact thing the GPL disallows.

Also, the businesses need to be wary of other proprietary code they might have to now open source as an unintended side-effect of moving to xGPL.

That's exactly what the GPL is for!

Someone using Apache complaining about GPL relicenses is saying they're fine with closed-source products making money off their private forks of their code without being forced to contribute it back, but open-source projects doing the same thing is where they draw the line.

But this sort of contribute-back-upstream is not what the GPL was written for and not how it behaves. The GPL is specifically a pass-it-forward downstream focused license. It is about requiring others to pass on the freedoms. The idea that it has any send-back-upstream requirements is a common misunderstanding that shouldn't be encouraged.

Otherwise, any company could break the GPL wide open by just morally considering themselves to be the upstream.

GPL's upstream features are incidental and often practical but are not the point of the GPL and more importantly do not describe how it works legally.

My personal reasons for MPL2 are basically:

- Modern goodies like explicit patent protections without being GPLv2 incompatible like Apache.

- Showing the sharing "spirit" I'd like to see, even though it's in practice impossible to enforce against a "hostile" user (see above). That is, feel free to use it in your proprietary product, but if you make improvements to my code please share those with me.

That being said, I'm not actually sure that MPL2 is worth it, considering it's very much an uncommon license compared to the big permissive ones.

I'm not sure I understand your arguments about MPL2 being better protected against forks with stronger copyleft licenses. The forker can still make their own additions subject to the xGPLv3, as long as they're in separate source files, effectively making the combined work xGPLv3.

IANAL. MPLv2 has two modes of protection:

1. By default, the immediate fork of a MPLv2 project under xGPLv3 is auto dual-licensed (for existing files, at least). Usually, the project stays dual-licensed (even for the larger work) unless the contributors make an explicit decision to remove the top-level MPLv2 license file.

2. Initial Contributor (original developer) can choose to make the "Covered Software" incompatibile with secondary licenses (like xGPLv3) for posterity.

> An evil corporation that wants to leech without giving anything back can practically as easily do that with an MPL2 licensed project as with a permissive licensed project.

Evil corp at least (if nothing) is required to open source their changes to MPLv2 files (part of the original work), if any. Whereas Apache / MIT / BSD don't require any form of reciprocation except an attribution.

> That being said, I'm not actually sure that MPL2 is worth it, considering it's very much an uncommon license compared to the big permissive ones.

From what I know, MPLv2 is well understood and it isn't ambiguous as WTFPL or confusing as AGPL. Hashicorp and Mozilla are two of the biggest corporate users of the license I know.

Of course there can be no argument that xGPLv3 protects the interests of the consumers better, though, MPLv2 (and EPLv2), I feel is a good compromise.

No, you can't change the license of existing code that you don't hold copyright of. Even permissive licenses like MIT don't allow that. Where you can add your own license terms is for additional code you wrote that you hold the copyright for. Permissive vs. weak vs. strong copyleft then tell you under which terms you can combine your own code and the other code that you forked.

> 2. Initial Contributor (original developer) can choose to make the "Covered Software" incompatibile with secondary licenses (like xGPLv3) for posterity.

The "secondary license" thing in MPL2 is a (clever) hack to make it compatible with *GPL. That just means that without the secondary license you can't make a combined work (called "larger work" in the MPL2) that contains both MPL2 code and your own GPL code. It doesn't allow you to relicense MPL2 code to GPL.

> Evil corp at least (if nothing) is required to open source their changes to MPLv2 files (part of the original work), if any. Whereas Apache / MIT / BSD don't require any form of reciprocation except an attribution.

Yes, but nothing prevents Evil Corp from just doing minimal modifications to the MPL2 code to add entry points or call out to the proprietary code in other files.

That is sort of the argument against weak copyleft licenses in general; they are easy to circumvent. So if you want copyleft protection, you should go for a strong copyleft license, or then you just accept that Evil Corp may leech and you might as well use a simple permissive license.

> From what I know, MPLv2 is well understood and it isn't ambiguous as WTFPL or confusing as AGPL. Hashicorp and Mozilla are two of the biggest corporate users of the license I know.

Maybe. I mean, if you look e.g. at https://resources.whitesourcesoftware.com/blog-whitesource/o... MPL2 isn't even a rounding error.

> Of course there can be no argument that xGPLv3 protects the interests of the consumers better, though, MPLv2 (and EPLv2), I feel is a good compromise.

Yeah, I think in many ways GPLv3 is pretty good, but considering how soundly it has been rejected by corporations I'm not sure it's worth it..

It's not that simple, see: Modifying and Distributing Files Licensed Under Both the MPL and (L)GPL.

Once an MPL-licensed file has been distributed as part of a larger (L)GPL-licensed work, third parties who receive the file may use and redistribute the file under the terms of either license. As a result, new modifications can be provided to recipients under the terms of both licenses, or solely under the terms of the (L)GPL.

https://www.mozilla.org/en-US/MPL/2.0/combining-mpl-and-gpl/

> So if you want copyleft protection, you should go for a strong copyleft license...

True, but MPLv2 with incompatibility clause (or EPLv2) prevents stronger copyleft, which has some nice properties whilst also retaining a weak "file-level" copyleft (which enterprises are okay with).

If the GPL fork becomes more popular then one of the main arguments for not having a GPL license falls apart.

Good luck with the open sourcing!

I'm curious if anyone knows of any cases where this actually happened.