Governance
Change controller, change process, licence, intellectual property, trademark and contribution terms — including the parts that are not yet settled.
This page states who controls the AKP specification, under what terms it is published, and how it changes. It is written for anyone deciding whether to implement the format or to depend on an artifact produced against it.
The change controller§
The specification is controlled by a named role, not by a named person. Role addresses are published below. This is deliberate: a specification outlives the people who write it, and a personal mailbox is not.
| Role | Address | Responsibility | Status |
|---|---|---|---|
| Change Controller | spec@stemmar.org | Owns the normative text and decides changes to it. | Defined, not yet routing |
| Security | security@stemmar.org | Receives reports of security defects in the specification, such as a parsing or resolution behaviour that the normative text mandates and that is exploitable. | Defined, not yet routing |
| Trademark | trademark@stemmar.org | Questions about permitted use of the format name and the wordmark. | Defined, not yet routing |
Status: the domain and its role addresses are not yet active. The addresses above are the defined addresses and will not change. They do not yet route, and nothing currently depends on them resolving.
The project is vendor-led. Stemmar employs the change controller and maintains the reference implementation. That is stated plainly rather than obscured, because a neutral-looking arrangement that turns out to be vendor-led on inspection is a worse governance position than a vendor-led one that says so. The mitigations are structural: the specification is published on a domain that carries nothing commercial, and every governance asset is held in a form that can be assigned to a foundation without being renegotiated.
How the specification changes§
A change to the normative text goes through four steps.
- Proposal. Anyone may propose a change. A proposal states the problem, the change, and what it would break. Proposals arrive at the change controller address or through the public repository.
- Review. The change is assessed against the format's invariants — the normative information model, the separation of canonical content from derived artifacts, the requirement that unknown extensions round-trip byte-for-byte, and determinism of identity computation. A change that violates one of those is a defect in the proposal, not a trade-off to be weighed.
- Decision. The change controller decides. A decision that has architectural consequences is recorded as an architecture decision record, with the alternatives that were rejected and the reasons. The record is published; see the specification's own change log.
- Publication. The change appears in a new specification version, or as an erratum against an existing one. It never appears as an edit to published text.
The last point is the one that does the work. A published specification version is immutable. If a version says something wrong, the wrongness is corrected in public, in a document that names the version it corrects — not by changing the version so that the error never happened. A reader who cited a version years ago must find the same text there today.
Errata§
Not yet established. No specification version has been published for long enough to accumulate errata, and no erratum has been raised. The process, when it is written, will publish each erratum against the version it corrects and display it alongside that version's text rather than inside it.
Licence§
Not yet decided.
The constraint is fixed even though the answer is not: the licence must permit anyone to implement the specification, without restriction, without a fee, and without seeking permission. A specification whose whole argument is that independent implementations are the point cannot be published under terms that make one awkward.
The shape that is being considered is a permissive documentation licence for the text, combined with an explicit grant covering implementation. It is not being published as a decision until the interaction with contributed text and with a possible future foundation transfer has been worked through once, rather than twice.
Until the licence is settled, the text on this site is published for reading and review. Anyone who needs implementation terms before then should ask the change controller, and will be given a written answer rather than a form.
Intellectual property and patents§
Not yet decided.
Registration reviewers and enterprise legal functions both ask for this specifically, and the intended position is a patent non-assert or an equivalent covering implementation of the specification. It is not published as a commitment until the wording has been settled, because a patent commitment published loosely and then narrowed is worse than one published late.
No patent is currently asserted against any implementation of AKP, and none is known to apply.
Trademark policy§
Partially decided. The full policy is not yet written.
The settled part is the distinction, and it is the part implementers need:
- AKP is the name of the format. It is freely usable to describe an implementation, an artifact, or a product that reads or writes the format. Describing software as "an AKP reader", "AKP-compatible" or "reads AKP packages" needs no permission and will never need permission. A format name that could be withdrawn is not a format name.
- Stemmar is the wordmark of the organisation. It names the project, the toolchain and the commercial entity. It is not free to use, and it does not appear in the format, the media type, the file extension or the byte signature.
Write "the AKP specification, published by Stemmar", not "the Stemmar format". The format is not named after the vendor, and the naming should keep making that visible.
What is not yet written is the full policy: permitted logo use, the conditions under which a conformance claim may be displayed, and the treatment of derivative names. The conformance part of it is blocked on the conformance terms below.
The mark is currently unregistered. No registration application has completed.
Contributing§
Provisional. Contributions to the specification text are welcome, and the terms below are the terms in force. They may be replaced once the licence is settled, and any replacement will be published before it applies.
A contribution is accepted on the basis that the contributor has the right to submit it and grants the change controller the right to publish it under the specification's licence, and under any later licence the specification is published under — including on a transfer to a foundation. The mechanism for recording that is a sign-off on each contribution, in the manner of a developer certificate of origin, rather than a copyright assignment.
The provenance requirement is not bureaucracy. If the specification is ever assigned to a foundation, every line of it has to be assignable, and text of unknown provenance is text that cannot be transferred. Establishing that at the point of contribution costs nothing. Establishing it retrospectively may be impossible.
Conformance claims§
Not yet decided.
No conformance claim is currently defined, and consequently no implementation should claim AKP conformance, including the reference implementation. There is no conformance suite to run and no definition of what passing it would mean.
Two things are already fixed about the answer. Conformance is defined here, on the specification surface, and may never be defined commercially. And verification performed commercially produces an attestation — evidence that a check was run and what it found — not a definition of what conformance is. If the organisation that publishes the specification is also the only body that may certify against it, the neutrality position on this page is considerably weaker, and that is an unresolved tension rather than a solved problem.
Conformance profiles beyond a minimal core are similarly undefined, tracked as Q10.
Versioning§
The specification is versioned independently of the reference implementation. An implementation at version 0.4 may implement specification version 0.1; the two numbers are unrelated and are not synchronised.
Every published version keeps its own permanent URL. Versions are listed on the overview and each carries an explicit maturity label:
| Label | Guarantee | In use |
|---|---|---|
| Draft | No stability guarantee. Any part of this document may change, including in ways that invalidate artifacts produced against it. Do not build a production dependency on a draft version. | 0.2 |
| Candidate | The information model is believed complete and no further breaking change is planned. Changes may still be made in response to implementation experience, and each will be recorded as an erratum or a new version. A candidate version is suitable for writing an independent implementation against. | 1.0-rc |
| Stable | The normative text will not change. Corrections are published as errata against this version and never as edits to it. A breaking change requires a new major specification version. | None |
What triggers a major version is not yet decided. Tracked as Q37. The question is coupled to what the byte signature encodes, because a detector reads the specification major version out of the signature without parsing the artifact, and the two definitions of "major" have to be the same definition.
Security reports§
A security defect in the specification — a behaviour the normative text mandates or permits that is exploitable in any conformant implementation — should go to the security role address above. Defects in the reference implementation go to the same address until a separate route is published.
The format's threat model treats all ingested source content as hostile. Malformed and deliberately adversarial source documents are the expected case, not the exceptional one, and any specification text that assumes otherwise is a defect worth reporting.