VirtualBox Extension Pack do not use requireFile (to prevent PUEL violations) anymore

[bbenoist]

I cannot run any of my virtual machines under the virtualbox version 4.2.14 updated yesterday by the commit 6c86398. This occurs even after discarding eventual savestates.

Error message:

Failed to open a session for the virtual machine myvm.
Failed to load VMMR0.r0 (VERR_SYMBOL_NOT_FOUND).

Details:

Result Code: NS_ERROR_FAILURE (0x80004005)
Component: Console
Interface: IConsole {db7ab4ca-2a3f-4183-9243-c1208da92392}

Everything is working fine if I revert this commit and switch back to the version 4.2.12.

Did you someone ever had such an issue after upgrading virtualbox ?

[domenkozar]

@viric @bjornfor

[bbenoist]

OK, everything is now working fine after a reboot.
I may have been due to a kernel upgrade since my last reboot, sorry for the annoyance 😕

By speaking about the commit 6c86398, and the remark by @vcunat:

I saw no reason to use requireFile, it seems normally downloadable.

The reason of the requireFile is that the virtualbox extension pack is licensed under a specific license which restricts its use to evaluation and personal use (see https://www.virtualbox.org/wiki/VirtualBox_PUEL for details).

In summary, the VirtualBox PUEL allows you to use VirtualBox free of charge:
* for personal use or, alternatively,
* for product evaluation.
In addition, academic use of VirtualBox is also permitted free of charge by the PUEL.

The requireFile is here to force the user be be aware of these restrictions (or at least to take him to the page where the license is mentioned) by manually going to the website. By removing it, there is no more prevention of potential violations of the PUEL.

Is there a way to force a user to accept a license in NixOS ? If yes, it may be an alternative and compliant solution.

[bbenoist]

I have updated the subject in order to be consistent with my latest posts...

[vcunat]

@bbenoist: thanks for clarifying. At the very least we should modify the license when using extensions (probably "unfree-redistributable"?).

I don't understand law at all (moreover, IMO it gets complicated in international setting like here). Certainly feel free to change it (but leave a comment there why it's so, please).

[aszlig]

I've noted this in 5a3f9c0 already, but maybe we should add a message attribute to requireFile so everyone is clear on the reasons behind this.

And I'm not a lawyer as well, which is why I used requireFile as i wasn't sure whether it is redistributable.

[vcunat]

Ah, I didn't read logs. It should be redistributable, IMO the only question is make user "accept EULA". I don't know... but we also don't print the GPL and others when installing packages (maybe they are less restrictive, but still).

[bbenoist]

@vcunat: No problem, as I also asked myself the same question when installing it the first time and had an answer, it seemed natural to relay you this answer.

I am too not a lawyer but have to take care of such weird licence-related issues as I am using it in a company...

Anyway, such reads can be quite funny when finding such clauses (from the PUEL):

The Product is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility and Oracle and its licensors disclaim any express or implied warranty of fitness for such uses. 

