docs: document libowfat hard dependency policy

AI.md

@@ -1300,4 +1300,29 @@ Next patch number should be `0253`.
   `include/<module>/*.h`, then move smaller modules such as `nwdirectory` before
   splitting very large files such as `nwconn.c` and `nwbind.c`.
 
-Next patch number should be `0262`.
+## 2026-06-02 - Patch 0262 libowfat hard dependency policy
+
+- Reviewed the uploaded `libowfat-0.34.tar.xz` archive as the dependency used
+  by tinyldap-style code.  Its README states that libowfat provides general
+  purpose APIs extracted from Dan Bernstein's software and reimplemented under
+  GNU GPL version 2 only, with no later-version grant.
+- Treat libowfat as a planned hard third-party dependency for the
+  tinyldap-derived `mars-tinyldap`/`nwdirectory` work, similar to how yyjson is
+  a required bundled dependency for salvage metadata.
+- The planned import path is `third_party/libowfat`.  Do not keep it merely as a
+  reference archive and do not place it at the repository root.
+- The pinned initial source should be libowfat 0.34 unless a later explicit
+  dependency bump patch chooses a different version.  The import must carry a
+  mars-nwe note documenting source/version, GPL-2.0-only license, local CMake
+  changes, and how `mars-tinyldap`/`nwdirectory` links it.
+- The first integration should expose a normal CMake target, for example
+  `OWFAT::owfat`, and should be usable from both standalone `mars-tinyldap` and
+  the mars-nwe superbuild.  Do not wrap libowfat's original Makefile as the
+  long-term build path.
+- Scope the direct libowfat dependency to the tinyldap-derived directory-service
+  build and any small compatibility facade needed for it.  Do not start using
+  libowfat APIs throughout unrelated `nwconn`, `nwbind`, or endpoint/provider
+  code merely because the library is bundled.
+- Keep GPLv3 code out of this dependency path.
+
+Next patch number should be `0263`.

REDESIGN.md

@@ -1530,6 +1530,11 @@ third_party/wolfssl
   fixed TLS dependency used by mars-nwe TLS code
   configured through CMake for the server's supported platforms and features
 
+third_party/libowfat
+  planned fixed hard dependency for the tinyldap-derived nwdirectory work
+  imported from libowfat 0.34 unless a later dependency bump says otherwise
+  GPL-2.0-only; exposed through a CMake target such as OWFAT::owfat
+
 third_party/libflaim
   planned fixed directory storage engine used through libdirectory
   mars-nwe-maintained import/fork of the FLAIM source
