[cxr]

MPL2 is great for something like this. It's not Apache 2 or MIT, but is compatible with them (if that's how you wished to license your stuff, for example, or if you wished to use libraries that are)—as well as being compatible with GPLv2 by default.

In practice, the fact that MPL2 is not as permissive as Apache 2 or MIT and has copyleft-like reciprocal terms is not a problem, because it's a file-based license, and few (if any) developers tend to be interested in changing the source files for the upstream project, and those who are are usually people doing so because they're in the process of trying to submit a fix upstream, anyway. For the fraction of a fraction of a minority of folks for whom it still would be a problem, it's as simple as the upstream project either declaring Apache 2 as a compatible Secondary License or just saying that they won't enforce MPL2's reciprocal clauses against downstream folks who are using the project in a way that is permitted by Apache 2.

MPL2 is an extremely underused and underappreciated license.

[fotcorn]

In my experience, people do hack game engines all the time for game specific optimizations, fixes and special features. At least in the bigger AA/AAA games I've seen. We tried to sell our plugin as binary only (C++), but basically everybody wanted the source code to hack and extend it. So people wouldn't be happy with MPL.

I agree for other things, e.g. webdev, I never had to hack Django or Vue.js.

The game industry is notorious for using, but not contributing back to open source. I don't want to know how often the same bug in recast/detour has been fix in different games, and never upstreamed.

[cxr]

> people wouldn't be happy with MPL.

Only if you ignore, like, everything that I wrote.

[ensignavenger]

I agree with this mostly. I would love to see the MPL2 used more often instead of the GPLs. I think it is a superior license in almost every way. I also love the Apache and MIT licenses for their own reasons, I don't really see MPL as a replacement for Apache/MIT, more as a replacement for the GPL.

[cxr]

Not exactly what I was going for with my initial remarks.

> I don't really see MPL as a replacement for Apache/MIT, more as a replacement for the GPL

That doesn't really make sense. GPL is a hard copyleft license, and MPL2 is not. The latter can be seen as a replacement for the former perhaps in the sense that a person who is being charged $20+/mo for streaming video might like to see their provider to offer a $0 "replacement" instead—i.e. a change clearly to the benefit of one party with regard to narrowly delivering something it sees as desirable, to the detriment of the other party (or more accurately: without regard to the benefit or detriment to the other).

MPL2 is a great alternative for the use cases I described—where the constraints/conditions of the license are agreeable to both upstream and downstream due to the way it matches how they already interact in practice (and expect to continue interacting).

> I would love to see the MPL2 used more often instead of the GPLs

I don't see GPL as overused at all in 2023. If anything, it, too, is underused.

MPL2 and GPLv2/GPLv3/LGPL/AGPL are underused relative to the fairly new tendency to reflexively reach for e.g. the MIT License and then get stung by the consequences of doing so, resulting in formerly libre codebases getting locked down in future revisions under a regressive, non-FOSS, shared source license (or fully proprietary), when the reality is that e.g. GPL would have better suited the project from the beginning and wouldn't have led to the circumstances that ended with the owner pulling back from FOSS entirely.