Some projects are available under restrictive FOSS licenses (GPL or AGPL, for example) which preclude them from being used in proprietary projects. The developers can then sell separate commercial licenses which allow the code to be used in proprietary projects.
How common is this?
Examples I'm aware of:
Those licenses do not do what you think they do. Sadly, the GPL and similar licenses are widely misunderstood (even by the people that write them — by which I mean that the law often has a different idea of what given terms mean than the license writer).
The GPL does not preclude you from using it in proprietary projects. Many proprietary projects have dependancies on FOSS licensed applications or libraries. All it does is preclude you from trying to ship a binary without source, or to apply extra restrictions on those projects.
What's more, if you wrote the code in the first place, even if you publish it under the GPL, you can do anything you like, and make any exception you like. You can even stop producing code in that license and produce only proprietary licensed versions.
However, to answer your question. It's become quite "en vogue" for companies to publish a "community" version of a product and an "enterprise" version. Examples include Vayatta, Alfresco, Flowplayer, and a whole bunch more.
The idea is that anyone that needs support will buy it anyways, and those that don't wouldn't buy your program anyways. So it fosters a sort of "good will" even though it's really just a scheme.
The GPL license has a couple of clauses/definitions that are not clear outside the original scope (C programming) that give corporations heartburn.
It's for the reason of potentially giving away corporate secrets that most corporations shy away from GPL based projects. Additionally, there may be other legal/proprietary knowledge type risks that I'm not aware of.
Dual licensing is not uncommon. It's a way of ensuring that the base product is always available, while providing value to people willing to pay for it. It's also not uncommon to simply choose a FOSS license that doesn't contain the scary clauses such as the ASL, MIT license, or some variation. It gives corporations much less heartburn to provide attribution than the source code. In short it's better to say the product uses Apache Xerxes than to have to release the source code because it embedded a GPL'd XML parser.
Additional background on American copyright Back in the 90's I attended a 2 week seminar that covered copyright law, as pertains to the entertainment industry. That seminar was taught by one of the most pre-eminant lawyers focusing on the subject at that time: Al Schlessinger. What follows is a brief summary of information from that seminar (I myself am not a lawyer, I'm just repeating information):
It is for this reason that when faced with the prospect of incorporating GPL or LGPL code/libraries into your commercial application that you vet everything with a lawyer who specializes in this type of work. They exist, and my previous company used one to discover legal risks. The lawyers did point out the potential problem points, which we had to relay to our client.
The tricky point for dual licensing is that the entity who is licensing the work must be able to prove that they have the only copyright for the work. That is why when you become a committer on some of the larger umbrella organizations (GNU, Apache, etc.) you are required to sign an agreement that you turn over the copyright of that code to that organization. When that condition is met, the organization can dual license, change the license model, or whatever they need to do at will.
It's because there is enough Fear, Uncertainty, and Doubt (FUD) surrounding the GPL on both sides of the equation that recently there's been more of a push to use corporate friendly licensing models.
Can the project you derived your work from cry foul and claim that you are in violation of the terms of the license? Yes. Will they? Probably not. That doesn't mean you should flagrantly violate its terms however.
