[OpenISO] OpenISO.org Core Guidelines - draft2

[Norbert Bollow]

I've tried to take the various comments (thanks to everyone again!)
into account and created a new "Core Guidelines" draft:
http://openiso.org/OI/A200:draft2

See below for a diff.

Greetings,
Norbert

--- A200:draft1	2007-09-10 17:22:17.000000000 +0200
+++ A200:draft2	2007-09-24 17:02:27.000000000 +0200
@@ -1,7 +1,7 @@
-DocumentID: OI A200:draft1
+DocumentID: OI A200:draft2
 ShortTitle: Core Guidelines
 LongTitle: OpenISO.org Core Guidelines
-Date: 2007-09-10
+Date: 2007-09-24, 2007-W39-1
 Working-Group: discuss at OpenISO.org
 Editor: Norbert Bollow
 About: OpenISO.org
@@ -28,7 +28,7 @@
 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 evluation process a rating is
+criteria for standards, during the evaluation process a rating is
 assigned to each specification.
 
 This rating is one of the following:
@@ -41,7 +41,7 @@
 
 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 approve
+in some contexts", "recommended" or "strongly recommended" are approved
 as standards.
 
 If after completion of OpenISO.org's evaluation of a specification
@@ -52,11 +52,36 @@
 
 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 evulation.  It is also possible
+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
@@ -77,7 +102,7 @@
 Working-Group mailing-lists becomes so intense that the sheer volume
 of the traffic becomes an obstacle to productivity.
 
-All Working-Group decisions must be justified in writing.
+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,
@@ -103,41 +128,91 @@
 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 company like Microsoft can prevent any
+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 disgreements which
-cannot be resolved by means of Working-Group consensus processes must
+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.
+the relevant facts, as described below in the section on dispute
+resolution.
 
-Every decision must be justified in writing.
+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.
 
-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 and maturity requirements are fulfilled.
 
 Openness requirements will include that there should be no patent
 issues etc.
 
-Maturity requirements include that there should be a BSD-, Apache- or
-LGPL-licensed reference implementation 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
-must in that respect be at least as good as the pre-existing standard.
+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
@@ -152,21 +227,21 @@
 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
+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
-DRPP and never anymore give it any business if it is ever found to be
-in violation of the contracture requirement to provide an excellent
+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,
-recouse to Switerzland's well-developed court system is also possible.
-Therefore, a very trustworthy assurance of intergrity can be achieved
+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
@@ -196,7 +271,7 @@
 
 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 und
+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
@@ -210,17 +285,62 @@
 integrity of the decision-making processes.
 
 
-## Requirements for Working-Group Participation ##
+### Dispute-resolution process example ###
 
-### Patent Non-Assertion Convenants Requirement ###
+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.
 
 
-Every participant in an OpenISO.org Working-Group must disclose
-whether this is done on behalf of, by request of, or while getting
-paid by an organization.
+## 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.
 
-Participation in the discuss at OpenISO.org Working-Group does not
-require execution of a patent covenant.
+The big exception to this rule is the discuss at OpenISO.org
+Working-Group where such covenants are not required.
 
 However, when subgroups of the discuss at OpenISO.org Working-Group
 are created, for each such subgroup a "List of specifications"
@@ -245,31 +365,43 @@
 > 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 employer (if any), and must provide the required patent
-non-assertion convenants, OpenISO.org promises to not disclose this
-information to third parties as long as the patent non-assertion
-convenants are not violated.
-
-
-## Commitment to Free Software ##
-
-The software which OpenISO.org will use must be "open" publicly
-available Free Software.  The reason for this is as follows: When
-the  software which a standardization organization uses to implement
-its workflow is proprietary (is this the case with the "livelink"
-system used by ISO?) that has the effect of creating a form of
-lock-in to the standardization organization which at odds with the
-fundamental principle of openness that is so important for legitimate
-standardization processes:  Whenever a group of people feel that their
-concerns and views are not properly taken into account by the existing
-standardization organizations, they must have the freedom to fork the
-standardization process to create their own specification,
-endorsement, problem report or amendment documents.
+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 ##
@@ -303,5 +435,97 @@
 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
-OpenSO.org and can be challenged at any time.
+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.