DocumentID: OI A200:draft2 ShortTitle: Core Guidelines LongTitle: OpenISO.org Core Guidelines Date: 2007-09-24, 2007-W39-1 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. 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.