Since this is a blog about standards law, it’s worthwhile to talk about what a standard is in the first place. Standards can cover a wide range of activities, from business practices to safety standards and everything in between. Each year, thousands of standards are adopted and revised that impact almost everything we interact with. What I focus on is software related standards, which I generally consider to be the following:
A technical specification that enables interoperability between different products and services and is either 1) intended for widespread industry adoption or 2) has achieved wide spread industry adoption.
The ultimate purpose of a software standard is to enable interoperability between different products and services. If there is no need for interoperability, there is little if any need for a common standard. The point of a standard is to make it possible for devices and services from different providers to work together. This also makes most standards pro-competitive since multiple parties can create products that compete in the market for the benefit of consumers.
Software standards generally include things like software interface specifications, audio/video codec specifications, and file formats and schema. It’s worth emphasizing that these standards generally are platform/language agnostic. That is, those specifications don’t generally define how the standard is implemented. Rather, the standard defines the elements necessary for interoperability. It should be irrelevant whether a standard implementer programs to the standard in Java, C#, Ruby, or Assembly language as long the output of that implementation conforms to the standard. For example, the standard for a document format will describe the attributes of that format, but it won’t describe how the tools that actually generate or read the files operate. That’s a role for product designers and coders. Some of those tools will be better than others (faster, easier to use, etc.), but as long as the file that is actually generated conforms to the standard, interoperability is maintained.
To build off the last point, a software standard should also not define user interfaces. It’s important that implementers have the ability to innovate with their products. For example, it might make sense to have a standard to define how television program guides exchange TV program data, but it’s better to let Tivo, Microsoft, Comcast, etc. compete on how they actually display that information to the user. Some of those interfaces are better than others, but those choices should be made by implementers, not standards bodies.
Another important element of successful standards is that the standard is scoped properly. A standard should only specify what’s required for interoperability within the standard’s intended purpose. This is a balancing act. If you don’t standardize enough, the standard won’t meet its interoperability goals and won’t be adopted. If you standardize too much, there is no room for implementers to innovate on top of the standard and add value to their own products (not to mention that the standards development process will get bogged down as each participant tries to either include their pet feature or commoditize its competitor’s products).
To give an example of scoping a technical specification, I’ll use the DDEX standards that I wrote about previously. DDEX defines a technical schema for exchanging music related meta data among participants in the music value chain. These participants include labels, rights societies, and service providers. That data can include things like artist data, album information, and other information that is of common interest to participants in the music value chain. In other words, the DDEX standards provide all DDEX members with a baseline for music meta data exchanges.
DDEX members are free, however, to innovate on top of the standard. For instance, if two DDEX members wanted to innovate on top of the DDEX standard by exchanging karaoke data, which isn’t included in the DDEX standard, they are free to add karaoke related information to their DDEX data exchange even though DDEX has not defined that type of data. This would constitute a proprietary extension to the DDEX standard, which is fine so long as it doesn’t interfere with the standardized portions of the DDEX standard. If enough DDEX members were interested in karaoke data, it could eventually be added the overall DDEX standard. What’s important here is that the standard doesn’t limit participants from innovating and offering new and unique services. A standard simply cannot, and should not, define every potential use of that standard.