OpenISO.org Core Guidelines

DocumentID: OI A200:draft3
ShortTitle: Core Guidelines
LongTitle: OpenISO.org Core Guidelines
Date: 2007-12-07, 2007-W49-5
Working-Group: discuss@OpenISO.org
Editor: Norbert Bollow
About: OpenISO.org


# OpenISO.org Core Guidelines #

## Overview ##

OpenISO.org aims to provide a process in which concerns about proposed
standards are fairly evaluated in a transparent and fact-oriented
manner, according to requirements of openness and maturity (described
briefly in the section on decision-making processes and requirements
below; in addition, OpenISO.org is planning to develop separate
documents with detailed formulations of the requirements.)

For specifications which satisfy OpenISO.org's criteria for approval
as a standard all kinds of concerns are evaluated and reflected upon
in OpenISO.org's evaluation report on the specification.

Regarding specifications which do not satisfy the criteria for
approval as a standard, OpenISO.org evaluates only concerns about
issues which are in themselves serious enough to justify (if the
concern is found to be valid) refusal of approval as a standard.

In addition to deciding whether specifications fulfil OpenISO.org's
criteria for standards, during the evaluation process a rating is
assigned to each specification.

This rating is one of the following:

1. Strongly discouraged
2. Discouraged
3. Recommended in some contexts
4. Recommended
5. Strongly recommended

Specifications with a rating of "strongly discouraged" or "discouraged"
are not approved as standards, while those with ratings of "recommended
in some contexts", "recommended" or "strongly recommended" are approved
as standards.

If after completion of OpenISO.org's evaluation of a specification
further concerns are raised, or if the validity of the justification
for the rating is challenged, these comments will be evaluated, and
if it is found that the facts justify such a step, the rating will be
adjusted.

There is a variety of reasons why a specification's rating may change.
It is possible that a serious issue has been overlooked or a mistake 
made during a specification's initial evaluation.  It is also possible
for problems to get resolved outside the specification itself, for
example patent problems can go away when a patent expires or when a
sufficiently broad patent license is granted.


## Requirements language ##

OpenISO.org's conventions with regard to the use of the words
"should", "must", "can" and "may" are as follows:

The word "should" and its negation "should not" are used to express
procedural requirements which, if not satisfied, will result in the
concerned action or specification being considered noncompliant with
OpenISO.org requirements.

The word "must" and its negation "must not" are used to express
requirements which, if not satisfied, will result in the concerned
action or specification being considered noncompliant with
OpenISO.org's interpretation of international law and/or other
widely-recognized principles of law.

The word "may" is used to described something which is allowed but not
required.

By contrast, the word "can" and its negation "cannot" are used to
describe ability or possibility independently of whether the concerned
possibility is required, allowed or forbidden.


## Working-Groups ##

Like just about every other standards organization, OpenISO.org
organizes its activities by means of structuring them into a number
of Working-Groups.

In the case of OpenISO.org, these working-groups are implemented by
means of "discussion" email mailing lists.  For each Working-Group,
the subscribers of the mailing list are the members of the
Working-Group.

The OpenISO.org Working-Groups are organized in a hierarchical
manner, with the discuss@OpenISO.org Working-Group at the root of
the hierarchy.  All other OpenISO.org Working-Groups are directly
or indirectly sub-groups of discuss@OpenISO.org.  Each of these
subgroups reports to the Working-Group of which it is a subgroup.
Subgroups should be formed whenever the traffic on any of the
Working-Group mailing-lists becomes so intense that the sheer volume
of the traffic becomes an obstacle to productivity.

All Working-Group decisions should be justified in writing.

If the validity of the justification for a decision is disputed and
the Working-Group does not reach a consensus resolution of the issue,
OpenISO.org will as quickly as possible, by means of a process which
is independent of the Working-Group, evaluate the arguments from each
side in a fair and fact oriented manner, and any Working-Group actions
which depend on resolution of the disagreement are delayed until a
decision has been reached.  (See the section on dispute resolution
below.)