@@ -1546,6 +1551,55 @@ mars-tinyldap/
   later wired to libdirectory/libflaim instead of tinyldap's original flat files
 ```
 
+### libowfat dependency rule
+
+`libowfat` should be a hard bundled dependency for the tinyldap-derived
+`mars-tinyldap`/`nwdirectory` work, not merely a reference archive.  It belongs
+under `third_party/libowfat` and should be handled like a fixed third-party
+building block, similar to yyjson for salvage metadata.
+
+The reviewed source is `libowfat-0.34.tar.xz`.  Its README describes libowfat as
+a library of general-purpose APIs extracted from Dan Bernstein's software,
+reimplemented under GNU GPL Version 2 with no later-version grant.  The initial
+import should therefore document `libowfat 0.34` and `GPL-2.0-only` explicitly in
+`third_party/libowfat/README.mars-nwe.md`.
+
+The CMake integration should not simply shell out to libowfat's original
+Makefile.  It should expose a normal target usable by both standalone
+`mars-tinyldap` and the mars-nwe superbuild, for example:
+
+```text
+standalone:
+  cmake -S third_party/libowfat -B build-libowfat
+
+inside mars-nwe:
+  add_subdirectory(third_party/libowfat)
+  target_link_libraries(nwdirectory PRIVATE OWFAT::owfat)
+```
+
+The expected target name is:
+
+```text
+OWFAT::owfat
+```
+
+The tinyldap-derived code may depend on libowfat directly where that matches the
+upstream programming model.  Broader mars-nwe endpoint/provider code should not
+start including libowfat headers directly just because it is present in the tree.
+If common mars-nwe code needs similar helpers later, add an explicit mars-nwe
+facade or small local helper rather than leaking the tinyldap compatibility
+library through `nwconn`, `nwbind`, or future provider boundaries.
+
+Areas of libowfat likely relevant to tinyldap include `byte`, `buffer`, `fmt`,
+`scan`, `str`, `stralloc`, `uint`, `open`, `socket`, and possibly `io` or `cdb`.
+Keep the first import focused on the parts required to build the tinyldap-derived
+LDAP service; optional tools/tests/manpage installation can remain disabled until
+there is a concrete maintenance need.
+
+Do not introduce GPLv3 code into this dependency path.  If a later libowfat bump
+or replacement is considered, review the license and make that a separate
+third-party update patch.
+
 ### TLS dependency rule
 
 wolfSSL should be the fixed TLS implementation shipped with the tree, similar in
@@ -1733,9 +1787,11 @@ ASN.1 helpers, LDAP encode/decode helpers, LDIF parsing, auth helpers, a storage
 archive, a tiny TLS archive, `tinyldap`, `tinyldap_standalone`, debug/test
 programs, index tools, ACL tools, an LDAP client, and conversion utilities.  It
 also expects libowfat-style headers/libraries and, when not using the old dietlibc
-path, links OpenSSL/crypt-style libraries for some helper code.  The CMake
-conversion should inventory those groups explicitly instead of copying the old
-`all` target wholesale.
+path, links OpenSSL/crypt-style libraries for some helper code.  For the
+mars-nwe integration, that libowfat expectation is intentional: `libowfat` is a
+hard bundled dependency under `third_party/libowfat`, exposed as `OWFAT::owfat`.
+The CMake conversion should inventory those groups explicitly instead of copying
+the old `all` target wholesale.
 
 A reasonable first CMake split is:
 

TODO.md

@@ -174,6 +174,30 @@ Current status:
   `case 0x17`; SDK group `0x2222/123` is top-level wire `case 0x7b`.
 
 
+#### libowfat hard dependency for tinyldap/nwdirectory
+
+Current status:
+
+- Patch `0262` records libowfat as a planned hard third-party dependency for the
+  tinyldap-derived `mars-tinyldap` / `nwdirectory` work.
+- The reviewed archive is `libowfat-0.34.tar.xz`; its README states that the
+  library is GPL Version 2 with no later-version grant.
+- The import path should be `third_party/libowfat`, with a normal CMake target
+  such as `OWFAT::owfat`.  Treat it like yyjson: bundled and required for the
+  feature that uses it, not an optional system probe and not only a reference
+  note.
+
+Follow-up:
+
+- Import/pin libowfat under `third_party/libowfat` in its own dependency patch.
+- Add `third_party/libowfat/README.mars-nwe.md` documenting source/version,
+  GPL-2.0-only license, local CMake changes, and consumers.
+- Provide a real CMake build exposing `OWFAT::owfat`; do not keep the original
+  Makefile as the long-term mars-nwe build path.
+- Wire the tinyldap-derived standalone and mars-nwe `nwdirectory` builds to that
+  target.  Keep direct libowfat usage scoped to the tinyldap compatibility layer
+  and do not spread it through unrelated NCP endpoint/provider code.
+
 #### Source/header subtree layout migration
 
 Current status:

third_party/README.md

@@ -22,6 +22,37 @@ support stay enabled; yyjson tests, fuzzer, misc tools, docs, install targets,
 JSON5/non-standard support, utilities and incremental reader support are disabled
 for the mars-nwe build.
 
+## Planned: libowfat
+
+libowfat is the planned hard bundled dependency for the tinyldap-derived
+`mars-tinyldap` / `nwdirectory` work.  It should live under
+`third_party/libowfat`, not at the repository root, and should be treated as a
+fixed third-party building block in the same sense as yyjson is fixed for
+salvage metadata.
+
+The reviewed archive is `libowfat-0.34.tar.xz`.  Its README describes libowfat
+as general-purpose APIs extracted from Dan Bernstein-style software and
+reimplemented under GNU GPL Version 2 with no later-version grant.  Record that
+GPL-2.0-only license and the exact source/version in
+`third_party/libowfat/README.mars-nwe.md` when the dependency is imported.
+
+The first mars-nwe integration should provide a real CMake target, for example:
+
+```text
+OWFAT::owfat
+```
+
+Do not rely on libowfat's original Makefile as the long-term build path.  The
+CMake import should be usable by both the standalone tinyldap-derived build and
+the mars-nwe superbuild.  The direct dependency should remain scoped to the
+`mars-tinyldap`/`nwdirectory` compatibility code and any small wrapper needed for
+that integration; unrelated NCP endpoint/provider code should not start
+including libowfat headers directly just because the library is bundled.
+
+Relevant libowfat areas for tinyldap are expected to include `byte`, `buffer`,
+`fmt`, `scan`, `str`, `stralloc`, `uint`, `open`, `socket`, and possibly `io` or
+`cdb`, depending on how much of the original tinyldap code is kept.
+
 ## Planned: wolfSSL
 
 wolfSSL is the planned fixed TLS implementation for mars-nwe.  It should be