That's another can of worms. If it were BSD licensed, they would not have made so much money, because they couldn't have done the dual-licensing trick.
Indeed, this is surely a price to pay, BSD will hardly make you rich even with a very successful product, but the project itself is much more protected probably.
When it's GPL'ed, there can be no proprietary forks. Companies who depend on the product will continue to maintain it and all source will still be available as keeping an internal fork is costlier.
If a program is BSD'ed, there is nothing to prevent a company to close it and start selling it as proprietary.
Proprietary forks are an illusion. The value of the project is in its developers, to take the code, close it, and develop it getting external developers, good ideas, and so forth, is a massive amount of work. This is why you can think of tons of BSD-ish very successful projects not forked.
Instead the real risk is that GPL is not free enough.
A proprietary fork can diverge very little, still grabbing the improvements of the original project. The reason you don't hear about them is because the vendors of such software have no incentive (and mostly no need) to say their product is mostly something they got for free.
I suspect they are more common than we know.
In essence, the only freedom GPL forces you to give up is the freedom to turn a free product into a proprietary one.
No, it is not.
But it is a result of overconfidence, caused by belief that
GPL is a silver bullet. People, who run BSD-licensed projects, in my observation, tend to be more cautious, because BSD license provides no protection against "privatization".
Most of the technology partners, where most of the innovation in the MySQL space happen nowadays, depend on being able to get licenses for MySQL so that they can combine their closed source application or closed code (like storage engines) with MySQL
This is clearly a problem with GPL. The economic model of a BSD-licensed product can't be broken just not selling licenses, as everybody will continue to use the code for whatever purpose.
Refusing to subsidize proprietary work is the purpose of the GPL. It's only a problem for vendors who become dependent on buying non-GPL licenses and will not open their own work.
And decrying a problem only after he stopped getting paid for perpetuating it? Wow. That's like selling your house and then urging it be condemned.
No, the problem is the dual-license strategy combined with changing business models. If it had been pure GPL from the start, anyone who couldn't work with that would never have used it in the first place. But because they sold licenses for closed source use, now there are customers using it who may be stuck choosing from three unpleasant options--keep using unmaintained code (if the license even allows that), find a way to use GPLed code, or find a new database.
It's not really any different from what would happen if a proprietary software vendor went out of business or killed a product, since that's effectively exactly what happened. The fact that the code also exists in GPL form is largely irrelevant and I don't know why you're focusing on it.
Without the dual-license strategy available, BSD software doesn't really HAVE an economic model other than charity (nor does pure GPL of course--just look at RMS--but at least GPL gives you the warm feeling of knowing that no one will be purely freeloading off your generosity).
* Closed source "PRO" versions. This has a number of declinations. For instance only add "enterprise" features in the closed source fork, or alternatively develop an important feature for the closed source fork and release it for the open source one after N months, and so forth.
A plugin system can also work: develop a number of closed source plugins about features that are not so general to enter in the real release but that many people think they absolutely need, and sell this plugins. Note that here you are not undervaluing the open source fork as this are stuff that anyway you don't think are so general to be included.
