3182da3965
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.
3.6 KiB
| name | description | metadata | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| schunix-licensing | Schunix is Apache-2.0, copyright Nexoniarz; BSD drivers yes, Linux no, and ports/ licences bind regardless |
|
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.MITwas missing — it was referenced asbk/LICENSE.MITand lost in thebk/→kernel/migration. Recreated; must not be deleted. ports/is other people's code, redistributed in every image: musl (MIT), toybox (0BSD), mksh (MirOS).NOTICEcarries the attribution musl and mksh require. Patches underports/*/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.