Adopt Apache-2.0 as the repository licence (+ open-source scaffolding)

[oaksprout]

PR: #277 — docs: adopt Apache-2.0 and add open-source scaffolding

• Version: 0.1 (discussion draft)
• Date: 2026-05-18
• Author: Guided by Oaksprout, written by Claude
• Status: Open for review. First ask: is Apache-2.0 the right code licence for Jinn-authored code, and is the rest of this scaffolding the right minimum to be properly open source?

Motivation

The repository is public but it is not, strictly, open source. There is no LICENSE file at root. The Jinn-authored Solidity carries SPDX-License-Identifier: MIT per-file and client/package.json declares MIT, but a public repository without a licence grants no rights to use, modify, or redistribute the code — the per-file SPDX tags imply MIT for those files, the rest defaults to "all rights reserved" by copyright law.

That state is incoherent with PRINCIPLES.md:

• Permissionless ("the network's output is composable — anyone can build on Jinn's primitives without permission") cannot be honoured if the legal default is "all rights reserved".
• Legible ("every claim we make about ourselves must be independently and robustly verifiable") cannot be honoured when the licensing posture has to be reconstructed from per-file SPDX tags and a package.json field.
• Neutral ("we should be able to signal our qualities cheaply in a way that would be expensive to fake") asks for the strongest low-cost neutrality signal we can ship — adopting a permissive licence with an explicit patent grant is exactly that.

This proposal closes the gap.

Decision proposed

Adopt Apache License, Version 2.0 as the repository licence for Jinn-authored code.

Why Apache 2.0 over MIT

MIT matches the existing per-file SPDX tags in the repository and is the lower-friction choice — a defensible answer. The reason to take a small amount of friction and pick Apache 2.0 instead is the patent grant:

• Apache 2.0 §3 includes an explicit, irrevocable patent licence from every contributor, and §3's retaliation clause auto-terminates that grant against any party who initiates patent litigation against the work.
• MIT has no patent grant. The patent licence is implicit at best and contested at worst.

For a network whose meta-principle is legitimacy and whose first derived principle is Neutral, "we cannot be captured by a patent claim" is a load-bearing property, not a nice-to-have. The patent grant is the property that makes the licence "expensive to fake" — anyone trying to capture Jinn via patent has to give up the patent first.

Why not AGPL or any copyleft

AGPL / GPL would tie downstream behaviour to upstream rules. That conflicts with Permissionless (composability without permission) and with Governance Minimal (every viral obligation is a governance surface). Copyleft is the wrong instrument for a coordination protocol that wants to be the substrate other things build on.

Why DCO and not a CLA

CLAs centralise contributor rights to a corporate entity that can then relicense or sub-license. That sits a governance surface between contributors and the licence. The Developer Certificate of Origin is the same attestation without the centralisation — contributor signs that they had the right to submit; rights flow directly to the project under the project's licence. Same legitimacy, smaller capture surface.

Why a separate trademark policy

The Jinn name, sigils, and wordmark are part of the protocol's identity — they are the "21M supply + proof-of-work" of the brand. They cannot be Apache-2.0 (which excludes trademarks anyway) but the headless-brand posture in BRAND.md rules out a corporate trademark regime. The compromise the proposed TRADEMARKS.md makes:

• Descriptive, factual, fan, journalistic, educational, non-deceptive-fork use: explicitly permitted, no permission needed.
• Use that presents a fork as Jinn or implies endorsement: not permitted.
• Enforcement posture: only against material confusion, particularly where money/custody/safety claims are involved.

