# VirtualBox: general-purpose full virtualization, and the kBuild tree behind it > The VirtualBox source tree is a C and C++ codebase built by a custom kBuild system with three platform configure scripts, licensed GPL-3.0 with separate CDDL and LGPL files for the parts of the tree that carry other terms. **VirtualBox/virtualbox** — Source code for Oracle VirtualBox - Repository: https://github.com/VirtualBox/virtualbox - Website: https://www.virtualbox.org/ - Stars: 1,453 · Forks: 230 - Language: C - License: GPL-3.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/virtualbox-virtualbox ## What VirtualBox is, and the scope of the claim VirtualBox is general-purpose full virtualization software for x86_64 hardware, with version 7.1 additionally for macOS and Arm, and it is targeted at laptop, desktop, server and embedded use. The four target categories are worth reading carefully, because they set the expectations. Desktop and laptop use is the familiar one, where VirtualBox runs a guest operating system alongside the host for testing. Server use means it runs the hypervisor on a machine with no desktop. Embedded use means it runs on a device with a very small footprint. And the note about x86_64 hardware with version 7.1 adding macOS and Arm says the guest architecture is not the same thing as the host architecture, which is why the repository topics include emulation and virtualization as separate concerns. The product description emphasises two things: a very user friendly graphical user interface, and availability for many popular operating systems, Linux, Windows, macOS and Solaris. The stated strong points are flexible networking setup and interactive performance. The audience line is unusually direct about who this is for. Anyone with the need to run multiple operating systems simultaneously with some basic knowledge about PCs and operating system installation can use it to reduce effort with a large number of tasks including software testing. So the intended user is a person who needs to run more than one operating system at once and does not want to learn a hypervisor to do it. That framing is also why the source repository exists in this shape, since the source of a product with that framing has to be buildable by people who are not the original team. ## Why the build is not a normal configure and make The README is blunt about the build. VirtualBox is a complex product with multiple dependencies, some of them specific to the operating system on which you want to run it, and the basics for building it are described on the build instructions page on the project wiki rather than in the repository. The repository layout explains why. There is no Makefile in the conventional sense. There is Makefile.kmk, Config.kmk, Maintenance.kmk and Version.kmk, which are the inputs to a custom build system called kBuild, and the kBuild/ directory holds that system. On top of it sit three configure scripts, configure.py for the Unix-like hosts, configure.vbs and configure.ps1 for the Windows hosts, and a configure shell script that dispatches to the right one. That is a deliberate choice for a product that has to build on four host operating systems with different toolchains, and it has consequences for a contributor. You do not run make and get a binary. You run a configure step that probes the host, generates the build configuration, and then drive kBuild. The Makefile.kmk files then carry the actual build rules. The other top level entries describe the shape of the product. The src/ directory is the source, include/ is the public headers, tools/ holds the host-side command line and GUI utilities, webtools/ is the web interface, and doc/ holds documentation with a Doxyfile.Core for the API docs. The debian/ directory is the Debian packaging, and there is a .gitmodules file, so parts of the tree come from elsewhere. The .scm-settings and .dir-locals.el files are editor and source-control configuration, and AGENTS.md and CONTRIBUTING.md are the contribution instructions. For a first build the practical advice is to start at the wiki page rather than in the tree, because the tree encodes the build system rather than explaining it. ## The licensing, which is three files and a header format The licence section of the README is unusually precise, and it is worth reproducing because the rules are easy to get wrong. The project is under the GNU General Public License version 3.0, and the README states that the released licence is shown at COPYING, which contains clarifications regarding allowed licenses for other code using parts of the project which are covered by multiple licenses. The repository also carries COPYING.CDDL and COPYING.LIB, which is how a tree that includes code under other terms keeps them straight. Then there is the required header format, and it is stricter than most projects ask for. The correct copyright notice format for both documentation and software is: ``` Copyright (C) [year-]year Oracle and/or its affiliates. This file is part of VirtualBox base platform packages, as available from https://www.virtualbox.org. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, in version 3 of the License. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, see . ``` The rule that catches contributors is the year. You must include the year the content was first released, on any platform, and the most recent year in which it was revised. So a file created in one year and revised in a later year carries both years, which is why the format is written as [year-]year with the square brackets marking the optional first year. The README's own example is the 2025 form, Copyright (C) 2025 Oracle and/or its affiliates. There is also a THIRD_PARTY_LICENSES.txt at the root, which is the record of the code that came from elsewhere, and the COPYING files sit next to it for the same reason. For anyone vendoring VirtualBox into a product, that set of files is where the obligations live, and it is worth reading before assuming the GPL-3.0 on the tree is the only thing that applies. ## Where the documentation lives, and how to get help The README is deliberately a signpost rather than a manual, and the signposts are worth listing because the split tells you what kind of question you are asking. For users, the VirtualBox User Guide contains all information relevant for users, including the product features and their configuration. That is the document to read for anything about how the product behaves. For developers, the recommendation is to start with the technical documentation, which contains links to a broad collection of pages related to development, covering many aspects of the project and its features. The build instructions page covers the build, and the two are different documents with different audiences. There are two tutorials linked as examples: Learn to Install Oracle VirtualBox and Run Virtual Machines, and Use Oracle VirtualBox on Oracle Linux, the second one showing the product on a server distribution rather than a workstation. For help, there are three separate paths, and the distinction between them matters. Oracle customers with a support contract covering VirtualBox should reach out to Oracle Support. Everyone can use the VirtualBox Forums for questions about the product or discussing its functionality. And an issue should be opened on GitHub for bug reports or requests for enhancements. Security vulnerabilities have their own route, and the README points at a reporting guide for that, with the SECURITY.md file in the repository covering the responsible disclosure process. Contributions are welcome, and the instruction before submitting a pull request is to review the contribution guide in the repository. One thing the README does not do is list release versions, and the repository has no published GitHub releases. The source is tracked on the default branch, main, with the last push on 2026-10-14, and the product versioning lives in the release artifacts rather than in tags on this repository. ## What this repository is and is not The first limitation is scale. The primary language is C, with C++ alongside it, and the tree is large enough that the build system exists to manage it. This is not a codebase you read to understand VirtualBox, it is a codebase you compile, and the wiki pages assume you already have a working build before the technical documentation becomes useful. The second limitation is the host dependency story. The README says explicitly that VirtualBox is a complex product with multiple dependencies, some of them specific to the operating system on which you want to run it. Building on macOS means a different set of host SDKs than building on Linux, and the configure step for each platform exists precisely because the differences are not cosmetic. The third limitation is the licensing boundary for distributors. A GPL-3.0 tree with CDDL and LGPL components in it, and a third-party licence file, is a codebase where the compliance work is proportional to the size of the product. The README gives the header format precisely because the project expects contributions from many people, and the same precision applies to anyone who redistributes it. The fourth limitation is that this is the source and not the product. There is no binary in the repository, no release artifact, and no package index. The README links to the project site and the User Guide for the product itself, and the tutorial links show the installation path a user actually takes. What the repository does give you is something specific and valuable: a hypervisor implementation that runs the same guest on four host operating systems, from a laptop to an embedded device, with the source, the build system, the developer documentation and the contribution process all in one place. That combination is why the tree is worth reading even for people who never compile it. ## Conclusion This repository fits a developer who wants to work on a hypervisor that runs on a laptop, a server and inside an embedded device, and a packager who needs to rebuild VirtualBox against a specific host SDK. It is a poor fit for a team that just wants a virtual machine manager, since the binaries are the product and the source is a large C and C++ tree with platform-specific dependencies, and a poor fit for a small experiment because the build is not self-contained. Before you start, read the build instructions page, because the basics of building VirtualBox live there rather than in the repository, and check the licensing situation in the COPYING files, since the GPL-3.0 for the tree sits alongside a CDDL file and an LGPL file for the parts that carry other terms. ## FAQ ### What is Oracle VirtualBox and who is it for? VirtualBox is general-purpose full virtualization software for x86_64 hardware, with version 7.1 additionally for macOS and Arm, targeted at laptop, desktop, server and embedded use. The README says anyone who needs to run multiple operating systems simultaneously with some basic knowledge about PCs and operating system installation can use it to reduce effort on tasks including software testing. ### How do I build VirtualBox from source? The basics are described on the build instructions page on the project wiki rather than in the repository. The tree uses a custom build system, kBuild, driven by Makefile.kmk, Config.kmk, Maintenance.kmk and Version.kmk, with configure.py for Unix-like hosts and configure.vbs and configure.ps1 for Windows, and the project warns that VirtualBox has multiple dependencies, some specific to the host operating system. ### What licence is the VirtualBox source under? The GNU General Public License version 3.0, released under the terms shown at COPYING, which also contains clarifications regarding allowed licenses for other code using parts of the project covered by multiple licenses. The repository additionally carries COPYING.CDDL, COPYING.LIB and THIRD_PARTY_LICENSES.txt for the parts of the tree under other terms. ### What copyright header does the VirtualBox project require in new files? The format is Copyright (C) [year-]year Oracle and/or its affiliates, followed by the GPL-3.0 notice and the instruction to include the year the content was first released on any platform and the most recent year in which it was revised. ### Where should I report a VirtualBox bug or a security issue? Bug reports and enhancement requests go to GitHub issues, general questions and product discussion go to the VirtualBox Forums, and Oracle customers with a support contract should use Oracle Support. Security vulnerabilities have a separate route through the Reporting Vulnerabilities Guide, with the process described in SECURITY.md in the repository. ## Sources - [Issues](https://github.com/VirtualBox/virtualbox/issues) - [License: GPL-3.0](https://github.com/VirtualBox/virtualbox/blob/main/LICENSE) - [Project website](https://www.virtualbox.org/) - [README](https://github.com/VirtualBox/virtualbox/blob/main/README.md) - [VirtualBox/virtualbox on GitHub](https://github.com/VirtualBox/virtualbox) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/virtualbox-virtualbox