7 ms·

We are about to open source our projects too [0], and have been faced with the question of xGPLv3 vs other permissive licenses. Not a big fan of source-availabl

We are about to open source our projects too [0], and have been faced with the question of xGPLv3 vs other permissive licenses. Not a big fan of source-available licenses because as Bryan Cantrill argues, one is better off with closed-source in that case [1]. From all that I have read, the Mozilla Public License v2 [2] (file-level copyleft) seems like a good intermediate between GNU family of licenses (strong copyleft) and Apache / MIT / 3-Clause BSD (copyright). The problem with using a permissive license such as Apache is, anyone can fork the project exclusively under xGPLv3. If that fork becomes more popular, there's no way for the Apache-licensed upstream to merge any patches from the xGPLv3d fork back in. With MPLv2, all "files" in the immediate xGPLv3 fork are automatically dual-licensed under both, xGPLv3 and MPLv2. This means MPLv2-licensed upstream is free to merge in changes without worries from immediate forks. MPLv2 additionally bakes in a choice for the original developer (viz. "initial Contributor") to make xGPL forks illegal (using the incompatibility clause), but it isn't the default. The Eclipse Public License v2 [3], which is very similar to MPLv2 in its copyleft aspects, takes this a step further and makes xGPL forks illegal by default. The original developer; however, can explicitly choose to permit xGPLv3 forks. [0] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/ https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/ [1] http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts-its-midlife-crisis/ http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts... [2] https://www.mozilla.org/en-US/MPL/2.0/FAQ/ https://www.mozilla.org/en-US/MPL/2.0/FAQ/ [3] https://www.youtube-nocookie.com/embed/uKKVydoqF_0 https://www.youtube-nocookie.com/embed/uKKVydoqF_0

LukeEF 6y ago
We thought about the Eclipse Public License in advance of the shift. There is a very persuasive member of our community who argued in its favor. In the end, it is ease of recognition that swayed us to Apache. If you have to forward for approval or read the details of the license before getting started, that is often a bridge too far. Good luck with the open sourcing!
haberman 6y ago
> The problem with using a permissive license such as Apache is, anyone can fork the project exclusively under xGPLv3. If that fork becomes more popular, there's no way for the Apache-licensed upstream to merge any patches from the xGPLv3d fork back in. I'm curious if anyone knows of any cases where this actually happened.
- jabl 6y ago
  LibreOffice vs OpenOffice. LibreOffice is, IIRC, under the MPL2, and can take improvements from the Apache-licensed OpenOffice (and has done so in the past, though Apache OpenOffice has been moribound for its entire existence so there's not much to take from there anymore), but Apache OpenOffice can't take improvements from LibreOffice.
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.
pmoriarty 6y ago
"The problem with using a permissive license such as Apache is, anyone can fork the project exclusively under xGPLv3. If that fork becomes more popular, there's no way for the Apache-licensed upstream to merge any patches from the xGPLv3d fork back in." If the GPL fork becomes more popular then one of the main arguments for not having a GPL license falls apart.
josephcsible 6y ago
> The problem with using a permissive license such as Apache is, anyone can fork the project exclusively under xGPLv3. 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.
- ignoramous 6y ago
  That's assuming the businesses using the Apache Licensed version are comfortable with the original developer moving to xGPL. 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.
  - josephcsible 6y ago
    What if you went with GPLv2 only as your license? It isn't AGPL-compatible, so nobody could release an AGPL fork, and then companies wouldn't have to worry about it unless they distributed your code to other people, rather than just using it themselves, with the former being way less common than the latter. And most companies are okay with GPLv2 since they use Linux.
FeepingCreature 6y ago
The irony of someone using Apache license complaining that other people's usage of their code doesn't let them merge changes back is, of course, palpable. 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.
- quadrangle 6y ago
  I agree with your sentiment overall (if you don't want obstacles to merging back downstream code, maybe consider requiring that it keep compatible licensing, i.e. use the GPL, use copyleft). 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.
  - FeepingCreature 6y ago
    Yes, but by the point your downstream project has changes that you want to merge back, it is the upstream for purposes of GPL sentiment. These roles are transactional, not historic. Otherwise, any company could break the GPL wide open by just morally considering themselves to be the upstream.
    - quadrangle 6y ago
      Not strictly. Downstream GPL users do not need to publish their changes. Businesses and individuals can get GPL software, change it for their own internal use and keep the changes private. 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.

LukeEF 6y ago

We thought about the Eclipse Public License in advance of the shift. There is a very persuasive member of our community who argued in its favor. In the end, it is ease of recognition that swayed us to Apache. If you have to forward for approval or read the details of the license before getting started, that is often a bridge too far. Good luck with the open sourcing!

haberman 6y ago

> The problem with using a permissive license such as Apache is, anyone can fork the project exclusively under xGPLv3. If that fork becomes more popular, there's no way for the Apache-licensed upstream to merge any patches from the xGPLv3d fork back in. I'm curious if anyone knows of any cases where this actually happened.

jabl 6y ago
LibreOffice vs OpenOffice. LibreOffice is, IIRC, under the MPL2, and can take improvements from the Apache-licensed OpenOffice (and has done so in the past, though Apache OpenOffice has been moribound for its entire existence so there's not much to take from there anymore), but Apache OpenOffice can't take improvements from LibreOffice.

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.

pmoriarty 6y ago

"The problem with using a permissive license such as Apache is, anyone can fork the project exclusively under xGPLv3. If that fork becomes more popular, there's no way for the Apache-licensed upstream to merge any patches from the xGPLv3d fork back in." If the GPL fork becomes more popular then one of the main arguments for not having a GPL license falls apart.

josephcsible 6y ago

> The problem with using a permissive license such as Apache is, anyone can fork the project exclusively under xGPLv3. 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.

ignoramous 6y ago
That's assuming the businesses using the Apache Licensed version are comfortable with the original developer moving to xGPL. 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.
- josephcsible 6y ago
  What if you went with GPLv2 only as your license? It isn't AGPL-compatible, so nobody could release an AGPL fork, and then companies wouldn't have to worry about it unless they distributed your code to other people, rather than just using it themselves, with the former being way less common than the latter. And most companies are okay with GPLv2 since they use Linux.

FeepingCreature 6y ago

The irony of someone using Apache license complaining that other people's usage of their code doesn't let them merge changes back is, of course, palpable. 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.

quadrangle 6y ago
I agree with your sentiment overall (if you don't want obstacles to merging back downstream code, maybe consider requiring that it keep compatible licensing, i.e. use the GPL, use copyleft). 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.
- FeepingCreature 6y ago
  Yes, but by the point your downstream project has changes that you want to merge back, it is the upstream for purposes of GPL sentiment. These roles are transactional, not historic. Otherwise, any company could break the GPL wide open by just morally considering themselves to be the upstream.
  - quadrangle 6y ago
    Not strictly. Downstream GPL users do not need to publish their changes. Businesses and individuals can get GPL software, change it for their own internal use and keep the changes private. 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.