5 ms·

I have released some minor personal projects under the MPL2, but in practice AFAICS MPL2 isn't much stronger than the permissive licenses (Apache/MIT/BSD/etc.).

by jabl 6y ago

I have released some minor personal projects under the MPL2, but in practice AFAICS MPL2 isn't much stronger than the permissive licenses (Apache/MIT/BSD/etc.). 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. 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.

pseudalopex 6y ago
Apache is GPL3 compatible. Did you mean GPL2 incompatible?
- jabl 6y ago
  Yes, I clarified that.
ignoramous 6y ago
> I'm not sure I understand your arguments about MPL2 being better protected against forks with stronger copyleft licenses. 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.
- jabl 6y ago
  > 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. 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/open-source-licenses-trends-and-predictions 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..
  - ignoramous 6y ago
    > No, you can't change the license of existing code that you don't hold copyright of... 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/ 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).

by jabl 6y ago

pseudalopex 6y ago

Apache is GPL3 compatible. Did you mean GPL2 incompatible?

jabl 6y ago
Yes, I clarified that.

ignoramous 6y ago

> I'm not sure I understand your arguments about MPL2 being better protected against forks with stronger copyleft licenses. 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.

jabl 6y ago
> 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. 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/open-source-licenses-trends-and-predictions 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..
- ignoramous 6y ago
  > No, you can't change the license of existing code that you don't hold copyright of... 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/ 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).