Contract models

For contract model lists see CM category.

Contracts/agreements need to be simple, human-readable and reliable: thus, they need to be "standard", based on contract models.

This page is a sort of "OSM contract models entry point", an official gazette of the OSM's contract models tested by community. The autority of the contract model is the general "OSM Community", but, given that precedent use (tests) and languages are local, the contract models can by organized in jurisdictions.

To avoid confusion and provide a permanent and up-to-date link, it is also important to assign a unique identifier for each contract model, rather than a long title. Because the Wiki needs human readable titles, the ID can be a redirection to a composite "ID - Name" title (plus a redirector from ID page). The complete namespace for each jurisdiction-ID will be a namespeace prefix such as CM (standing Contract Model), so the full syntax of the Wiki-title will be CM/{$Jurisdiction}/{$ID}. Examples:

• CM/en/001 (that redirects to CM/en/001 - Cover letter and waiver template for CC BY v4), a contract model useful for any country.
• CM/pt/BR/001 (that redirects to CM/pt/BR/001 - Decreto Municipal para Licenciamento de Dados), a contract model adapted for portuguese language and ported to the BR (Brazilian) jurisdiction. The parent path, CM/pt/BR, lists other.

See historical contract models at OSM Foundation's Licence/Waiver and Permission Templates.

Objective

Each contract model has a specific contracting objective, but historically at OpenStreetMap, the main objetive of contract models are to reinforce license or to check dataset donor's agreements. The aims here, in this Wiki project for template organization, are wider:

1. easy to find contract models (find ID, find text or navigation by languages, countries, themes, etc.);
2. unique identifier for each contract model (CM/{$Jurisdiction}/{$ID});
3. easy to classify (you can add category);
4. serious version control (see Wiki-history and at each contract model its green box);
5. any Wiki user, the full OSM community, can edit (not only few OSMF editors);
6. serious review process, to be result in an official and registrable (at official jurisdiction) document;
7. non-limiting the contract models to permissions (also e.g. law and governamental active transparency).

About "serious", for example in Brazil use using http://Uniproof.com.br as official (Brazilian jurisdiction) register. About law, see concrete case of Jaragua do Sul at CM/pt/BR/001.

The contract model

Contract models (CMs) are documents with controled structure and with placeholders (like forms, DTDs, templates or Wiki placeholders). At this Wiki we can use some conventions to express contract models:

• title page conventions: the Wiki page with title's syntax CM/{$Jurisdiction}/{$ID} - Name is the page of the contract model.
  The $ID is the identifier (a counter) of the contract model, and $jurisdiction, when used, the country-code (e.g. BR) or subdivision (e.g. BR/SP). A redirect-page CM/{$Jurisdiction}/{$ID} is also created, to simplify access to the page.

• the "root path" of each CM/{$Jurisdiction} is redirected to a category that starts with the "next ID" (to be edited/updated) and lists all local contract models.

• Text/instruction separation convention: some kind of "boxing markup" as
  <div style="background-color:#EDB; padding: 3em;">... contract model text ... </div>.

• placeholder syntax: somethig as <code>{$varName}</code>, that is rendered as "{$varName}".

• add CM category to the page (category:CM/{$Jurisdiction}), so the list of all contract models will be the category list.

CM life cycle

General life cycle of a contract model, like a RFC submission.

Usual RFC life cycle.

1. Initial draft Submission to the community any OSM's valid chanel
2. Author Refinement
3. CM-authority's (community) in Acceptance and working group (WG) Selection
4. WG's Editor Selection
5. WG Refinement
6. WG Last Call
7. WG Request to Publish

State diagram of the life cycle of a contract model wiki-text.

Other way to organize life cycle, viewing the text of the CM as a community-task, so, the basic states in a state diagram is:

• ACCEPTED - a new enqueued CM waiting to be pulled by demand of any local community agent (jurisdiction's community);
• SCHEDULED - a task pulled (dequeued) by the a local redactor but not yet stared;
• RUNNING - a "task of readact or review" being processed by the local redactor;
• PAUSED - a "redact task" which has been put on hold by the some one and which is waiting to be resumed, after new discussion;
• FINISHED - a "redact task" which has been finished successfully (terminal state)
• FAILED - a "redact task" which has been finished by a failure (terminal state)