 |
privacy |
||
|
Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.
Blog Feed Recent Items 
The nfoCentrale Blog Conclave nfoCentrale Associated Sites |
2005-11-30Open Standards are not Open SourceIn discussions on the creation and use of public standards for document formats, there seems to be some cultivated confusion around what the actual conduct of standards-creating organizations is and how public specifications for industry standards are arrived at and used. I see blurring of the differences between specification of standards, the sometimes-open development of open-source software, and the creation and distribution of (open-source) software that conforms to a standard. To clarify how industry standards organizations operate in practice, I have compiled a summary of the four organizations that commonly figure in discussions of document-format standards: ISO, ECMA, OASIS, and the W3C. I have added IETF, my benchmark for open process, for comparison purposes. The summaries are in an appendix at the end of this article. Using Specifications of StandardsWithout exception, the specifications of standards are copyright by the issuing organization (and sometimes others). All rights are reserved. Without exception, there is no blanket permission to make derivative works of specifications. The W3C provides a license for creation of derivative works under specific conditions related to documenting, discussing, and explaining a specification. The OASIS OpenDocument specification carries a comparable limited permission that is specific to that document. Of course, the whole point of creating a standard is to have a fixed, shared specification for what it is. Allowing arbitrary derivatives and the prospect of “forking” a standard is not something that fits with the established approach to formal standardization. Those who want community-owned specifications to be as malleable as open-source software need to find an avenue that does not involve a formal standards-development organization. Using Schemas Provided with StandardsTypically, schemas are incorporated in the specifications, a practice that began with the specification of protocol and document data units in ISO specifications (Using Abstract Syntax Notation 1, ASN.1 and also various versions of Backus-Naur Form before that). In the case of schemas that can be used directly with software, the schemas of interest for office documents carry notices of copyright with all rights reserved. There are no blanket permissions for derivative works of any kind. It would appear that translating the RELAX NG schema for OpenDocument to an XML Schema might constitute creation of a derivative work, as would going in the reverse direction with the Microsoft Office 2003 XML Reference Schemas. It would be surprising for a complaint to arise in either case. Developing Software That Conforms to StandardsIt is customary for the specification of a standard to stipulate what constitutes conformance to the standard. There are often specific, measurable qualities involved. It is also customary, in the case of software, to specify aspects that are not constrained by the specification or that are left for resolution by individual implementations. These conditions establish what it means to claim that a software product conforms to the specification and can be important in specifying and selecting products for procurement. For specifications that involve computer software (e.g., programming languages and document formats), there are two levels of conformance that are important: (1) the conformance of data streams to the format and (2) the conforming behavior of processors when accepting and producing those data streams. For example, the OASIS OpenDocument specification section 1.5 provides definitions for conforming documents and for conforming applications. The definition for conforming document is straightforward and tolerates the presence of foreign extensions (proprietary or otherwise). The definition of conforming application does not specify a minimum set for document features that must be accepted and realized in conformance with the standard. Specifications that are realized by software are unlikely to specify or prohibit a particular software-development methodology or economic regime. Although some organizations introduce requirements for conformance certification, for labelling, and for technology licensing, that is not the model of the organizations appraised here. Patent Claims Against Implementation of StandardsIt is possible that the implementation of software that conforms to a standard may infringe on patented technology. All standards-promoting organizations are sensitive to this prospect. Although it is not possible to know for sure that no encumbering patent has been applied for or issued, all of the five organizations take steps to make sure that specifications can be implemented without infringing on essential claims of a known patent. In particular, the contributors to the specification must disclose any of their patents that may be applicable (and non-contributors are not so constrained, of course). If it is not possible to avoid patent infringement, each organization places conditions on availability of licenses so that the specification remains usable. The W3C requires that all applicable patents with essential claims have royalty-free licenses for implementations of the specification. For the other organizations, Reasonable and Non-Discriminatory (RAND) license terms are tolerated. For OASIS, an individual technical committee can specify whether the specifications it produces require royalty-free licenses or whether RAND terms are acceptable, or both. The OpenDocument Technical Committee operates under royalty-free requirements. In all cases the license is with respect to implementation of the specification and not with regard to any other software that may involve the patented technology. Compatibility of Specifications with Open-Source LicensesAlthough there are open documentation licenses, including the well-known Creative Commons licenses for copyrightable works, none of these standards organizations produce documents under such licenses. And, since the specifications are not software, open-source software licensing has little bearing. In general, these specifications must be considered to be neutral with regard to software development methodologies and licensing of software distributions and source code. The difficulty is with regard to any patent licensing and the form of license provided by individual (prospective) patent holders. Some licenses, even if royalty-free, may require explicit notice including notice of the limitations of applicability of the license. Some licenses, even if royalty-free, require explicit written application and issuance of the license. An example of this is the license provided by RSA Security Inc. with regard to implementations of the OASIS SAML Specification. The conditions on such licenses may limit public distribution of source code and may also prohibit sublicensing. Although requirements for notice of patent licenses and prohibitions on sublicensing, even when royalty-free, are considered inimical to use of the GNU Public License (GPL) in all of its forms, these requirements have an important practical purpose. They prevent the license from being adhered to software that does not implement the specification and they caution users of the source programs of the limitations surrounding the license. Open Processes in Specification of StandardsThere are varying degrees of of open-ness in how specifications for standards are produced. First, some standards-development activities are highly transparent and visible. IETF working groups are conducted in public and documented in public. OASIS working groups are documented in public although meeting and conference-call minutes are not necessarily detailed in their accounts of technical deliberations. W3C working groups preserve a public record, but it need not be public during development of the specification. ECMA and ISO have documentation requirements that are satisfied essentially internal to the subcommittee operations. With regard to participation and approval processes, there is greater variation among the organizations. With the exception of the IETF, which has open participation in working groups, the ability to participate in and influence the technical work is governed by membership requirements, attendance conditions, and the payments of appropriate fees. OASIS does provide a low-cost membership for un-affiliated individuals. The W3C may invite participation of experts and academics not affiliated with member organizations. The actual voting procedures vary at the technical working-group/subcommittee level. Approval of a specification for issuance is done above the level of individuals, involving member organizations. Inventing Versus RatifyingThe invention of standards by standards committees came in disrepute in the period of emergence and then deterioration of the Open Systems Integration suite of standards (under ISO) and the emergence of Internet standards (under IETF). It’s not as black-and-white as that, but it illustrates the different ways that standards arise. In some cases, one ratifies a specification that has been developed privately or by a small community. In this case there is an existing proposal that is refined to satisfy requirements for usability as a public standard. There is also some public interest to be served by having such a standard specification. There is usually an important industrial/commercial interest in having an agreed specification (for the production of audio cassette tapes and recordings, for example) that competitive products will be developed against. There may have been a private contribution (from Philips, in the example of audio cassettes) and the standard basically ratifies that contribution as a public specification. An important contribution of industry standards organizations, in this case, is avoiding any improprieties with regard to anti-trust and anti-competitive regulations. Many successful standards in computing and information technology began life as ratifications. In some cases there was need to reconcile divergent approaches, but the ratification process was for the purpose of providing a single foundation. This applies to programming-language standards and other protocols. The heavy work in development of a ratification is in abstracting and specifying the standard in a reusable way, stripped from any specific implementation that was the inspiration (but not so as to invalidate that implementation). Developing a solid specification is laborious even when little invention is required. There are also important invented standards in our field. The American Standard Code for Information Interchange (ASCII) was such a standard. It satisfied an important need and it did not ratify an existing code. ASCII’s descendant, Unicode, is also an invented standard developed and maintained by a consortium. The IETF is not adverse to inventing standards, although its stringent ratification process is dependent entirely on multiple, successful, interoperable implementations and stability over time. For ratification of a standard for a particular purpose, ECMA International is an appealing and experienced organization. It is an appropriate venue when the work involves creating and reconciling an usable specification of something that exists, such as an open, legacy-preserving format for Microsoft Office documents. This is different than a public effort to arrive at some sort of universal format or even a preferable format for new applications and new kinds of document interchange. OASIS and W3C may invent standards in an area of need. They may also accept proposals that are the basis for development and ratification of standards derived from existing implementations (as was the case with the OASIS Open Office XML Format committee, officially renamed OpenDocument in January 2005). Standards OrganizationsThis material is extracted from an extended analysis of the Microsoft Office XML and OpenDocument Format efforts.
|
||
|
You are navigating Orcmid's Lair. |
template
created 2004-06-17-20:01 -0700 (pdt)
by orcmid |