glm-5.3-flash
a3cdef909b
- Cargo workspace with 5 sub-crates: alkgit-core (storage), alkgit-transport (smart protocol), alkgit-http, alkgit-ssh, alkgitd (binary); sha1 pinned through the gix stack, sha256 passthrough feature - docs/research/: vision, gitoxide alignment, alk stack fit, server-side protocol inventory, license/reference policy, POC plan - AGENTS.md: conventions mirroring alkcall (no comments, thiserror, tokio, no secrets on wire/at rest, visible-surface=authorized-surface, gitoxide-only serving path, bounded resources, registry-resolved repos) Verified: cargo build, clippy -D warnings, fmt, test, check --all-features
3.3 KiB
Research: reference projects, licenses, and reuse policy
Status: complete Date: 2026-09-19
TL;DR
gitoxide (MIT OR Apache-2.0) is a dependency and a readable reference — clean.
One similar Rust git server exists (gitserver, MPL-2.0) but its license is
incompatible with MIT/Apache-2.0 distribution, so no code may be copied,
transcribed, or derived from it. Reading it to confirm facts (e.g. "the
protocol surface is ~1300 LOC") is fine; reading it for implementation
technique is not. We do not name it in alkgit docs, README, or commit
messages; this research doc names it once so the policy itself is recorded.
License matrix
| Source | License | Use as dependency | Read for design facts | Copy/derive code |
|---|---|---|---|---|
gitoxide (/workspace/gitoxide) |
MIT OR Apache-2.0 | yes | yes | yes (attribution per license terms) |
| alkcall / alkhttp / alktls / alkvault | MIT OR Apache-2.0 (ours) | yes | yes | yes |
gitserver (/workspace/gitserver) |
MPL-2.0 | no | facts only, minimally | no |
russh (/workspace/russh) |
Apache-2.0 | yes (if we ever need raw sshd) | yes | yes |
| git itself (C) | GPL-2.0 | no (never ship binaries) | protocol behavior yes | no |
MPL-2.0 note: it is file-level copyleft. Linking an MPL-2.0 crate into our MIT/Apache-2.0 binary is technically possible (MPL is weak copyleft, LGPL-style), but distributing this project as MIT/Apache-2.0 while containing MPL-2.0 code-derived files would require keeping those files separately licensed — a mess for a crate intended for crates.io. We simply don't take anything from it: everything it does, gitoxide primitives + our own protocol layer does.
gitserver — what we may legitimately take from it
Only the existence proof and shape facts:
- A single-binary git server in Rust with http interface fits in a small code footprint when gix provides storage (their core crate is ~3.4k LOC including pack/ref/http plumbing).
- They hand-rolled pkt-line + protocol_v2 + receive_pack rather than using
gix-protocol— consistent with our finding that gix-protocol is client-side only. - Their http crate is a thin axum wrapper — consistent with our plan to make the http adapter thin over alkhttp.
What we must NOT take: their file contents, function structures, error taxonomies, test matrices, or README wording. If during implementation we find ourselves about to write something that would look like their file structure, stop and design from gitoxide primitives + git's protocol spec instead.
Other prior art (not vendored, for awareness)
rudolfs(/workspace/rudolfs) — a git-lfs server in Rust, not a git server; relevant later if LFS support is scoped (it is not in v1).sftp-rs/russh-sftp— for an SFTP endpoint; out of scope for v1 (git over alkcall channels is our ssh story, not an sshd).- gitea/gitlab — the threat-model references, not code references.
Naming policy
The incompatible-licensed project is referenced in this doc only (and possibly in future ADR context blocks explaining "we looked at prior art"). It does not appear in README, architecture docs, or code comments. Reason: license-hostile maintainers have historically DMCA'd or harassed projects that even referenced their work in docs; there is no need — our design sources are git's own protocol specifications and gitoxide.