- <item>
- <title>The many definitions of a open standard</title>
- <link>http://people.skolelinux.org/pere/blog/The_many_definitions_of_a_open_standard.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/The_many_definitions_of_a_open_standard.html</guid>
- <pubDate>Mon, 27 Dec 2010 14:45:00 +0100</pubDate>
- <description>
-<p>One of the reasons I like the Digistan definition of
-"<a href="http://www.digistan.org/open-standard:definition">Free and
-Open Standard</a>" is that this is a new term, and thus the meaning of
-the term has been decided by Digistan. The term "Open Standard" has
-become so misunderstood that it is no longer very useful when talking
-about standards. One end up discussing which definition is the best
-one and with such frame the only one gaining are the proponents of
-de-facto standards and proprietary solutions.</p>
-
-<p>But to give us an idea about the diversity of definitions of open
-standards, here are a few that I know about. This list is not
-complete, but can be a starting point for those that want to do a
-complete survey. More definitions are available on the
-<a href="http://en.wikipedia.org/wiki/Open_standard">wikipedia
-page</a>.</p>
-
-<p>First off is my favourite, the definition from the European
-Interoperability Framework version 1.0. Really sad to notice that BSA
-and others has succeeded in getting it removed from version 2.0 of the
-framework by stacking the committee drafting the new version with
-their own people. Anyway, the definition is still available and it
-include the key properties needed to make sure everyone can use a
-specification on equal terms.</p>
-
-<blockquote>
-
-<p>The following are the minimal characteristics that a specification
-and its attendant documents must have in order to be considered an
-open standard:</p>
-
-<ul>
-
-<li>The standard is adopted and will be maintained by a not-for-profit
-organisation, and its ongoing development occurs on the basis of an
-open decision-making procedure available to all interested parties
-(consensus or majority decision etc.).</li>
-
-<li>The standard has been published and the standard specification
-document is available either freely or at a nominal charge. It must be
-permissible to all to copy, distribute and use it for no fee or at a
-nominal fee.</li>
-
-<li>The intellectual property - i.e. patents possibly present - of
-(parts of) the standard is made irrevocably available on a royalty-
-free basis.</li>
-
-<li>There are no constraints on the re-use of the standard.</li>
-
-</ul>
-</blockquote>
-
-<p>Another one originates from my friends over at
-<a href="http://www.dkuug.dk/">DKUUG</a>, who coined and gathered
-support for <a href="http://www.aaben-standard.dk/">this
-definition</a> in 2004. It even made it into the Danish parlament as
-<a href="http://www.ft.dk/dokumenter/tingdok.aspx?/samling/20051/beslutningsforslag/B103/som_fremsat.htm">their
-definition of a open standard</a>. Another from a different part of
-the Danish government is available from the wikipedia page.</p>
-
-<blockquote>
-
-<p>En åben standard opfylder følgende krav:</p>
-
-<ol>
-
-<li>Veldokumenteret med den fuldstændige specifikation offentligt
-tilgængelig.</li>
-
-<li>Frit implementerbar uden økonomiske, politiske eller juridiske
-begrænsninger på implementation og anvendelse.</li>
-
-<li>Standardiseret og vedligeholdt i et åbent forum (en såkaldt
-"standardiseringsorganisation") via en åben proces.</li>
-
-</ol>
-
-</blockquote>
-
-<p>Then there is <a href="http://www.fsfe.org/projects/os/def.html">the
-definition</a> from Free Software Foundation Europe.</p>
-
-<blockquote>
-
-<p>An Open Standard refers to a format or protocol that is</p>
-
-<ol>
-
-<li>subject to full public assessment and use without constraints in a
-manner equally available to all parties;</li>
-
-<li>without any components or extensions that have dependencies on
-formats or protocols that do not meet the definition of an Open
-Standard themselves;</li>
-
-<li>free from legal or technical clauses that limit its utilisation by
-any party or in any business model;</li>
-
-<li>managed and further developed independently of any single vendor
-in a process open to the equal participation of competitors and third
-parties;</li>
-
-<li>available in multiple complete implementations by competing
-vendors, or as a complete implementation equally available to all
-parties.</li>
-
-</ol>
-
-</blockquote>
-
-<p>A long time ago, SUN Microsystems, now bought by Oracle, created
-its
-<a href="http://blogs.sun.com/dennisding/resource/Open%20Standard%20Definition.pdf">Open
-Standards Checklist</a> with a fairly detailed description.</p>
-
-<blockquote>
-<p>Creation and Management of an Open Standard
-
-<ul>
-
-<li>Its development and management process must be collaborative and
- democratic:
-
- <ul>
-
- <li>Participation must be accessible to all those who wish to
- participate and can meet fair and reasonable criteria
- imposed by the organization under which it is developed
- and managed.</li>
-
- <li>The processes must be documented and, through a known
- method, can be changed through input from all
- participants.</li>
-
- <li>The process must be based on formal and binding commitments for
- the disclosure and licensing of intellectual property rights.</li>
-
- <li>Development and management should strive for consensus,
- and an appeals process must be clearly outlined.</li>
-
- <li>The standard specification must be open to extensive
- public review at least once in its life-cycle, with
- comments duly discussed and acted upon, if required.</li>
-
- </ul>
-
-</li>
-
-</ul>
-
-<p>Use and Licensing of an Open Standard</p>
-<ul>
-
-<li>The standard must describe an interface, not an implementation,
- and the industry must be capable of creating multiple, competing
- implementations to the interface described in the standard without
- undue or restrictive constraints. Interfaces include APIs,
- protocols, schemas, data formats and their encoding.</li>
-
-<li> The standard must not contain any proprietary "hooks" that create
- a technical or economic barriers</li>
-
-<li>Faithful implementations of the standard must
- interoperate. Interoperability means the ability of a computer
- program to communicate and exchange information with other computer
- programs and mutually to use the information which has been
- exchanged. This includes the ability to use, convert, or exchange
- file formats, protocols, schemas, interface information or
- conventions, so as to permit the computer program to work with other
- computer programs and users in all the ways in which they are
- intended to function.</li>
-
-<li>It must be permissible for anyone to copy, distribute and read the
- standard for a nominal fee, or even no fee. If there is a fee, it
- must be low enough to not preclude widespread use.</li>
-
-<li>It must be possible for anyone to obtain free (no royalties or
- fees; also known as "royalty free"), worldwide, non-exclusive and
- perpetual licenses to all essential patent claims to make, use and
- sell products based on the standard. The only exceptions are
- terminations per the reciprocity and defensive suspension terms
- outlined below. Essential patent claims include pending, unpublished
- patents, published patents, and patent applications. The license is
- only for the exact scope of the standard in question.
-
- <ul>
-
- <li> May be conditioned only on reciprocal licenses to any of
- licensees' patent claims essential to practice that standard
- (also known as a reciprocity clause)</li>
-
- <li> May be terminated as to any licensee who sues the licensor
- or any other licensee for infringement of patent claims
- essential to practice that standard (also known as a
- "defensive suspension" clause)</li>
-
- <li> The same licensing terms are available to every potential
- licensor</li>
-
- </ul>
-</li>
-
-<li>The licensing terms of an open standards must not preclude
- implementations of that standard under open source licensing terms
- or restricted licensing terms</li>
-
-</ul>
-
-</blockquote>
-
-<p>It is said that one of the nice things about standards is that
-there are so many of them. As you can see, the same holds true for
-open standard definitions. Most of the definitions have a lot in
-common, and it is not really controversial what properties a open
-standard should have, but the diversity of definitions have made it
-possible for those that want to avoid a level marked field and real
-competition to downplay the significance of open standards. I hope we
-can turn this tide by focusing on the advantages of Free and Open
-Standards.</p>
-</description>
- </item>
-
projects / homepage.git / commitdiff