OpenWyrd MOP — Governance Charter

This document governs the MOP wire specification and its surrounding documents (RFC series, conformance suite, canary policy). It does not govern individual implementations — those are governed by their own maintainers under their own licenses. The spec belongs to no company, no foundation, no board. It belongs to the people running code that conforms to it.

Stewardship

The current steward of MOP is DeltaClimbs, BDFL-for-now. This is a transitional posture, not an end state. The steward holds tie-break authority over spec decisions and merges accepted RFCs.

Stewardship transitions to a multi-maintainer model when both of the following are true:

1. At least two independent implementations exist — independent meaning separate codebases, separate maintainers, neither a fork of the other — and both pass the conformance suite at the latest accepted spec version.
2. At least two contributors other than the BDFL have shipped substantial RFC-grade contributions (a new MOP-NNN doc accepted, or a non-trivial revision to an existing one).

When both conditions are met, the BDFL relinquishes tie-break authority and the maintainer set becomes the active stewards. Decisions thereafter follow rough consensus among maintainers; in the rare case of deadlock, the spec stays as-is. There is no foundation. There is no legal entity. There is no board. There is a list of people with merge rights and a process they have agreed to follow.

RFC process

Spec evolution happens through numbered MOP documents: MOP-001 (the wire spec), MOP-002, and onward. Anyone may propose an RFC by opening a pull request adding a new MOP-NNN file in the mop/spec/ directory.

An RFC is acceptable when it has:

1. Running code. A working implementation, in any language, demonstrating the proposed change.
2. Interop test. A test case added to the conformance suite that exercises the proposed behavior across at least two implementations.
3. Rough consensus. No outstanding strong objection from an active maintainer after a 14-day comment window. "Strong" means an objection grounded in a technical or capture-resistance argument, not aesthetic preference.

Rough consensus at this scale means: the people doing the work agree, and the people not doing the work do not get a veto. Lazy consensus applies to non-controversial editorial fixes — typo, clarification, broken link — which any maintainer may merge directly.

Versioning

Each MOP-NNN document is independently versioned under semver:

• Patch — clarifications, examples, non-normative additions. No interop break.
• Minor — additive normative changes. Old conformant implementations remain conformant; new features are opt-in.
• Major — breaking changes. Breaking changes do not amend an existing MOP-NNN. They are issued as a new MOP-NNN+1 that obsoletes the old one. The old MOP-NNN remains published, marked obsolete, and continues to define behavior for implementations that have not migrated.

Once any MOP-NNN reaches 1.0, the deprecation cycle for breaking behavior in that document is minimum twelve months between obsolescence announcement and removal of conformance-suite coverage.

Implementation neutrality

SendWyrd is the canonical reference implementation. SendWyrd is one host among many. SendWyrd has no veto over the spec. A reference implementation is a role — it tracks the spec closely, ships first, and serves as a known-good bring-up target. It is not a master copy. It is not the spec.

If a non-reference implementation diverges from the spec, exactly two outcomes are admissible: the implementation patches itself to conform, or the implementation proposes an RFC to change the spec. There is no third option. There is no carve-out for a popular fork, a well-funded vendor, or an early adopter.

Conformance

The cross-implementation conformance suite at mop-conformance/ is the gate. An implementation is MOP-compliant at version X if and only if it passes the suite at version X. That is the only meaning of compliance.

Marketing claims of MOP compliance without a passing conformance run are a bug, and will be called bugs. The badge is the badge. There is no honor system.

Hostility to capture

This project is built to be inconvenient to capture. The following are policy:

• No CLA. Contributions are licensed under the project license at the moment of submission. Maintainers do not ask contributors to assign rights to a single entity, because there is no entity to assign rights to.
• No conditioned grants. The project does not accept funding contingent on spec changes, governance changes, or favorable treatment of a contributor. Unconditional infrastructure grants (CDN, hosting credits) are acceptable and disclosed.
• No patent-encumbered contributions. Code or specifications encumbered by patents not licensed under a defensive-termination grant compatible with the project license will not be accepted.
• No unilateral breaking changes. No single maintainer, including the BDFL, may merge a breaking spec change without the RFC process running its course. The BDFL's tie-break authority resolves close calls; it does not override the process.

Permanent commitments

The following commitments are precedents, not preferences. They cannot be amended out of this charter. A future maintainer set that wishes to break them must do so under a new project name, not under the name MOP.

