Governance and Licensing

Osmol installed its governance at population one, before it had a second contributor, let alone a second user. That was deliberate. The engineering dissertation states the reason plainly: governance retrofitted after adoption is how open protocols quietly become products. This page documents what the governance file actually says, and what the license actually permits.

The source of truth is GOVERNANCE.md in the osmol-lang/rfcs repository. Everything below is a faithful rendering of it; where the two ever differ, the file wins.

Who decides

Osmol currently has one maintainer, its founding keeper, named and signed in GOVERNANCE.md. The maintainer may appoint co-maintainers at any time by amending the file. This is the ordinary shape for a young language (a benevolent dictator, explicitly temporary). What is unusual is only that it is written down, versioned, and bound by the clauses below from day one.

What defines the language

In order of authority, quoting the file:

  1. The conformance suite (when it exists): programs and their required outcomes.
  2. The specification at osmol-lang/spec.
  3. The reference implementation, "which serves the two above and never overrules them."

Note what is not on the list: the maintainer's opinion of the moment, and any particular codebase's convenient behavior. When the suite exists, an implementation is Osmol if and only if it passes, the reference one included. See Conformance for how the suite grows.

The constitutional clauses

Two clauses in GOVERNANCE.md are marked amendable by nothing. Verbatim:

  1. Osmol's specification, suite, and reference code remain under irrevocable open licenses.
  2. Conforming implementations must honor the portability guarantee: a participant's membranes, models, and logs export and rehost losslessly.

The first clause keeps Osmol a protocol rather than a product: no future steward, including the founding one, can take the language private.

The second one deserves some attention, because it is a conformance requirement, not a courtesy. A participant's membrane is the most sensitive filter ever attached to a life; whoever hosts it curates that person's reality. The Fifty-Year Letter names this the gravest risk of the whole design: a filter you do not control is a cage with good UX. The portability guarantee is the structural answer (dissertation, Chapter 10): if your membranes, models, and logs export and rehost losslessly on any conforming mesh, then no host, the project's own infrastructure included, can convert the filter layer into a captive position. An implementation that stores state in a roach motel is not a lesser Osmol; it is not Osmol at all.

The dead-man clause

GOVERNANCE.md closes with succession, the outlive-me clause, verbatim:

If every maintainer is publicly unreachable for 12 consecutive months, stewardship passes to the most spec-conformant actively maintained public fork, which may claim continuity of the Osmol name. The stone belongs to whoever keeps carving it faithfully.

Note the tie-breaker: not the loudest fork, not the biggest, but the most spec-conformant one. Even succession is decided by the authority list above.

Licensing

Everything is MIT, everywhere (spec, reference interpreter, proofs, this book), under the copyright line:

Copyright 2026 The Osmol Language Contributors

For an implementer, MIT means exactly what you hope: build Osmol in any language, embed it in anything, commercial use is fine, forking is fine. Keep the copyright notice and license text in your distribution, and you owe nothing else. There is no CLA, no patent gate in the license, no "open core" seam waiting to close.

One planned refinement: the specification may later add CC-BY or Apache-2.0 as parallel license options, add-only, never subtract. A document already released under an irrevocable license stays released; future versions can only widen the grant. This is the licensing face of the first constitutional clause.

How change happens

Grammar and semantics changes ship only in editions, and enter through the RFC process: a pull request to osmol-lang/rfcs describing the change, its motivation, and its effect on the spec and suite, accepted or declined by maintainers with written reasons. Lightweight at today's population, and installed anyway, for the reason this page opened with.