Open Specification Promise Video on Channel 9
Channel 9 has recently posted a video that gives additional information and background on Microsoft's Open Specification Promise. The video features Jean Paoli, co-creator of XML and General Manager of Interoperability & XML Architecture, Tom Robertson, General Manager of IP and Corporate Standards Strategy, and Amy Marasco, General Manager of Standards Strategy.
Microsoft, Google, and Yahoo! join together to support Sitemaps. A lot goes into these deals.
Microsoft, Yahoo!, and Google have just announced a joint initiative to improve search engine results by providing a single way for web operators to notify each search engine about website details. Lots of great posts on the announcement are up on Techmeme. My colleagues at Microsoft, Google, and Yahoo! also have posted about the arrangement.
A great deal of work took place to make this collaboration happen. It took business leadership from all sides, technical collaboration, PR, and, of course, the establishment of a legal framework. Over many weeks of negotiation, Microsoft, Google, and Yahoo! established how we would work together, ranging from how the Sitemaps website will be hosted to how we will improve the specification going forward to how we will make Sitemaps available to the community.
Community support is important for Sitemaps, so one of the primarily goals of this collaboration was make sure the legal terms and conditions would encourage adoption. This was one reason we are making the Sitemaps specification available under the Creative Commons Attribution-ShareAlike License (version 2.5). This is also the same Creative Commons license that Microsoft made its Simple List Extensions and Simple Sharing Extensions specifications under.
All in all, it's our hope that this collaboration will result in better and more efficient search results while also opening the door to future collaborations that help solve common problems among search engines and web operators for the benefit of the community.
In-House Counsel Blogs
Catherine Aman at Law.com recently wrote about in-house lawyers who are blogging. In addition to yours truly, she mentioned
- Mike Dillon at Sun
- Adam Golodner and Jeffrey Campbell at the Cisco High Tech Policy Blog
- David Munn at Fair Isaac Corporation.
- Jonathan Wilson at Web.com, Inc.
- Hanna Hasl-Kelchner of Lorillard Tobacco Company.
I've also recently found a copyright blog by Google's William Patry. Any other in-house counsel blogs out there?
What’s a Standard Anyway?
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.