API Licensing

[tolmasky]

Apologies if there is somewhere that makes this clear, but I am not sure what licensing applies when making use of the API. The SDK itself does not seem to clearly list a license anywhere, and I don't know how licenses are treated when you are interacting with things through XPCOM. Additionally, for example, the docs state "The sample code files shipped with the SDK are generally licensed liberally to make it easy for anyone to use this code for their own application code." However, the samples themselves seem to all actually be GPLv2 meaning the samples can't really be used without licensing considerations.

[Perryg]

Licensing issue should be addressed at Oracle.

[klaus]

The general VirtualBox sources are covered by GPLv2, and as you observed this generally includes the sample code. We have no intentions going after code which uses the samples as inspiration (copying significant portions of the code is as usual a different story), because that's what the intention behind having the samples.

The actual headers/jar files etc. in the SDK which you need to use for creating yout own API client are covered by different, more liberal licenses - generally LGPLv2.1, and we consider the SDK header files to be free of code (this avoids certain difficulties with LGPL, as code from header files would otherwise "pollute" your binaries). The aim is to leave you free choice for licensing your application. We encourage going open source, but you can also elect any other license.

If you find any files in the SDK (besides sample code) which mention a too strict license, please name them and we'll look into resolving this as soon as possible.

[pwnall]

Some header files have a nice MIT license notice right at the top, e.g. bindings/c/glue/VBoxCAPIGlue.{c,h}

The main header files, e.g. bindings/c/include/VBoxCAPI_v4_3.h have an explicit LGPL v2 license at the top. That seems to suggest that the authors explicitly intended headers to be covered by the LGPL v2. If you don't consider the headers code, perhaps consider re-labeling them with the MIT license?

[klaus]

Can you say what actual problem you have with the VBoxCAPI_*.h files covered by LGPL? They don't contain any traces of what anyone could consider code which would trigger the annoying re-linking clause which is to our knowledge the biggest issue (and thus out of the way). As the comment mentions, we clarified the licensing of the file (which is derived from code developed by the Mozilla project), and we can't slap a totally different license on it without getting this nodded off by the Mozilla project. That's a nightmare for us and them, because such fundamental licensing changes strictly speaking needs explicit approval of each and every contributor who touched the relevant code in the past.

The VBoxCAPIGlue.* files are different. They're fully developed by us. For the header file LGPL would be again no problem (no code in it), but of course we considered the consequences of the licensing of the C part, which is meant to be statically linked with 3rd party code, and there it's obvious that LGPL would be a problem.

[pwnall]

Thank you very much for getting back to me so quickly!

Personally, I'm fine with LGPL v2.

I brought this up because I wrote Go bindings [1] for the XPCOM API, and I felt that I had to put in a big warning about the license.

Go statically links everything, so LGPL tends to be a nightmare for it. In pretty much any other language, I'd have made my binding a dynamically loaded library, and kept LGPL away from trouble.

I thought the header VBoxCAPI_*.h files are auto-generated from the .idl files. As far as I know, LGPL (and even GPL) don't infect program output, so one could modify the (L)GPL-ed generator to remove the generated header, publish the generator modifications, and not have the LGPL text slapped to the output. If the files are written by hand, I don't think it's worth bothering to remove the LGPL.

[1] I can't post URLs, but the bindings are on GitHub under pwnall/vbox. There's a copyright/licensing section in the README.
FWIW, the bug that led me to believe the files are auto-generated is filed as ticket/14149

[klaus]

The biggest part of VBoxCAPI_*.h is auto-generated, but there are non-negligible portions taken from various XPCOM header files (included as fixed text in the generator, "tainting" the generator output). That's why we can't change the license easily (derived work).

Definitely not necessary to put a big warning on anything using the C API binding, because the glue part is trouble-free, and VBoxCAPI_*.h is really not containing any code which would make trouble. Might be worth mentioning it in some internal documentation aimed at developers so that they're aware of this.

[pwnall]

Thank you for explaining! I'll link to this thread in the README.