First topic: Virtualbox does not rely on kvm to get stuff done. They have different source base, and even if they exchange patches, that does not makes them a derivate work of kvm.
Second point is that Oracle owns VirtualBox brand, so they can pretty much deal with licensing of "chunks" of that software(base, extensions, plugins, etc) the way they want. This allow them to keep virtualbox opensourced while develop a module that is proprietary. And if you take a look at the Licencing FAQ, this is pretty much what they state:
How is VirtualBox licensed?
The VirtualBox base package (i.e., everything but the VirtualBox
Extension Pack) contains the full VirtualBox source code and platform
binaries and is licensed under the GNU General Public License, version
2. You can distribute and modify the base package, provided that you distribute all modifications under the GPLv2 as well.
The VirtualBox Extension Pack is available under the VirtualBox
Personal Use and Evaluation License, which is a free license for
personal, educational or evaluation use, or an Enterprise License,
which is for fee license that covers most other business uses.
More information about the Oracle VM VirtualBox Enterprise License for
the VirtualBox Extension Pack can be found on the Oracle VM
VirtualBox pages, which also contains a link to the Oracle Store
where you can directly buy licenses. Please contact Oracle for
additional information.
Oracle states clear that only the base package is GPLv2 and Extensions are nonfree.
This is why projects have a Development agreement on projects they create, or take ownership when they want to be the ones to centralize all issues, so they can "own" the code that you have contributed, but the trick here is that they have the power to change the license if they want. This is a trust relationship between the developers and the company/entity that now owns the code. Examples:
- Canonical Contributor license agreement: In this case you have a company that wants to best centralize all ownership to better deal with contribution and licensing problems. You have to TRUST them when you develop code and give to them
- FSF software ownership: In this case, you have a foundation that owns code for best interest of all, the same way they can change licenses whenever they want, it's up to them to ENFORCE GPL on derivated projects that are not compliant with.
Also, it is not uncommon that some companies dual-license its products. Artifex does the same thing with ghostscript
. If you will develop a free software program AND you will not profit from it, you can use the GPL version of ghostscript
. If you want to make proprietary software with ghostscript, you need to pay for a subscription.
And Federal Court decided that using a software that has a license is the same than accepting its terms(enforceable contract).