Is this the result of MySQL adopting the GPL license? I mean, what about if MySQL were BSD licensed?
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.
Instead the real risk is that GPL is not free enough.
The most famous counter example is SunOS, which was directly based on the Berkeley code.
Of course, times are different now - the internet has changed a lot of things.
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.
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.
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.
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).
BSD business models:
* Services: training, consultancy, ...
and MOST important:
* 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.