In order to prevent to wasting too much money on dealing with trolls,
those who have taken positions which are found to be frivolous will
after wards have to pay themselves for getting their disputes
resolved.  The same applies to anyone who engages in conflict-bombing
(initiating many conflicts simultaneously.)


## Decision-making Processes and Requirements ##

The fundamental decision-making principle is of course that decisions
should be made in a fact-based manner.  The fundamental question is:
What happens when there is no consensus about an appropriate
fact-based decision? In most existing standardization organizations,
at that stage the decision-making process either breaks down or the
committee members vote.  Both of these mechanisms are inadequate
because is the first case a monopolistic company can prevent any
decision it doesn't like by means of breaking the consensus, and in
the second case it can manipulate every vote by means of telling
enough "gold certified" (economically dependent) partner companies to
vote, like it happened in the case of the ISO/IEC evaluation of OOXML.

Therefore, OpenISO.org adopts the rule that all disagreements which
cannot be resolved by means of Working-Group consensus processes should
be addressed by means of an independent, professional evaluation of
the relevant facts, as described below in the section on dispute
resolution.

Every decision should be justified in writing, based on scientific
facts and/or OpenISO.org's requirements regarding openness, maturity
and mapping properties, as appropriate.


Openness requirements will include that there should be no patent
issues etc, and that the process by means of which the specification
is maintained is "open" in the sense that all legitimate concerns and
commercial interests are fairly considered.

Maturity requirements include that a complete non-copyleft or
weak-copyleft free software implementation should exist, and that the
spec has been reviewed for cross-cultural applicability and with
regard to its impact on people with disabilities.  Where a
significantly earlier standard with significant marketplace adoption
already exists, the OpenISO.org maturity requirements also include
that for any new standard which will compete with the pre-existing
standard, for every aspect of how the new proposed standard which can
be objectively compared with the pre-existing standard, the new
proposed standard should in that respect be at least as good as the
pre-existing standard.

The requirements for mapping properties are that all semantics which
can be expressed by earlier standards in the same subject area (which
fulfil OpenISO.org's requirements for approval as a standard) should
also be possible to be expressed by means of the new proposed
standard.  The part of the new proposed standard which describes the
features providing these mapping properties may be declared "optional"
so that it is not a requirement for conforming implementations to
implement these features, but the specification of these features
should fulfil the OpenISO.org maturity requirements.

If it turns out that there are several justifiable viewpoints, the
proponents of the various possible approaches can all get their
preferred solutions equally endorsed by OpenISO.org provided that the
openness, maturity and mapping requirements are fulfilled, as
explained in more detail in the following:

If the text under consideration is a draft standard, what this rule
intends to tell the protagonists is: "If you can't reach agreement on
factual grounds, you have the freedom to fork the specification, and
OpenISO.org will not pick sides if both groups manage to produce a
specification which satisfies the  requirements regarding openness and
maturity and mapping properties."

If however the document under consideration is a review of a
specification such as e.g. OOXML and one group wants to have "you
can use ODF instead" in the review, and another group wants a
recommendation for another alternative, then both alternatives will
get equally recommended if and only if they both fulfil OpenISO.org's
requirements for approval as a standard.


## Dispute Resolution ##

Working-Group processes sometimes result in disagreements which need
to be resolved before the Working-Group can publish its evaluation of
a proposed standard.  Therefore OpenISO.org needs to provide a process
by means of which such disputes can be resolved.  The goal of this is
not at all to disempower Working-Groups from being able to resolve
disagreements among themselves by means of fact-oriented discussion,
but rather to give Working-Group members a strong incentive to admit
it when an argument that they have proposed is invalidated by a valid
counterargument.

Fortunately, the task of checking the validity of a proposed argument
and a proposed refutation can be carried out by anyone with at least
ordinary professional skill in the concerned area of subject matter.
OpenISO.org therefore resolves such disputes by means of entrusting
the dispute resolution process to a mediator who evaluates the
arguments of the protagonists to determine which of the arguments
(if any) are valid in a fact-oriented, scientific sense, so that
the disagreement is resolved and ceases to block the affected
Working-Group from being able to publish its findings.

Ultimately OpenISO.org intends to outsource the dispute resolution
process to a legally independent "Decision Consulting Services" (DCS)
business.  The DCS company will have a conditionally-exclusive
contract in the sense that as long as the DCS company provides an
excellent quality of service at a reasonable price (the precise
requirements for fulfilling these conditions will have to be spelled
out in detail in the contract), OpenISO.org will source (as resources
allow), from the DCS company, dispute resolution services for all
disagreements that the respective Working-Groups do not succeed in
resolving among themselves in a mutually-acceptable way.

If there are unresolved conflicts and OpenISO.org does not have the
necessary financial resources for resolving them, OpenISO.org
standardization work will be stalled in the concerned areas until some
interested party contributes the necessary financial resources for
getting the conflicted questions examined in a proper, professional
manner.

OpenISO.org itself will be established as a foundation under Swiss
law, and its bylaws will require it to terminate the contract with the
DCS company and never anymore give it any business if it is ever found to be
in violation of the contractual requirement to provide an excellent
quality of service at a reasonable price.  If a foundation under Swiss
law fails to act according to the principles in its bylaws, it should
possible to force the foundation to comply with its bylaws by means of
asking the responsible government authorities which are responsible
for the supervision of foundations to act on the issue.  Besides that,
recourse to Switzerland's well-developed court system is also possible.
Therefore, a very trustworthy assurance of integrity can be achieved
by establishing OpenISO.org as a foundation under Swiss law with a
strong requirement in the bylaws to switch to a different DCS company
if the DCS company is ever found to be corrupt or otherwise not up to
an excellent standard of reliability.  In such a situation, the new
DCS company must be strongly different from all previous DCS companies
in that a new DCS company must be chosen where no board member or
executive has served as board member or executive of one of
OpenISO.org's previous DCS companies.  (Unlike OpenISO.org itself,
which will be a foundation, the DCS company will be a normal company.)

