I’m very suspicious of the ability of this kind of license to make formerly-free software no longer free. If the majority of a group of developers could vote to, say, switch the Linux kernel from GPLv2 to GPLv3, they could also vote to switch the Linux kernel from GPLv2 to a novel license that’s like the GPLv3 in every respect except it bars ICE from using the Linux kernel (substitute any organization that an motivated political faction of software developers might organize against).
And in general, once you have a process for monetary and political benefits to flow to people who have been democratically accepted as contributors, you create two systems of perverse incentivizes. Random people who want to control the political direction of some well-known software project, or get a piece of the profits from it, are incentivized to do the bare minimum necessary to get themselves elected as collaborators, even if they don’t necessarily care about the project as a piece of software. Simultaneously, existing contributors are incentivized to deny all new contributors, in order to protect their project from the parasites in the first group, or to keep control of the flow of money and power locked up within a small group of people (and of course there’s no politically-neutral way to decide whether a prospective-newcomer to a project is a potential parasite or a potential valuable contributor who should be unjustly denied participation).
I’m not worried about the relicensing aspect. You could always set the bar higher for licensing, such as requiring a supermajority, which I think would be appropriate anyhow. And I’ve never been particularly worried about politically motivated licenses; that’s what copyleft licenses are. Even if we disagree on that, consider that the existing code can always be forked using the previous license, which is not any worse than what we have currently.
You’re spot-on that the perverse incentives bear more examination. I don’t know what the right answer is, here. You might end up with a small guild of “contributors” who do most of the work, and take bug reports and feature requests but not actual patches, and I think that’s fine for some projects and likely wouldn’t be a drastic departure from the status quo. It’s also important to think about how these teams would evolve over time, as people drop off and have other commitments. Would they voluntarily resign, so they don’t receive payments? What happens if active contributors want to relicense, and the original founders are otherwise inactive but block the relicensing?
While there are problems with the model license (and I know the author would be interested in Github issues about these problems, if you’re up for it) I think the overall idea of cross-license collaboratives is pretty cool and might work really well if someone governance-minded took a crack at the license.
I agree that the governance model needs work. Do you have any ideas on what might work better? (Proportional votes; core vs. non-core contributors; something entirely different…)
I like Qt model.
They have both commercial and (L)GPL versions. Qt devs are paid from this. In order to contribute (externally), one needs to sign an agreement: https://wiki.qt.io/Qt_Contribution_Guidelines
As a Qt customer, it might be good idea to contribute back with bugs/improvements (not to patch upgrades all the time). Otherwise to incentivize outside contributors, a bounty program can be introduced.
I’m very suspicious of the ability of this kind of license to make formerly-free software no longer free. If the majority of a group of developers could vote to, say, switch the Linux kernel from GPLv2 to GPLv3, they could also vote to switch the Linux kernel from GPLv2 to a novel license that’s like the GPLv3 in every respect except it bars ICE from using the Linux kernel (substitute any organization that an motivated political faction of software developers might organize against).
And in general, once you have a process for monetary and political benefits to flow to people who have been democratically accepted as contributors, you create two systems of perverse incentivizes. Random people who want to control the political direction of some well-known software project, or get a piece of the profits from it, are incentivized to do the bare minimum necessary to get themselves elected as collaborators, even if they don’t necessarily care about the project as a piece of software. Simultaneously, existing contributors are incentivized to deny all new contributors, in order to protect their project from the parasites in the first group, or to keep control of the flow of money and power locked up within a small group of people (and of course there’s no politically-neutral way to decide whether a prospective-newcomer to a project is a potential parasite or a potential valuable contributor who should be unjustly denied participation).
I’m not worried about the relicensing aspect. You could always set the bar higher for licensing, such as requiring a supermajority, which I think would be appropriate anyhow. And I’ve never been particularly worried about politically motivated licenses; that’s what copyleft licenses are. Even if we disagree on that, consider that the existing code can always be forked using the previous license, which is not any worse than what we have currently.
You’re spot-on that the perverse incentives bear more examination. I don’t know what the right answer is, here. You might end up with a small guild of “contributors” who do most of the work, and take bug reports and feature requests but not actual patches, and I think that’s fine for some projects and likely wouldn’t be a drastic departure from the status quo. It’s also important to think about how these teams would evolve over time, as people drop off and have other commitments. Would they voluntarily resign, so they don’t receive payments? What happens if active contributors want to relicense, and the original founders are otherwise inactive but block the relicensing?
While there are problems with the model license (and I know the author would be interested in Github issues about these problems, if you’re up for it) I think the overall idea of cross-license collaboratives is pretty cool and might work really well if someone governance-minded took a crack at the license.
How the votes are weighted? By quantity (LOCs) or importance (who will decide what is important, what’s not) or something else?
Is this model vulnerable to 50%+1 attack similar to bitcoin?
Votes are not weighted, it’s one person, one vote.
Thanks for finding this. It seems too dangerous. One group of committers can fix grammar and overtake the project.
I agree that the governance model needs work. Do you have any ideas on what might work better? (Proportional votes; core vs. non-core contributors; something entirely different…)
I like Qt model. They have both commercial and (L)GPL versions. Qt devs are paid from this. In order to contribute (externally), one needs to sign an agreement: https://wiki.qt.io/Qt_Contribution_Guidelines
As a Qt customer, it might be good idea to contribute back with bugs/improvements (not to patch upgrades all the time). Otherwise to incentivize outside contributors, a bounty program can be introduced.