This protects Legible (participants can tell what is and isn't Jinn) without contradicting headless-brand.

Why this is principle-aligned, not just hygiene

A licence is a coordination commitment. Apache 2.0 + DCO + trademark carve-out is the cheapest set of commitments we can make that:

1. Cannot be undone unilaterally (Apache 2.0 contributor grants are irrevocable).
2. Are independently verifiable by reading the LICENSE file in a fork ten years from now (Legibility).
3. Do not structurally favour the founders or any operator over any other participant (Neutral).
4. Add no governance surface (Governance Minimal; DCO replaces a CLA).
5. Make patent capture expensive (Neutral, with teeth).
6. Leave the protocol-level brand commitments (name, sigils, lexicon) load-bearing as common knowledge anchors (Legible).

If a future contributor tries to argue against any of these properties, they will be arguing against PRINCIPLES.md.

What the PR contains

PR: #277 — docs: adopt Apache-2.0 and add open-source scaffolding

Files added or modified:

• LICENSE — Apache 2.0 verbatim text (canonical from apache.org).
• NOTICE — copyright statement, pointer to LICENSE, brief note on per-file SPDX precedence and the trademark carve-out.
• TRADEMARKS.md — the policy described above. Carves Jinn name, sigils, wordmark, and the protocol-level lexicon (summon, bind, vow, vessel, wish, smoke, seer, wane) out of the code licence. Headless-brand-aligned enforcement posture.
• CODE_OF_CONDUCT.md — Contributor Covenant 2.1, with conduct@jinn.network + GitHub private reporting as the enforcement channel.
• SECURITY.md — private vulnerability reporting (GitHub PVR preferred, security@jinn.network fallback), scope, disclosure timeline, safe harbour for good-faith research.
• THIRD_PARTY_LICENSES.md — by-directory inventory of vendored upstream code. Documents the licence count: 116 MIT, 4 AGPL-3.0-only (stolas/solmate fork), 4 LGPL-3.0 (mech lib), 1 GPL-3.0 (mech Account.sol). Flags the AGPL-3.0 contamination of the contracts package as a known follow-up requiring resolution (preferred: swap to upstream MIT Solmate).
• CONTRIBUTING.md — adds a "Licence and sign-off" section requiring DCO Signed-off-by: on every commit and stating that new files default to Apache-2.0 (existing per-file SPDX tags retained).
• README.md — adds a Licence section.
• contracts/package.json — adds "license": "SEE LICENSE IN LICENSE" (because the contracts package is mixed-licence due to vendored copyleft).

Explicitly out of scope for this PR

These are the items I'd otherwise want to bundle, deferred to keep the PR reviewable and the decisions separable:

• Resolving the AGPL-3.0 contamination in contracts/src/vendor/stolas/solmate/ (4 files). The preferred resolution — swap to upstream MIT Solmate — is a contracts change that should go through its own review. Tracked in THIRD_PARTY_LICENSES.md and will be filed as a follow-up bd.
• Relicensing existing MIT-tagged Jinn-authored files to Apache-2.0. This needs author consent and a separate, deliberate sweep. Per-file MIT SPDX stays as-is for now; Apache-2.0 is the root licence and the default for new files. MIT and Apache-2.0 coexist legally without issue.
• Secrets / history audit. The repo is already public, so this is retrospective hygiene rather than a gate. Will be filed as a follow-up bd.
• yarn licenses machine-readable inventory for client/ and packages/. Same reason — separable from the licence-adoption decision.
• GitHub repo settings: enabling private vulnerability reporting; setting the licence in repo metadata so GitHub's "License: ..." badge renders. Both happen after the PR merges.

Questions for reviewers

1. Apache-2.0 vs MIT — am I weighing the patent grant correctly? If you would prefer MIT for continuity reasons (matches existing per-file SPDX tags, lower friction), say so here.
2. DCO vs CLA — anyone want to argue for a CLA? The case would be: future entity formation might want to relicense or commercially sub-license, which DCO makes harder. My read is that exactly that flexibility is what we don't want (it's a capture surface).
3. Trademark policy — is the carve-out narrow enough to be headless-brand-aligned, or too narrow to actually protect Legibility? Specifically: is the "do not present a fork as Jinn" clause clear enough to be enforced by social pressure without ambiguity?
4. Scope — should the AGPL-3.0 stolas/solmate swap be in this PR rather than deferred? Argument for: licence adoption is incomplete if the contracts package is still effectively AGPL-encumbered. Argument against: it's a contracts change and a licence change, and bundling them makes both harder to review.
5. CODEOWNERS — should this PR add TRADEMARKS.md, SECURITY.md, LICENSE, NOTICE, THIRD_PARTY_LICENSES.md, CODE_OF_CONDUCT.md to .github/CODEOWNERS so future edits go through canon-owner review? I left this out of the PR but it would be a small addition.

After this discussion

If consensus lands and the PR merges:

1. Enable GitHub private vulnerability reporting on the repo.
2. Confirm the GitHub-rendered licence badge resolves to "Apache-2.0".
3. File follow-up bds for: AGPL-3.0 stolas/solmate swap, secrets-history audit, machine-readable client/packages licence inventory.
4. The Discussion: <this URL> pointer in this PR's body becomes the canonical audit trail for the decision.

[ritsukai]

Apache seems the right fit for this. If we have this those files (TRADEMARKS.md, SECURITY.md etc.) then yes I think they should go through canon-owner review.

[oaksprout]

Aligning with the no-canonical-surfaces posture (#316): Apache-2.0 is the right licence not just because it's permissive, but because it structurally invites the forking we now explicitly want. The licence + the no-canonical posture together make plurality real instead of aspirational.

Operational follow-ups that fall out:

• Every implementation repo (client, frontend, broadcast bot, etc.) carries Apache-2.0 + a clear "forks and alternative implementations welcomed" note in the README.
• CONTRIBUTING.md explicitly invites design input via Discussions/PRs and explicitly invites alternative-implementation contributors who don't want to contribute to this implementation. (Tracking that update as a separate issue.)
• The future repo restructure (also tracked separately) splits Jinn-Network/protocol — containing only canonical artifacts — from the implementation monorepo, which moves to the implementing contributor entity's GitHub org. Apache-2.0 applies to both but the org structure makes the "this is one implementation among many" framing visible.