The DCS company will be contractually required to provide its services
in a transparent, verifiable manner.  All decisions taken by the DCS
company must be justified in writing and made available for public
scrutiny.  All the DCS company's employees must be identified by means
of a unique permanent pseudonym, so that any systematic bias in the
actions of particular employee can be detected.  In addition to the
permanent pseudonyms, there will be separate, randomly-generated
pseudonyms with short-term validity for use during the dispute
resolution processes themselves.  Only after completion of any given
dispute-resolution process will it be disclosed what permanent
pseudonym corresponds to the short-term pseudonym which was used
during a specific dispute resolution process.  The introduction of
these short-term pseudonyms is an additional safeguard against
corruptions, which increases the difficulty of exploiting any
knowledge about vulnerability to undue influencing of a particular
employee of the DCS company.

The start-up plan for all this is that initially, the founder of
OpenISO.org takes care of the DCS function until the time
requirements for this function become too great for that and
OpenISO.org manages to acquire sufficient financial resources for
being able to outsource this function.  At that stage the founder
of OpenISO.org may name the company that becomes the initial DCS
company.  In particular, at that time the OpenISO.org founder will
have the right to name a privately-held company of his own for this
function.

This set-up provides the OpenISO.org founder with a rational economic
incentive for doing a good job with the OpenISO.org start-up, while at
the same time setting up appropriate incentives for ensuring long-term
integrity of the decision-making processes.


### Dispute-resolution process example ###

A typical situation in which the dispute-resolution process might need
to be involved could be as follows:  The Working-Group has been
reviewing the FooBar specification and is of mixed opinion regarding
whether FooBar should be approved as an OpenISO.org standard or not.
During the discussions, a number of concerns about FooBar have been
discussed, and concerning most of these the Working-Group has succeeded
in reaching consensus, but concerning one point no consensus has been
reached: The representative of Foo Inc. insists that FooBar does not
in any way create problems for persons with disabilities, but the
representative of Oof Inc. (which competes with Foo Inc.) insists that
FooBar causes significant problems for blind people.  Both have
submitted detailed arguments to support their respective positions.
The Working-Group needs to somehow decide which side of this dispute
has it right.

