Carry project memory in the repo, with tools/memory-sync.sh

Claude Code keeps per-project memory at <home>/.claude/projects/<key>/,
where <key> is the project's absolute path with every separator and the
drive colon turned into a dash. That makes it both rename-fragile and
machine-specific, and this project has hit each of those once:

  - D:\DEV\Schunix -> D:\DEV\SchOS changed the key, and 43 memories were
    invisible until moved across by hand.
  - Development happens from Windows and from Linux, and each looks in a
    different place for the same checkout.

Committing .claude/memory/ fixes both -- git carries it across renames
and between hosts -- and `import` puts it wherever the local machine
expects. .claude/settings.local.json stays ignored: those are per-machine
permissions.

The colon maps to a dash rather than being dropped. Deleting it gives
D-DEV-SchOS, which matches nothing and silently finds zero memories; that
was the first attempt. On Git Bash the key comes from `cygpath -w`,
because Claude Code is a Windows program and sees D:\DEV\SchOS, not
/d/DEV/SchOS.

.claude/memory/schunix-licensing.md

@@ -0,0 +1,68 @@
+---
+name: schunix-licensing
+description: "Schunix is Apache-2.0, copyright Nexoniarz; BSD drivers yes, Linux no, and ports/ licences bind regardless"
+metadata: 
+  node_type: memory
+  type: project
+  originSessionId: a665e14b-86bd-4b41-a228-51377f3e9225
+  modified: 2026-08-08T16:18:39.569Z
+---
+
+**`LICENSE` is Apache-2.0**, copyright *Nexoniarz* (not "Schunix Contributors" —
+one author, and a fictional collective makes future re-licensing harder).
+Chosen over MIT/BSD for the express patent grant.
+
+**Settled, do not reopen:** the "Apache-2.0 but shared-source" question was
+discussed at length in 2026-08 and **on 2026-08-08 Nexoniarz asked for it to be
+dropped from the docs entirely** — `docs/licensing.md` is about licensing, not
+about that debate. All references are gone from `docs/`, `LICENSE` and `NOTICE`;
+don't reintroduce them. The substance that survives, in one line inside §1:
+Apache-2.0 §2 is an irrevocable grant, so a restriction stated anywhere else
+does not narrow it, and restricting distribution would be a licence change
+(bespoke proprietary, or BUSL-1.1) rather than a wording change.
+
+The decision that actually mattered to them is **when to publish**, not the
+licence; the standing rule is still never ([[nexoniarz-sharing-preference]]).
+
+**Binding regardless of what they pick:**
+- The kernel derives from xv6 (MIT). `LICENSE.MIT` was *missing* — it was
+  referenced as `bk/LICENSE.MIT` and lost in the `bk/` → `kernel/` migration.
+  Recreated; must not be deleted.
+- `ports/` is other people's code, redistributed in every image: musl (MIT),
+  toybox (0BSD), mksh (MirOS). `NOTICE` carries the attribution musl and mksh
+  require. Patches under `ports/*/patches/` inherit *their* licences.
+
+New first-party files carry `// SPDX-License-Identifier: Apache-2.0`.
+
+**Drivers: BSD yes, Linux no** (asked 2026-08-04, "for drivers we can try get
+it from like Linux?"). Linux is GPL-2.0-**only**, and Apache-2.0's patent and
+indemnity clauses are "further restrictions" under GPLv2 §6 — the two cannot
+be combined and redistributed. Using a Linux driver means relicensing all of
+Schunix to GPLv2 and dropping Apache-2.0; you cannot keep both. FreeBSD /
+NetBSD / OpenBSD are BSD-2/3-clause and **are** compatible: keep the notice,
+add to `NOTICE`, done. Reading Linux to understand hardware is fine;
+translating a driver function-by-function produces a derivative work whatever
+the identifiers say. Best source of all is the public specification — xHCI,
+virtio, AHCI, NVMe, e1000 — which carries no licence on what you write from
+it. Recorded in `docs/roadmap.md` §1. See [[schunix-roadmap-and-projects]].
+
+
+## fs.c is third-party, and was unattributed until 2026-08-09
+
+`kernel/fs/fs.c` (and parts of `tools/mkfs.c`) derive from **"New File System
+For XV6"** by Qi Ma, Leyi Pan, Ao Sun and Peiran Xu -- **MIT License**. Nexoniarz
+mentioned the provenance in passing; the tree had **no attribution at all**,
+only a comment crediting xv6. That was a live compliance gap, since MIT requires
+the notice be retained in substantial portions.
+
+Their work is what the HTree directory index (`BKDRHash`, `HASHRANGE`,
+`OVERFLOW_DIR_START`), the Ext4-style extents (`T_EXTENT`), the inode bitmap and
+`divesymlink` all are. Now credited in `NOTICE` and in fs.c's header.
+
+**The obligation does not go away when fs.c does.** It attaches to every copy
+already made, so the NOTICE entry stays even after the SchFS migration deletes
+the file.
+
+**The general lesson:** ask where code came from before assuming it is
+first-party. "It is in our tree and looks like xv6" was wrong here, and the only
+reason it surfaced was an offhand remark.