#7 Updated by adrelanos 2015-10-18 15:25:57

What about licensing? In Debian jessie, VirtualBox unfortunately moved from main to contrib.

https://packages.debian.org/jessie/virtualbox

Do you have a policy at Tails about including non-free packages?

#8 Updated by intrigeri 2015-10-23 08:31:05

> Do you have a policy at Tails about including non-free packages?

Yes: https://tails.boum.org/doc/about/license/

#9 Updated by hybridwipe 2015-10-23 10:25:56

FYI, the reason VirtualBox was moved was because the compiler used to build the BIOS for VirtualBox is non-free.

Essentially, VirtualBox is in a similar position as Firefox on Windows. The underlying code and libraries are Free Software, but a non-free compiler/tool is needed to make it usable. Does that make Firefox on Windows non-free software? That depends on who you ask :).

However, as intrigeri referenced in Tails’ license statement, Tails uses free software (and some non-free firmware to improve hardware compatibility). I’d say that VirtualBox’s non-free BIOS would be analogous to non-free firmware.

#10 Updated by intrigeri 2015-10-23 11:32:43

> However, as intrigeri referenced in Tails’ license statement, Tails uses free software (and some non-free firmware to improve hardware compatibility). I’d say that VirtualBox’s non-free BIOS would be analogous to non-free firmware.

The hardware compatibility argument works for stuff that improves running Tails inside VirtualBox: in some situations that’s the only way one can use Tails. But IMO it doesn’t work that well for a BIOS that allows running arbitrary OS’es inside Tails.

This being said, even though I disagree with this specific argument, I’m undecided on the broader license policy issue.

#12 Updated by hybridwipe 2016-02-16 01:25:49

So I played with this a bit more today on 2.0.1. Potential license issues aside, there’s a larger technical problem:
https://www.virtualbox.org/ticket/8336

to demonstrate:
boot tails on recent (i.e. 64-bit capable) hardware, and enable a root password
$ sudo su -

1. apt-get update && apt-get -y install linux-headers-amd64 virtualbox-qt
2. Virtualbox

the GUI will start, configure a vm named foo and accept all defaults. Try to start it, which will fail, saying the kernel modules aren’t loaded or don’t match.

If, however, you force a 32-bit kernel to load (see Bug #11129) by hitting ESC in the tails boot menu, then typing ‘menu_486’, and booting, then follow those instructions (use linux-headers-586 instead), the VM will start.

As it currently stands, for Virtualbox to work on Tails, either we could only support 32-bit kernels (easiest), we’d need two userlands (64-bit and 32-bit) (more work, but arguably the most complete solution, at the cost of increased disk space/complexity), or switch completely to 64-bit (less compatibility for some users, but do we know how many?)…or get Virtualbox to fix their 32/64-bit mismatches. There’s a patch we could test there, but I don’t think we want to fork Virtualbox or use that incomplete/unaudited patch.

#14 Updated by sajolida 2016-02-17 12:39:09

See Feature #8183 for plans to drop 32-bit: we’re not there yet but almost :)

#15 Updated by hybridwipe 2016-02-17 15:14:03

sajolida wrote:
> See Feature #8183 for plans to drop 32-bit: we’re not there yet but almost :)

Ah, cool, thanks for the link.

#18 Updated by intrigeri 2018-05-26 09:45:37

Besides, given how hard it is to maintain VirtualBox guest support (see Bug #12048 and the related tickets) I’m not eager to commit to maintain host support as well.

Also, AFAIK basically no user ever requests this feature.

Dear ticket triager, if you agree let’s reject this ticket during your next triaging session.