you are building a straw-man version of an unworkable payment system.
it would be totally doable for the project to say
1) we are GPL licensed
2) if you can't use GPL we will sell you a license for $X
3) all proceeds go to the project.
4) if you contribute, you give us the right to do this, and retain the funds that are generated.
Dual licensing really could be a silver bullet, but because nobody has done it well (for some reason people want to use MIT + commercial), nobody understands how powerful it could be.
This is the spot where I see it becoming a sticking point. What is "the project"? For it to be an independent entity, you need to incorporate, which, at the very least, costs money, and is therefore a huge barrier to taking this route for a small project. And it's almost by definition a small project if it's in a position to be making this decision. And if it's not an independent entity, then "the project" is probably just a euphemism for one person's pocketbook. Maybe with some pinky swearing layered on top. In any case, you've also got an image problem, because a lot of people are going to be skittish about a GPL/commercial model after what happened with MySQL and some of the other open source projects that fell into Oracle's hands.
You could instead set up a legal entity that pools the resources of several projects, and let it be the commercial vendor. That might even, in a parallel universe, have been a plausible funding model for the FSF. But even there it's probably tricky, because you still need to have some way of deciding what to do with the surplus. Having once served on the board of a nonprofit, I can say that that's tricky at the best of times, and it's probably only worse if you're talking some sort of open source foundation, because open source community members tend to get along like cats in a sack.
Long story short: While I never said that something like this was unworkable, I do think that, given how badly it tended to work out when people were trying to figure out how to make it work a couple decades ago, it would seem to be much harder to get right than it initially seems.
> you need to incorporate, which, at the very least, costs money
A nice (maybe impossible or impractical) idea would be to sell commercial licenses with eventual future payments.
As in the commercial license states an estimated price and a clause saying that at any time (with some months of notice) the price will be set to somewhere up to the estimated price. If the project chooses an higher price then the licensee is free to not pay. This would also allow prospective licensee to estimate future expenses and the project to estimate eventual revenue.
"But"? That's exactly the difference. Most of the work is done by the company so they can do more or less what they want with the project. When there are many contributors, and significant parts of the contributions have been done by people not paid by the company, dual licensing could cause all the problems described by mumblemumble.
kevsim put Qt as a counterexample and I objected that they're different beasts because Qt was developed mostly by Trolltech. Later it became more of an open project, but the dual licensing arrangement is older than that.
it would be totally doable for the project to say
1) we are GPL licensed
2) if you can't use GPL we will sell you a license for $X
3) all proceeds go to the project.
4) if you contribute, you give us the right to do this, and retain the funds that are generated.
Dual licensing really could be a silver bullet, but because nobody has done it well (for some reason people want to use MIT + commercial), nobody understands how powerful it could be.