More seriously, the PUEL (available at https://www.virtualbox.org/wiki/VirtualBox_PUEL ) stipulates that:

This license applies if you download the full VirtualBox binaries from the Downloads page. 

Which seems to be meaning that the only way to be compliant to the license is not only to accept its license but that any end-user downloads the binaries from the official "Downloads page".

Also, on a different side of the problem, the licensing FAQ (available at https://www.virtualbox.org/wiki/Licensing_FAQ) contains this Q/A:

> Can I redistribute the VirtualBox extension pack?  
No. The Personal Use and Evaluation License allows you to download the VirtualBox extension pack binaries for personal and academic use and for evaluation, but it does not give you the right to redistribute these binaries.
So you may not put them onto your own websites or other mirrors. We do this because we would presently like to keep track of how many people are downloading these binaries.  

Which means that the derivation containing the extension pack can not be distributed through a nix channel because of containing binaries licensed under the PUEL.

From what I have understood of the problem, the only solution to use in order to be compliant is to force the end-user to download it from the "Downloads page" of virtualbox.org. As the license does not clearly stipulates if the thing can be done manually or automatically, I see here two possible solutions:

• The ambiguous but automatic one: Find a way to fetch the download page ( https://www.virtualbox.org/wiki/Downloads ), extract the related URL and download the binaries on each end-user system.
• The approved one: Use requireFile if it really prompts at the end-user installation step and prevents the binaries to be present on a nix channel (I am not sure about these).

Following my habits of "searching how issue X has been handled in Arch ™ ", it seems that their point of view is to let its users download it by themselves: https://wiki.archlinux.org/index.php/VirtualBox_Extras#Extension_pack
Their last alternative (the AUR one available at https://aur.archlinux.org/packages/virtualbox-ext-oracle/ ) seems to require a PUEL file to be present but is not officially approved by Arch's maintainers.

I must say that such licensing restrictions are IMO a loss of time for its end users, but we unfortunately do not have the choice to comply with.

[vcunat]

OK, so this way? vcunat@05cfc11 I tested that nix finds the file if one runs the command as the message suggests.

[aszlig]

LGTM 👍

edit: However I'd word it like this:

      In order to use the extension pack, you need to comply with the VirtualBox
      Personal Use and Evaluation License (PUEL).

      Please be sure to head over to:

      http://www.virtualbox.org/wiki/VirtualBox_PUEL 

      Once you've read and understand the terms and conditions, you can proceed
      by invoking the following command:

      nix-prefetch-url "${url}"

(I'm not a native speaker either, but it probably isn't as terse as your version)

[bbenoist]

Not really. According to what I have previously quoted, any end-user must download the binaries from the Downloads page:

This license applies if you download the full VirtualBox binaries from the Downloads page. 

By using nix-prefetch-url, you still not respect literally the license because the end users will not have to go to the page: nix-prefetch-url is directly using the binary download url.

As I agree that this rule seems to be nonsense, we must respect their conditions whatever useless they are.

Even if counting downloads directly on the downloaded file rather than passing through a dedicated page is technically possible, this does not mean that virtualbox.org is counting this way...
They did mentioned a download count reason in the FAQ which may be true:

We do this because we would presently like to keep track of how many people are downloading these binaries.

In summary, you must use the "ambiguous" solution which is automatic but potentially buggy (depends of a dynamic page) or ask the user to go to the download page and find the URL or dowload the file by himself.
As I would prefer to rely on a reliable solution, the last proposal (asking the user) is the only correct one.

So, to my mind, the message should be:

In order to use the extension pack, you need to comply with the VirtualBox Personal Use and Evaluation License (PUEL) by downloading the related binaries (version ${version}) from:
https://www.virtualbox.org/wiki/Downloads

Once you have downloaded the file, please use the following command and re-run the installation:

nix-prefetch-url file://${filename}

with only using a filename variable in the nix-prefetch-url instead of url.

My side would have added this:

The correct download URL should be:
 ${url}

but I fear misinterpretations 😨

It would be nice to have a method to quantify the total number of hours lost in the world by such licensing restrictions, maybe this would help lawyers to make some more realistic and user-friendly licenses 😡

There even exists some US restriction preventing some software to be used in certain people resigin in countries listed in the US OFAC such as Cuba, Iran, North Korea, Sudan, and Syria which has several issues (see http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/ for an example with sourceforge)... 😵

[bbenoist]

The commit bbenoist@9be289d is compliant with my POV.

[vcunat]

I see, feel free to push it (extpackRevision is redundant, but it doesn't matter).

[bbenoist]

@vcunat OK, I will do it.
The extpack revision is used to version binary builds as their result may differ in function of the state of the system on which it has been built.
Per example, if virtualbox releases the extension pack of the 4.2.14 version with buggy dependencies which are statically linked, they will have to release a new build which did not changed any source at all but needs to distinguished of the previous one by some sort of versionning (it seems to be the build number of their CI bot).
I referenced it because this is the name of the file when downloaded from the official page. Also, if virtualbox releases a new build of the same version, the other link/filename would result to a wrong checksum.

[domenkozar]

Closing, continue discussion in pull requests #675