diff options
| author | Open-IOV <dev@open-iov.org> | 2026-09-23 05:44:08 -0400 |
|---|---|---|
| committer | Open-IOV <dev@open-iov.org> | 2026-09-23 05:46:43 -0400 |
| commit | 68cdd7728a7cc6715bbbff7decfe2b11c3bdf558 (patch) | |
| tree | 3dc8ce2e6af313a97ec6852f5c663a9a93665d2e /docs/09-reference/legal-and-licensing.md | |
| download | open-iov-68cdd7728a7cc6715bbbff7decfe2b11c3bdf558.tar.gz open-iov-68cdd7728a7cc6715bbbff7decfe2b11c3bdf558.zip | |
Open-IOV: initial public release
Open-IOV virtualizes NVIDIA GPUs so that unmodified guest drivers run with
real GPU functionality - CUDA first, 3D and video to follow - on unmodified
hosts, without a proprietary vGPU license and without patching any driver,
firmware or hypervisor.
Core principle: emulate the interface, pass through the work.
kernel/ open-iov-vfio.ko - host VFIO mdev driver: virtual GPU device
(PCI config space, BAR shadows, MSI-X), GSP boot emulation,
GSP-RM message-queue/RPC emulation, memory model (GPU-VA to
guest-PA discovery) and the semaphore-completion service that
advances guest UVM progress.
userspace/ libiov.so management API and examples.
tools/ guest diagnostics, firmware analysis wrappers, RM probes.
scripts/ stack manager, VM harness, build/load/test automation.
config/ hardware/version profiles (the portability surface).
docs/ documentation tree - start at docs/README.md.
wiki/ long-form firmware and protocol deep dives.
Status: initialization works end to end for a stock 570.144 Linux guest on
Turing (TU104): driver probe, nvidia-smi, the full GSP-RM control battery,
object creation and the early CUDA/UVM start-up path. GPU work forwarding -
the step that makes CUDA kernels execute on real hardware - is the active
work item; see docs/04-implementation/01-known-knowns-and-unknowns.md.
License: BSD-3-Clause for the project; GPL-2.0 for kernel modules that link
GPL-only kernel interfaces. See LICENSE and docs/09-reference/legal-and-licensing.md.
Diffstat (limited to 'docs/09-reference/legal-and-licensing.md')
| -rw-r--r-- | docs/09-reference/legal-and-licensing.md | 81 |
1 files changed, 81 insertions, 0 deletions
diff --git a/docs/09-reference/legal-and-licensing.md b/docs/09-reference/legal-and-licensing.md new file mode 100644 index 0000000..74f1363 --- /dev/null +++ b/docs/09-reference/legal-and-licensing.md @@ -0,0 +1,81 @@ +# Legal, Licensing, and Third-Party Material + +> What is licensed how, what we may redistribute, and how we stay clean while +> doing adversarial interoperability. + +## 1. The project's licenses + +| Component | License | Rationale | +|---|---|---| +| `kernel/**` (e.g. `open-iov-vfio.ko`) | **GPL-2.0** (`MODULE_LICENSE("GPL v2")`) | The Linux kernel exports the interfaces we need (VFIO, mdev, IOMMU, DMA) under `EXPORT_SYMBOL_GPL`. GPL-2.0 is the legally correct choice. | +| `userspace/**`, `tools/**`, `scripts/**`, `config/**`, `docs/**` | **BSD-3-Clause** | Maximizes reuse and adoption — the project's mission. | +| Third-party submodules and imported trees | their own licenses | Not relicensed; used under their terms. | + +Per-file `SPDX-License-Identifier` headers always govern. + +The split is deliberate: the kernel side gets a clean legal footing; everything +vendor-facing, embeddable and reusable stays permissive. Commercial adoption is +welcome and requires no license fee. + +## 2. How we learn the interfaces + +Open-IOV is built by **reverse engineering and decompilation**: we study the +behaviour of vendor drivers and firmware — in VMs, on hardware, and by +disassembling published firmware images and analysed binaries — and we +reimplement the interfaces we discover. What this project publishes is our +own work: behaviour descriptions, numeric identifiers, layouts, emulation +code, and the evidence behind each observation. + +In this repository you will find: + +* **GSP firmware images** (`firmware/**/*.fwimage.bin`) — fetched from public + distribution channels (e.g. `linux-firmware`); used to understand and + emulate the firmware interface. +* **Decompiled firmware artifacts** (`firmware/**/decompiled/`) — our own + analysis output; kept for study and cited in the wiki. +* **Reformatted interface tables** — IDs, structures and message layouts that + we derived, published in `wiki/` and in this documentation tree. + +**Our rule:** publish *our work product* (facts, layouts, behaviours, code and +evidence). Do not copy third-party source or documentation into this project, +do not point readers at material we cannot redistribute, and do not +redistribute third-party binaries as project content beyond what their terms +allow. + +## 3. Adversarial interoperability and the law + +We implement the *interface contract* so that unmodified NVIDIA software can +talk to our device. We do not: + +* copy NVIDIA driver code into our kernel module, +* patch NVIDIA drivers or firmware, +* defeat licensing for NVIDIA's own products (our device is our device; no + impersonation of a licensed product identity). + +Where interoperability requires knowledge of structures and constants, we +obtain them from publicly distributed headers and from observation of the +unmodified guest in a lab, and we document the evidence. This is the same +discipline used by other interoperable implementations of closed interfaces. + +If you believe a specific artifact in this repository is improperly included, +open an issue: we would rather over-comply than argue. + +## 4. Contributions + +* Inbound = outbound: contributions to BSD-3-Clause files are BSD-3-Clause; + contributions to GPL-2.0 files are GPL-2.0. +* By contributing you confirm you have the right to do so and that the + contribution does not contain third-party material under incompatible terms. +* Write original code. Describe behaviour, cite the evidence, and reimplement + interfaces from observation rather than copying anyone's source. +* Do not commit firmware or ISO images unless they are explicitly permitted and + listed in `.gitattributes`/LFS policy. + +## 5. Export, safety and platform notes + +* GPU firmware and drivers may be subject to export regulations in your + jurisdiction; users are responsible for compliance. +* Security-sensitive deployments should follow the security evaluation doc and + the platform's attestation mechanisms (e.g. TrenchBoot). +* Nothing in this project's licensing changes the licenses of the host + distribution's NVIDIA driver, the guest's driver, or any hypervisor. |
