summaryrefslogtreecommitdiffstats
path: root/docs/09-reference/legal-and-licensing.md
diff options
context:
space:
mode:
authorOpen-IOV <dev@open-iov.org>2026-09-23 05:44:08 -0400
committerOpen-IOV <dev@open-iov.org>2026-09-23 05:46:43 -0400
commit68cdd7728a7cc6715bbbff7decfe2b11c3bdf558 (patch)
tree3dc8ce2e6af313a97ec6852f5c663a9a93665d2e /docs/09-reference/legal-and-licensing.md
downloadopen-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.md81
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.