Forks and independent implementations

The code is released under MIT and the law texts are open to all. Forks are welcome, and so are implementations in any language. There is one request: keep differences visible.

Licence

Code and documents are under the MIT licence: you may use, modify, redistribute and sell them, keeping the licence text. The registry contract’s source is under CC0, and the embedded fonts are each under SIL OFL 1.1.

An implementation of your own

The law text is self-contained: every judgment verification needs is stated in it. Write an implementation from the text in the language you choose, then validate it with the conformance suite; with zero divergences against the frozen core it is a conforming implementation, on the same footing as the one in this repository.

The more independent implementations, the sturdier the law: each one written from the text alone is one more chance to find an ambiguity in it. When you find two implementations diverging outside the corpus, open an issue.

Forking the app

Changing the interface, adding features and changing defaults all belong to the tooling layer, and you are free to do them. Please attend to three points:

Take another name

So that users can tell the two programs apart.

Take another machine folder

So that the two programs keep their key stores and data apart.

Stay conforming to the law

The original can read ledgers your fork writes, and your fork can read ledgers the original writes.

Changing the rules

A change to the rules has to be visible to every reader: start a new spec name and a new signing-domain literal. Signatures under the two sets of rules are then independent, and a reader sees at a glance which set an entry belongs to.

• Choose a spec name and domain literal wholly distinct from the existing ones; the literal zikaron/1 always means the present law.
• Publish your law text and core, and state the digest.
• Write ledgers under the new rules with a new key.

The registry contract

The contract is shared by everyone. Anyone can deploy the same bytes on any EVM chain that has passed the Shanghai upgrade and get the same code hash. A verifier states in its scan range which addresses it accepts; a contract you deploy and one someone else deploys stand equal before the law.

Who decides

The law

The frozen core decides. Maintainers, like everyone else, can only start a new version.

The contract

The deployed bytes decide.

This repository

The maintainers decide which pull requests to merge. When you disagree with a choice, forking is a legitimate way out.

Users’ data and keys

The users decide; the project holds source code alone.

The weight of evidence

The reader of the evidence decides.

Stating it plainly

When you present your fork or implementation, state which version of the law it conforms to, which registry contract it uses and which nodes it connects to by default. Users rely on these to judge whether records written by the two programs can verify each other.