Marrying Open Standards and Open Source
This post was first published on 16th February, 2011.
Standards can either be open or closed based on the manner of their creation and their accessibility to the public. A standard that is created through public or community participation without any restrictions and can be used or implemented by any one are called open standards. A standard that is developed by and limited to one or more persons is a closed standard. All proprietary standards are closed standards.
The basic tenets of open source software are availability of source code, rights to copy, modify and distribute the software, movement of license along with software and so on. The objectives of open source and open standards are at two different levels though both are based on openness. However, with the increasing importance of open standards, the interface between open source and open standards has gained great interest. Many efforts today are aimed at reconciling the interests of open source in open standards.
An open standard may have either a proprietary or an open source implementation. One example is the implementation of HTML standards in the form of Internet Explorer, a Proprietary implementation and Netscape Navigator, an Open Source implementation. Depending on intellectual property protection in open standards and flexibilities for their implementation, they may or may not enable OSS Compliance. For example, an open standard that is available for a patent royalty would not comply with many open source licenses because most licenses require grant of patent rights, royalty free distribution and transfer of rights to subsequent licensees, which cannot be easily accomplished.For example, most IEEE standards would not enable OSS License compliance.
In an attempt towards enabling creation of open standards that comply with open source objectives, the Open Source Initiative has defined the Open Standard Requirement. Compliance with the requirement will automatically bring about compliance with Open Source Licenses. The requirement requires every standard to meet the following conditions:
a. No Secrecy – No information with respect to interoperability must be kept secret or confidential;
b. Availability – The standard must be available to the public from a reliable source on a royalty-free basis;
c. Patents – The standards must not require patent royalty or allow assertion of patents;
d. Agreements – The standard must not require acceptance or execution of agreements; and
e. Dependancies: The standard must not have dependancies on specific technologies or systems.
If an open standard satisfies all the afore-said requisites it is said to be Open Standard Requirement (OSR) Compatible. If the Open Source Initiative approves the standard, it is said to be OSR Confirmant. An open source software created under such a standard will not have issues of compliance with the license.
Image form Wikimedia Commons