Since there is no consensus, the DCS company is called upon to provide
an answer to this question.

The DCS company assigns the question to an employee who has general
knowledge in the area of accessibility engineering and who also has no
vested interest in the success of either Foo Inc. or Oof Inc. or any
of their direct competitors.  This employee will be referred to as the
"validator" in the following.

Unless the position of one of the contrahents is for some reason
obviously wrong, the validator consults accessibility experts about
various points in the statement of Oof Inc. (which asserts
the existence of accessibility problems), taking into account any
counterarguments in the statement of Foo Inc. (which claims to rebut
the arguments of Oof Inc.)  When the validator has, with the help
of the experts that have been consulted, reached a conclusion, the
validator writes a report explaining why the assertion of Oof Inc.
is invalid or why Foo Inc.'s counterarguments are invalid.

The report is double-checked by a "supervisor", another employee of
the DCS company, and then the OpenISO.org Working-Group is given the
opportunity to comment on it.  If during this comments period it
becomes clear that there is something wrong with the report, the
validator, the supervisor, or the supervisor's boss at the DCS
company can decide to withdraw the report and do whatever it takes
to create a correct one.


## Requirements for Working-Group Participation ##

### Patent Non-Assertion Covenants Requirement ###

Most OpenISO.org Working-Groups require Patent Non-Assertion
Covenants from participants and/or their employers and clients
in order to minimize the risk of proposed standards for which
there are submarine patents gaining OpenISO.org approval.

The big exception to this rule is the discuss@OpenISO.org
Working-Group where such covenants are not required.

However, when subgroups of the discuss@OpenISO.org Working-Group
are created, for each such subgroup a "List of specifications"
will be specified for which a patent covenant as follows will be
required of participants in the subgroup.  This covenant is modeled
on Sun's promise .

> [Participant/Organization] irrevocably covenants that, subject
> solely to the reciprocity requirement described below, he/she/it
> will not seek to enforce any of his/her/its enforceable [Country of
> Participant/Organization] or foreign patents against any
> implementation of one of the following specifications [List of
> specifications] or of any subsequent version thereof, in the
> development or OpenISO.org evaluation of which [Participant/Organization]
> participates ("Implementation of a Covered Specification").
> Notwithstanding the commitment above, [Participant/Organization]'s
> covenant shall not apply and [Participant/Organization] makes no
> assurance, covenant or commitment not to assert or enforce any or
> all of his/her/its patent rights against any individual, corporation
> or other entity that asserts, threatens or seeks at any time to
> enforce its own or another party's [Country of Participant/Organization]
> or foreign patents or patent rights against any Implementation of a
> Covered Specification.

Prospective Working-Group participants should in addition evaluate
whether there reasonably appears to be a possibility that their
employers and/or clients could have patents or pending patent
applications that might be interpreted as being relevant to one
or more of the specifications on the Working-Group's list of
specifications.

Depending on the result of this evaluation, each prospective
Working-Group participants should submit to OpenISO.org a Letter
about Employers and Clients according to the following template:

