@@ -175,7 +175,7 @@ <h3>The module layout (confirmed)</h3>
   <li><code>nvidia-drm.ko</code> &mdash; the <strong>DRM/KMS bridge</strong> that registers with and links the <em>same</em> <code>drm.ko</code>/<code>drmn</code> core this plan&rsquo;s <code>IOGraphics.kext</code> provides (<code>MODULE_DEPEND(nvidia_drm, drmn, 2,2,2)</code>). FreeBSD even split the port: <code>x11/nvidia-driver</code> (userland) &rarr; <code>x11/nvidia-kmod</code> (the <code>.ko</code>s) + <code>graphics/nvidia-drm-kmod</code> (the bridge).</li>
 </ul>
 <div class="callout callout-warn">
-<p><span class="pill">Distribution &mdash; same as FreeBSD</span> NVIDIA&rsquo;s driver is redistributable: FreeBSD ships nvidia-driver as binary packages. NextBSD builds the .kos from NVIDIA&rsquo;s tarball like the FreeBSD port and ships the result the same way (carry doc/license.txt, don&rsquo;t sell).</p>
+<p><span class="pill">Distribution &mdash; same as FreeBSD</span> NVIDIA&rsquo;s driver is redistributable: FreeBSD ships <code>nvidia-driver</code>/<code>nvidia-kmod</code> as binary packages under <code>LICENSE_PERMS = dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept</code>. NextBSD builds the three <code>.ko</code>s from NVIDIA&rsquo;s tarball exactly like the FreeBSD port (compile the glue against the local kernel, link the blob, wrap as a kext) and ships the result the same way &mdash; carrying NVIDIA&rsquo;s <code>doc/license.txt</code> and not selling it. Building in a sibling repo vs a job inside <code>nextbsd-graphics</code> is a build-architecture choice, not a licensing one.</p>
 </div>
 <p><strong>One kext per FreeBSD <code>nvidia-kmod*</code> port.</strong> FreeBSD ships the current driver plus five pinned legacy branches; each becomes a kext carrying that branch&rsquo;s <code>.ko</code>s and its own supported-GPU match table. Crucially, the DRM/KMS bridge (<code>graphics/nvidia-drm-612-kmod</code>, pinned to NextBSD&rsquo;s drm&nbsp;6.12 core &mdash; see the note in &sect;5) is packaged <strong>only for the main and 580 branches</strong>; the four older branches are <strong>core / X11-only</strong> (proprietary <code>/dev/nvidia</code> path, no <code>/dev/dri</code>, no Wayland), so only main/580 depend on <code>IOGraphics</code>.</p>
 <table>
@@ -229,7 +229,7 @@ <h2 id="risks">10. Risks &amp; open questions</h2>
   <li><strong>The virtio KPI bridge is the real virtio cost</strong> &mdash; no <code>linuxkpi</code> virtio layer exists; the prototype is against 5.5, doesn&rsquo;t compile, and <code>panic()</code>s on the mandatory <code>reset</code>/<code>del_vqs</code>. Its <code>scatterlist</code>&rarr;<code>sglist</code> conversion and interrupt-context casts are likely buggy under real traffic.</li>
   <li><strong>virtio&rsquo;s match path differs</strong> (sub-bus ivar, not a raw <code>IOPCIDevice</code>), so the <em>cleanest</em> end-to-end CI demonstration is <strong>bochs</strong>, not virtio.</li>
   <li><strong>Aperture/vgaarb handoff</strong> must release the boot framebuffer or every driver fights the console at attach.</li>
-<li><strong>NVIDIA distribution</strong> is not a blocker &mdash; FreeBSD ships nvidia-driver as a binary pkg; NextBSD ships the kext on the same terms.</li>
+  <li><strong>NVIDIA distribution</strong> is not a blocker &mdash; FreeBSD ships <code>nvidia-driver</code> as a binary pkg (<code>LICENSE_PERMS pkg-mirror no-pkg-sell auto-accept</code>); NextBSD ships the kext on the same terms (carry the license file, don&rsquo;t sell).</li>
   <li><strong>vmwgfx <code>page_dirty</code></strong> leans on Linux MM internals <code>linuxkpi</code> doesn&rsquo;t expose; correct (un-stubbed) support may require touching <code>linuxkpi</code> VM-fault handling. <code>kmap_atomic_prot</code> is x86-specific &mdash; an arm64 target needs more.</li>
 </ul>
 <p><strong>Open questions to settle first:</strong></p>