Instead, IT banned it enterprise-wide. Which is sad, because we like it for Vagrant. We've since started moving all of our developer stuff to OpenShift, so we're not totally up a creek.
Early 2016: https://web.archive.org/web/20160411070811/https://www.virtu... Late 2016: https://web.archive.org/web/20161208112443/https://www.virtu... Current, last changed July 2017: https://www.virtualbox.org/wiki/VirtualBox_PUEL
In the earlier licenses, "personal use" was just defined as the person using it being the same person as who installed it, and only one person remotely accessing the desktop at a time. So I had interpreted this as being OK for developer VMs in which the developer installs it themselves and uses it for their own development purposes. It also contained an "evaluation use" with a vaguely defined period.
The current license now defines "personal use" as explicitly non-commercial use, and adds more restrictions on client access that applies to any type of clients and not just remote desktop access, as well as explicitly defining the evaluation use period to being 30 days.
So while I didn't really have a concern about developers using VirtualBox with the extension pack previously, given the new license and the fact that they seem to be enforcing it via phoning home, it looks like it's time to set a policy of no one using it.
Luckily, we've already pretty much transitioned everything over to libvirt/KVM on Linux hosts, and people have generally been using VMWare or VMWare Fusion on Windows and Mac hosts.
Of course others are right, virt-manager is probably a better replacement I think.
You can spin up KVMs in OpenShift, but I have the feeling it's not going to be quite what you're looking for. I suppose it's all going to be a matter of what workflow is most comfortable for your devops people. If you have an OpenStack install, Vagrant can control those AND they can login and poke around.
Also FYI virt-manager is deprecated in RHEL 8, and is superceded by Cockpit.