As a business model dual licensing means having a free software license (which may or may not be copy-left) and a proprietary software license. Having 2 or more free software licenses is not a business model, even if it is handy for letting people get around the GPL. There is no reason to pay for the second free software license. Otherwise you could just use MIT or the equivalent and be rolling in money. Obviously it doesn't work that way. Pedantically, "dual licensing" means to have 2 licenses. Companies are willing to pay for the proprietary software license because they want to use that code with their own proprietary code.
The only potential difference between that and "open core" is that open core generally talks about applications. Dual licensing a library allows people to use that library in proprietary software. But let's not kid ourselves -- that library is proprietary. That's the whole point.
Can you point to a project with dual licencing where all or nearly all of the development is not done by a singular company. This is rare (if it even happens at all), because you need to have copyright assignment in order to relicense the software under the proprietary license. Any other changes essentially causes a fork in the free vs. proprietary version. This is precisely the same reason why open core and other dual licensed projects tend to be controlled by a single entity. Unless you fork, there is no way to contribute without having to go through the controlling entity.
Potentially, you have in mind that many dual licensed libraries do not offer more features in the proprietary version as compared to the free version. With open core applications, where the license is less important (or not important) to the customer, you need to add different functionality to get them to buy the proprietary version. So I'll grant you that.
I'm not aware of any common difference in terminology usage. Open core is dual licensing. The fact that applications tend to diverge between then free and proprietary versions is due to the fact that nobody wants to link it to another application -- they just want to use it. In order to get people to pay for the proprietary version you need to add more features. But that's not a difference in strategy, it's just a reality of the thing you are selling. Libraries usually don't bother making different feature sets because there is no need -- people are willing to pay for the proprietary version without the extra work.
What no, open core is not dual licensing, at least, not by what is meant here with "dual licensing".
Dual licensing is about selling exceptions. Selling copyleft exceptions. There's no dual licensing without copyleft, because there is no exception to sell. And yes, it requires a single copyright holder. FFTW is an example of dual licensing. Octave gets FFTW because we like copyleft and Matlab gets FFTW because they like to pay to hide their code.
But it doesn't just have to be a library. MongoDB also sells exceptions because people are irrationally afraid of the AGPL.
I think you were confused by software like Firefox which is dual or triple-licensed and all recipients get to pick which license they want to follow, but that's not what was being discussed here.
Sigh... you are right about the copyleft thing. I'm not sure where my head was. Just so I get this right: you're saying that "open core" is essentially having a copyleft license and a proprietary license, while "dual licensing" is having a copyleft license and another non-copyleft free software license? If so, I can understand what you are saying :-)
Open core is freemium. You can use the base under a free license but if you want fancy features, those are under a non-free license.
Selling exceptions (or what someone else called, "dual licensing") means everyone gets the same software, both free and non-free, but people who don't want copyleft have to pay.
The only potential difference between that and "open core" is that open core generally talks about applications. Dual licensing a library allows people to use that library in proprietary software. But let's not kid ourselves -- that library is proprietary. That's the whole point.
Can you point to a project with dual licencing where all or nearly all of the development is not done by a singular company. This is rare (if it even happens at all), because you need to have copyright assignment in order to relicense the software under the proprietary license. Any other changes essentially causes a fork in the free vs. proprietary version. This is precisely the same reason why open core and other dual licensed projects tend to be controlled by a single entity. Unless you fork, there is no way to contribute without having to go through the controlling entity.
Potentially, you have in mind that many dual licensed libraries do not offer more features in the proprietary version as compared to the free version. With open core applications, where the license is less important (or not important) to the customer, you need to add different functionality to get them to buy the proprietary version. So I'll grant you that.
I'm not aware of any common difference in terminology usage. Open core is dual licensing. The fact that applications tend to diverge between then free and proprietary versions is due to the fact that nobody wants to link it to another application -- they just want to use it. In order to get people to pay for the proprietary version you need to add more features. But that's not a difference in strategy, it's just a reality of the thing you are selling. Libraries usually don't bother making different feature sets because there is no need -- people are willing to pay for the proprietary version without the extra work.