• The MOP wire spec is forever published under CC-BY-4.0 (prose) and Apache-2.0 (code). No relicense. No retroactive grant.
• The reference server sendwyrd is forever AGPL-3.0-or-later. No relicense. No CLA permits a future relicense, because there is no CLA.
• The reference client libraries are forever Apache-2.0. Permissive at the client edge is non-negotiable; the trust boundary is the server, not the client.
• No CLA, ever. Contributions are licensed under the project license at the moment of submission. The project will not grow a CLA later, including under the framing of "patent peace" or "license harmonization."
• No exclusion of features from the open core based on payment. Every cryptographic, federation, capability-URL, attestation, storage, expiry, and routing feature that ships in any maintained MOP host is in the open core. Operational tooling, support, and hosted-service convenience may be paid; protocol-level capability may not.

Trademarks

The names OpenWyrd, MOP, SendWyrd, Wyrd, and the project marks are governed by the trademark policy at governance/TRADEMARK.md. The trademark layer exists to keep the brand from being captured even where the license cannot reach. It permits good-faith nominative use and forbids implication of endorsement. Read the policy before naming a fork, a hosted service, or a derivative product.

Plugin boundary

Any code that interacts with an MOP server only via documented APIs — HTTP endpoints, capability URLs, declared IPC channels, configuration files, conformance-suite-stable wire formats — is a separate work for the purposes of the AGPL §5 combined-work test. The maintainers will not assert that documented-API consumers are derivative works of the server. This is a public commitment to plugin authors, not a legal opinion they can rely on against third parties.

The boundary does not extend to in-process linkage. Code that links into a server binary, imports server-internal symbols, or reaches behind the API surface is bound by the server's license. If a plugin author needs to cross that line, they must license under AGPL or upstream the change.

Premium and commercial posture

A maintainer may operate a hosted service (sendwyrd.com is the canonical reference deployment) and may charge for it. A maintainer may ship a separate proprietary product — a desktop client, a mobile app, a custody tool — that consumes the protocol via documented APIs. A maintainer may sell support, deployment automation, and integration services.

What a maintainer may not do, while remaining a maintainer of MOP under this charter:

• Remove a feature from the open core to reserve it for a paid tier.
• Make protocol-level interoperability conditional on a paid product.
• Privilege a hosted deployment (their own or anyone else's) in the spec, the conformance suite, or the canary protocol.
• Accept community contributions to a proprietary commercial module and then keep the contribution proprietary. Commercial modules are solo-authored by their commercial copyright holder, full stop.

The intent is straightforward. A maintainer can build a business around stewarding MOP. A maintainer cannot build a business by hollowing out MOP.

Succession and resilience

This project is built to outlive any single steward. The following provisions attach automatically, without further action:

• Incapacity succession. If the BDFL ceases to publish for ninety consecutive days without a designated continuity statement — no commits, no canary, no public response to a maintainer ping — stewardship transitions to the active maintainer set under the rough-consensus rules already defined. The BDFL designation is forfeited and is not restored on return without rough consensus of the maintainers then active.
• Trademark succession. If the trademark holder is incapacitated, gagged, indicted, sanctioned, or otherwise legally unable to publish under the project marks for one hundred and eighty consecutive days, the maintainer set then active may use the project marks to continue publication of the spec, the canary, and the reference implementation under this charter. The trademark holder's standing is restored when the incapacity ends and the holder publicly affirms continued adherence to this charter.
• Spec mirroring. The spec, conformance suite, and canary MUST be mirrored to no fewer than three independent jurisdictions and at least one non-Five-Eyes hosting venue within six months of the first 1.0 MOP-NNN tag. The mirror set is published in governance/MIRRORS.md once established. A canary signed only on the primary domain, with no surviving mirror, is treated as a degraded canary.
• No founder lock-in. No technical decision in the spec, the conformance suite, or the canary protocol is permitted to depend on a credential, key, domain, or service controlled solely by the BDFL. Every such dependency is a defect and is filed as one.

These provisions are not amendable in a way that weakens them. They are amendable in directions that strengthen them.

Conduct

Ship code, not drama. Attack ideas, not people. Don't be tedious. You'll know when the line is crossed; don't be the one to cross it.

The maintainers reserve the right to remove contributors whose behavior makes the project worse to work on. This will be done transparently, in writing, with reference to specific incidents. Persistent bad-faith engagement is itself a security issue, and will be treated as one.

Warrant canary

Every host operator running an MOP server in production MUST publish a warrant canary at /canary per MOP-001 §10. This requirement is normative, not advisory, and it attaches at the moment a host accepts traffic from anyone other than its own operator. A host that ceases publishing a valid canary is signaling a state change to its users; clients SHOULD surface that signal.

Pre-launch projects without a hosted production deployment are exempt from the active-canary requirement. They MUST publish the canary policy (the affirmations, the mechanism, the cadence) before they begin accepting outside traffic, and the first signed attestation MUST land no later than the date production opens.

The project itself maintains its own canary at openwyrd.org/canary once production launches, signed with the project's maintainer key, refreshed on a published cadence. Loss of canary on the project domain carries the same meaning it carries everywhere else. No further comment will be made.