I believe that the Open Source Initiative (OSI) has something called the Open Standard.
What is the Open Standard, and what is its purpose?
Open Source Stack Exchange is a question and answer site for people organizing, marketing or licensing open source development projects. It only takes a minute to sign up.
Sign up to join this communityI believe that the Open Source Initiative (OSI) has something called the Open Standard.
What is the Open Standard, and what is its purpose?
I would like to first make clear that the Open Source Initiative (OSI) doesn't actually define a standard. Instead, they say the following:
There are many definitions of "Open Standard". We don't try to define it ourselves, but we know that if you can't implement an Open Standard under an Open Source License, it's not open enough for us.
Basically, they've created something even better. That is, The Open Standard Requirement for Software.
Instead of creating a "One Size Fits All" standard, with a million and one clauses to effectively apply to everything, the Open Source Initiative needed to think of something simple, clean and innovative. Therefore, they made a requirement for standards. In essence, it’s a standard for open standards.
There are 5 points it must fulfill, contained within a single requirement: that an Open Standard may not prohibit any implementation that follows its rules. In order to comply with the Open Standards Requirement, the "Open Standard" must meet a set of 5 criteria, otherwise it will discriminate against Open Source Developers.
1. No Intentional Secrets
I'm just going to quote here…
The standard MUST NOT withhold any detail necessary for interoperable implementation. As flaws are inevitable, the standard MUST define a process for fixing flaws identified during implementation and interoperability testing and to incorporate said changes into a revised version or superseding version of the standard to be released under terms that do not violate the OSR.
In other words, an open standard can't keep anything from you. Everything must be stated clearly, and they can't sneak this little clause that will allow others to make 100 dollars on every dollar you make. Also, since there will always likely be things that need fixing, those little things to clarify, there must be a defined procedure in order to fix those flaws, and correct them to a newer version that will still not violate the criteria listed here.
2. Availability
This is pretty clear. Make sure that your standard is available, and make sure that people can access it without any issues. I won't put the Zizouz212 version -1 public license on my imaginary, private hosting service. It should be out and about with the public - that is, they should be able to find it, and get it. There’s a couple of other things:
3. Patents
If there are any patents that are essential to the implementation, there are two things that it must follow:
4. No Agreements
Essentially, I should be able to take it and use it. I shouldn't have to agree to any terms of use, any license clauses or anything like that. I'll quote again:
There MUST NOT be any requirement for execution of a license agreement, NDA, grant, click-through, or any other form of paperwork to deploy conforming implementations of the standard.
5. No Incompatible Open Standard Requirement Dependencies
For any implementation of the standard, the implementation should not have to rely on anything that doesn't conform to these requirements. In essence, everything that the standard needs must conform to whatever is in these requirements. Otherwise, it won't be "open" according to this.
I’m really going to quote on this now:
The purpose of an open standard is to increase the market for a technology by enabling potential consumers or suppliers of that technology to invest in it without having to either pay monopoly rent or fear litigation on trade secret, copyright, patent, or trademark causes of action. No standard can properly be described as "open" except to the extent it achieves these goals. The industry has learned by experience that the only software-related standards to fully achieve these goals are those which not only permit but encourage open-source implementations. Open-source implementations are a quality and honesty check for any open standard that might be implemented in software; whether an application programming interface, a hardware interface, a file format, a communication protocol, a specification of user interactions, or any other form of data interchange and program control. To help industry participants (suppliers, consumers, and regulators) identify and specify standards that permit open source implementations, the OSI has defined a minimal Open Standards Requirement (OSR). The OSI has also created a set of Criteria that can be used to judge whether a standard fully complies with that Requirement.
To add on to that, the Open Source Initiative felt the need to help create a guideline. With many legal authorities adopting "open standards" of their own into their respective laws. They viewed that the lack of guidelines made the term "open standard" more aspirational, rather than a practical and defining term. As a result, the rationale for their requirement was to rectify these problems.
The OSI defines two levels of compliance, in an effort to assist the development of standards that conform to the requirement. This is similar to the way that the OSI approves licenses to be Open Source.
OSI Compatible
This is a mark that is provided to creators that have self-certified their license is conformant to the requirement listed above. If the OSI, at anytime, deems the standard to be incompatible, the creator must modify the standard for it to be compatible, or remove the mark altogether.
OSI Conformant
This is a mark that shows the OSI has deemed the standard to be conformant to the requirement listed above.
Sources/References/Good Reads: