The RSS Controversy
There's been a lot of blog posts in the last several days regarding Microsoft's filing of RSS related patents. Despite many negative posts, Don Dodge and Techdirt have provided a balancing perspective. While I am not a patent attorney and have no familiarity with these patents other than what I've read on other blogs, I am very familiar with Microsoft's approach to patents.
Microsoft, like many technology companies such as IBM and Sun, files a larger number of patents every year. Patents serve a number of purposes, including protecting valuable research, licensing to third parties, cross licensing, and defensive reasons. What is exceedingly uncommon, however, is for Microsoft to use its patents offensively. In fact, while I am not aware of any offensive patent action by Microsoft in recent memory, Microsoft itself is the constant target of patent claims.
While the general tone of many posts on this matter is distrust of Microsoft, I think it's important to look at how Microsoft actually makes its patents available. I've written about Microsoft's Open Specification Promise in the past, and I think it is a great example of how Microsoft is making it's patents for select standards available to the community at no charge.
In the RSS space, Microsoft has created the Simple Sharing Extensions for RSS and OPML. Microsoft made this RSS extension available under a Creative Commons License and agreed to license it's patents that are infringed by the specification, if any, under royalty free terms. This actually goes beyond the licensing terms of RSS itself, which provides a copyright license under a Creative Commons license but offers no patent assurances at all.
Overall, if you look at Microsoft's track record in the patent space, it simply does not support claims that Microsoft is going to use these patent claims offensively.
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.
Sender ID added to Microsoft’s Open Specification Promise
Microsoft today announced that the four specifications that make up Sender ID are being made available under Microsoft's Open Specification Promise (OSP). Jason and Brent have comments on the announcement and how making Sender ID patents available under the OSP fits into Microsoft's approach to interoperability.
Standards usually don't make the front page of the Washington Post, but Sender ID did. For that reason alone, Sender ID is not your everyday standard. The hope behind Sender ID was to provide a widely deployed system to authenticate email. When Sender ID was brought to the IETF, Microsoft, in accordance with IETF polices, disclosed the existence of its pending patent claims. Microsoft also agreed to license its patent claims on the Sender ID specification on reasonable and nondiscriminatory terms without royalty.
It's important to point out that this disclosure went beyond IETF requirements, which require patents be disclosed but does not prohibit licensing on a royalty basis. Microsoft's intent was to foster the wide adoption of the Sender ID specification by offering its necessary patents to implementers at no charge or royalty. Microsoft's royalty free terms, however, were met with opposition primarily from the open source community. Despite this opposition, more than 5 million domain holders have adopted Sender ID.
The reason I bring up this history is to show how Microsoft's approach to standards licensing is evolving. When Microsoft offered to make its necessary patents available to Sender ID implementers on royalty free RAND terms, Microsoft was in fact making its patents available under one of its most permissive licensing approaches (and one that was never, to my knowledge, greeted with the kind of opposition it received at the IETF, home of many royalty based standards). To be clear, Microsoft's goal was to license its technology in a manner that would encourage adoption. Since that time, Microsoft has spent a great amount of effort refining its standards licensing approaches and working with the community to find new approaches to standards based licensing. One result of that process has been Microsoft's adoption of the OSP - an approach that was not available to Microsoft when Sender ID was brought to the IETF.
Although the application of the OSP to Sender ID has been warmly received (as has the OSP's application to certain WS specs and the Virtual Hard Disk Image Format Specification), a comment by Rich Jennings about Sender ID and the OSP caught my attention.
As far as I can tell, nothing has changed. There's no news here. Move along.
This promise seems to be exactly the same promise as was made by Microsoft in 2004. It's a promise that didn't prevent the MARID working group from failing to reach consensus -- mainly due to deadlock over the IP issue.
Although I've posted about the OSP before, I think it's important to emphasize that the OSP is in fact a different approach to standards licensing than royalty free RAND licensing. A royalty free RAND license, despite being free, does require implementers to actually obtain that license. The OSP does not require an implementer to come to Microsoft for that license. This also removes issues related to sublicensing, which is of concern to the open source community, since the OSP extends directly to each user of the spec. These are a few of the several reasons why the OSP has received the support of companies including Red Hat and SendMail. It's Microsoft's hope that the OSP's application to Sender ID will in fact resolve lingering IP licensing issues related to Sender ID.
DDEX Announces its Standards
The Digital Data Exchange, also known as DDEX, just announced the establishment of its first four standards. DDEX is an organization that establishes music meta data standards to enable more efficient exchanges of music related data. This includes information not only about the content, but also information that helps transaction processing between participants in the digital music supply chain.
DDEX board members include a wide range of companies involved in the music ecosystem such as EMI Music, SONY BMG MUSIC ENTERTAINMENT, Warner Music Group, Universal Music Group, The American Society of Composers, Authors and Publishers (ASCAP), The Harry Fox Agency Inc. (HFA), The MCPS-PRS Alliance Limited, Sociedad General de Autores y Editores, AOL, LLC, Apple Computer Inc., Microsoft Corporation and RealNetworks Inc. More information about DDEX can be found at its website.
I've had the opportunity to work with DDEX and its members from the founding stages of the organization almost a year ago. During this relatively short time, we've established the underpinnings of the organization, including the corporate structure and Intellectual Property Rights Policy, and completed the first set of standards.
DDEX is a great example of a standards organization done right. It was established to solve a set of common problems among members of the digital music supply chain. Prior to DDEX, digital service providers, labels, and rights societies used different systems to communicate music related data. The result was a tower of babel that required each party in the chain to maintain multiple systems at great expense. The lack of common communication mechanisms made it difficult to leverage existing infrastructures to provide new music related offerings to consumers. Transaction costs were also high since any change to the existing individual formats required one off negotiations and technical implementations.
By agreeing to implement a common meta data standard, each DDEX implementer can communicate in a more efficient way and provide more and higher quality services to end users. At the same time, implementers can rely upon the base DDEX standards for common, cross industry tasks while maintaining the ability to innovate on top of the DDEX standards. The outcome is extremely pro-competitive, providing benefits to implementers and consumers.
Back from the DVD CCA
I'm currently airborne flying back from a DVD CCA meeting in LA. The DVD CCA is the licensing body that determines how protected content on DVD discs can be used and what types of features can be included in DVD players for computers and consumer electronic devices.
By way of background, the DVD CCA is a rather unique organization. Though DVD CCA resembles a standards body in many ways, it doesn't generally establish technical specifications. Rather, the DVD CCA is responsible for licensing the Content Scrambling System to implementers, which is licensed to the DVD CCA by CSS's owners and developers, MEI and Toshiba.
The DVD CCA is comprised of companies from the motion picture, consumer electronics, and computer industries. For any changes to be made to the CSS rules, all three industries must agree to the changes. As you can imagine, achieving changes, improvements, and new business models in DVD CCA requires a great deal of compromise. It's a challenging and often fruitless exercise for all involved. It demands a large amount of resources to engage. It's also an incredibly time consuming process where success is measured in inches and rarely in feet.
DVDs have been one of the most successful consumer electronic products in history. There has been no other consumer electronic device that has achieved such a high rate of adoption in such a short period. DVD sales have also propelled content industry sales - from old and new releases to television shows.
With all that success, however, there is something that you haven't seen from DVD CCA lately, and that's innovation. Because of its governance structure and the competing interests of its participants, DVDs have been largely stagnate.
The DVD CSS system has been completely broken and the enthusiast community has developed compelling, polished, and unsanctioned applications that include DVD jukeboxes and enhanced quality outputs. At the same time, legitimate CSS implementers cannot match these innovations since they are bound by the CSS rules.
The point is that industry standards can be a double edged sword. They can lay the groundwork for widespread consumer adoption, but they can also slow or prevent progress. DVDs will be with us forthe foreseeable future, but without innovation, DVDs will in time be replaced with systems and business models that better meet new consumer expectations.
The Role of the Patent Trolls
On Wednesday, the Financial Times published a piece by Alan Cane called Trolls control the rickety-rackety bridge of intellectual property. In the article, Mr. Cane points to the cost of patents in products and draws attention to patent trolls that "participate in or monitor standards-setting processes without revealing, until it is too late, that they hold patents essential to the standard." While he finds that these activities can be problematic, he concludes by saying that "[p]atents are property and can be bought and sold. There is nothing wrong with holding an asset from which you hope to profit."
Although patent trolls can pose problems within standards bodies, they are a far greater problem outside of a standards body than if they are a member. Most standards organizations are based on RAND concepts, but each has a different set of rules governing its operations. Those rules are generally designed for the particular standards context and the types of activities that the organization engages in.
For example, some standards organizations require that their members positively disclose any necessary patents they may have. Other organizations require members to only notify the organization of any necessary patents that they are unwilling to license on RAND terms. Without debating the merits of each approach here, the important point is that these obligations are imposed upon members of the standards organization. To go back to a point I made in an earlier post, standards members generally cannot refuse to grant a necessary patent license, and that license must be on reasonable and non-discriminatory terms. Even patent trolls that are standards organization members are bound by this obligation.
Although disputes can and do arise as to whether patent licensing terms are indeed reasonable and non-discriminatory, those disputes are exceedingly rare. There are hundreds of RAND based standards organizations, which publish thousands of standards, which are implemented in millions of products. Yet the number of cases brought each year over RAND licensing terms can usually be counted on your fingers.
It's also important to keep in mind that even in the standards context, patent licensors operate in the marketplace. If their patent royalties are too high, the market will not adopt the standard and the patent owners will not make money. That pressure tends to result in patents being reasonably valued. In the patent pool process, it's very common for the pools to lower their fees in response to market forces.
Despite a handful of high profile issues with patent holding standards members, the problems with patent trolls tend to arise outside, rather than inside, standards bodies.
Legal Overlord? I Prefer Benevolent Counsel
James Governor, an analyst with RedMonk, has welcomed the new Legal Overlords to the conversation, for which I thank him. I absolutely agree with James that lawyers need to be part of the conversation.
There seems to be a perception that standards are developed by groups of engineers working in harmony to reach the optimum technical solutions. The reality is that standards are venues for both cooperation and competition between rival interests. Making a standard successful in this environment often requires the involvement of individuals from many disciplines. Technology, business, and legal must all work together to ensure that the right technology is solving the right business problem using the right legal framework.
Lawyers play an important role in this process. In some standards bodies, the only thing that is perhaps more complicated than the technology is the legal framework that governs it.
As several of James's commenters noted, lawyers have certain constraints when speaking publicly that others do not. As a lawyer, I have legal and ethical responsibilities to my client, Microsoft, and often to the standards bodies I work with. These obligations will guide my writings on this blog. This isn't a fine line test. Rather, if there is a topic that can even be remotely construed as interfering with my legal and ethical obligations, I simply won't discuss it.
While smart minds can differ on a conclusion, it's important that the conclusion is founded on appropriate facts, background, and knowledge. It's my goal that through this blog I can provide a legal perspective and background to the standards conversation. That leaves us with lots to talk about.