> [Participant], called "the participant" in the following, hereby
> assures OpenISO.org that for all of his/her "firms of influence"
> (as defined below), ["without exception" / "with the possible
> exception of ... "] it appears extremely implausible that they might
> have any rights to patents or pending patent applications that might
> be interpreted as being relevant to implementations of one of the
> following specifications: [List of specifications].  Here "firms of
> influence" refers to any and all persons and organizations on behalf
> of whom or by request of whom the participant acts, as well as all
> important suppliers and customers of the participant or his/her
> employer.

Prospective participants will be accepted as Working-Group members
only after Patent Non-Assertion Covenants have been received from all
firms of influence for which it appears plausible that they might have
patent interests.


### Pseudonymous Participation ###

Pseudonymous participation in Working-Groups is allowed.  While
Working-Group participants must inform OpenISO.org of their real name,
address and any "firms of influence" for which it appears plausible
that they might have relevant patent interests, OpenISO.org promises
to not disclose this information to third parties as long as the
patent non-assertion covenants are not violated.


## Reflectivity ##

OpenISO.org is intended to be a reflective organization in the sense
that it should always strive for a good understanding of its own
processes in the light of relevant scientific research in the fields
of economics, organizational development and standardization.

The plan is to get started with generating some draft recommendations
and problem reports for some specifications that are worthy or not
worthy of being called a "standard".

However OpenISO.org intends to avoid moving anything from "draft"
status to "published" endorsement or problem report before there is
confidence in discuss@OpenISO.org Working-Group that OpenISO.org has
a sufficiently mature understanding of all important concerns and
attracts enough attention from interested parties that errors or
significant omissions are likely to get pointed out.

Here's a pointer to a book that might turn out to be useful as a
frame of reference in the evaluation of existing standardization
processes and in developing one which works well and robustly:

  Surowiecki, James (2004). The Wisdom of Crowds: Why the Many Are
  Smarter Than the Few and How Collective Wisdom Shapes Business,
  Economies, Societies and Nations Little, Brown ISBN 0-316-86173-1

For the development of guidelines and procedures for standardization
work it may be a good strategy to work mostly manually (without much
use of automated tools) initially, documenting workable procedures
as they emerge.  Procedures which appear to be in any way
untrustworthy are subject to the decision making principles of
OpenISO.org and can be challenged at any time.

## Document Licensing Policy ##

OpenISO.org publishes only documents for which all copyright holders
have granted permissions allowing everyone to redistribute the document
in original or modified form, under the terms of at least one of the
following licenses:
1. Creative Commons Attribution License,
2. Creative Commons Attribution Share-Alike License,
3. GNU Free Documentation License.

In the following, the term "acceptable license" shall mean any version
of any of the above-listed three licenses which has been published by
Creative Commons Corporation or by the Free Software Foundation,
respectively.

>From a licensing policy perspective, there are two distinct types of
documents:

1. Documents which are written from scratch within an OpenISO.org
  Working-Group.

2. Documents which an OpenISO.org develops my modifying a previously-
  existing document that is available to OpenISO.org under an
  acceptable license.

In the first case, OpenISO.org publishes the document with the
following legal notice:

> Permission is granted to copy, modify and redistribute this document
> under the terms of the Creative Commons Attribution 3.0 License.  In
> addition, permission is granted to copy, modify and redistribute this
> document under the terms of the GNU Free Documentation License,
> version 1.2.
> 
> THIS DOCUMENT IS PROVIDED BY OpenISO.org AND ALL AUTHORS AND
> CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
> BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL
> OpenISO.org OR ANY AUTHOR OR CONTRIBUTOR BE LIABLE FOR ANY DIRECT,
> INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
> STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
> IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.

In the second case, OpenISO.org publishes the document with a copy
of the notice, granting permission to copy, modify and redistribute
under the terms of an acceptable license, by means of which
OpenISO.org has received these rights.

In addition to this permissions notice, the following disclaimer
will be added:

> THIS DOCUMENT IS PROVIDED BY OpenISO.org AND ALL CONTRIBUTING
> OpenISO.org WORKING-GROUP MEMBERS "AS IS" AND ANY EXPRESS OR IMPLIED
> WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
> IN NO EVENT SHALL OpenISO.org OR ANY CONTRIBUTING OpenISO.org
> WORKING-GROUP MEMBER BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

In either case, the legal notice is placed at the end of the document.


-----------------------------------------------------------------------
Legal notice:

Permission is granted to copy, modify and redistribute this document
under the terms of the Creative Commons Attribution 3.0 License.  In
addition, permission is granted to copy, modify and redistribute this
document under the terms of the GNU Free Documentation License,
version 1.2.

THIS DOCUMENT IS PROVIDED BY OpenISO.org AND ALL AUTHORS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL
OpenISO.org OR ANY AUTHOR OR CONTRIBUTOR BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.