A Few Standards Resources
Here's a few resources that might come in handy if you're interested in standards.
http://www.standardslearn.org/ - standards e-learning.
http://xml.coverpages.org/ - standards news and background.
http://www.talkstandards.com/ - standards background and analysis.
Patent Licensing Assurances in Standards Organizations
From a patent licensing perspective, most standards organizations are based on RAND principals. In other words, members are required to make their patents that are required to implement a specification available on reasonable and non-discriminatory terms.
Most standard organizations permit patent holders to charge royalties for their patents. Some, like W3C, require that those required patents be made available under RAND terms without royalty. This is often referred to as RAND-z (RAND with zero royalty) or RAND-RF (RAND Royalty Free). Still other organizations allow members to choose whether or not they will charge a royalty, or if they are willing to license their patents at all.
For example, the international standards setting organizations ITU-T, ITU-R, ISO, and IEC have adopted a common patent policy. Under this policy, a patent holder has the option to make its required patents available under 1 of 3 options, which I've paraphrased below.
- Under the 1st option, a patent holder agrees to grant licenses for patents required to implement the standard on RAND-z terms. The patent holder may also select defensive options for a) reciprocity and b) reserving the right to offer royalty bearing RAND terms to third parties who are only willing to license their required patents on royalty bearing RAND terms.
- Under the second option, a patent holder agrees to offer RAND terms for its required patents, with the option to condition the license grant on reciprocity.
- Under the third option, a patent holder can declare it is unwilling to grant licenses under the first two options.
These options allow a patent holder to declare the general licensing scheme it will offer its required patents under, but the actual patent licensing terms are left for the patent holders and users of the patents to determine outside of the standards body itself (the reasons for this warrant their own post, but license negotiations within standards bodies carry antitrust risk).
This does not mean, however, the standard participants are unaware of the terms that will be included in the actual patent license. Before the standard is formally adopted, interested parties can contact the patent holders to inquire about licensing terms and cost. Patent holders may also make their terms available in a number of ways, before or after a standard is adopted. Patent terms can be established through bilateral negotiations, cross licensing arrangements, patent pools, or the patent holder publicly posting its terms.
Even when a patent holder declares a necessary patent to a standards organization, it does not mean that the patent holder will necessarily set up a licensing program around that patent. Patent licensing programs are expensive and complicated to develop and maintain. Licenses need to be drafted, negotiations may need to occur, and an infrastructure needs to be developed to maintain the program. Also, companies often maintain patent portfolios for reasons other than royalty-based licensing, such as for defensive purposes and cross licensing.
The reality is that an extremely large percentage of RAND based patent declarations to standards bodies do not result in the patent holder seeking to actually license those patents to implementers. To be fair, the percentage of RAND based patent programs can differ greatly depending on the types of standards involved. For example, it's more common to see royalty based patent licensing around telecom standards than for Internet related standards. The percentage of formal licensing programs by standards participants around RAND-z declarations and standards is even lower (probably closer to the very low single digits, if that high). In spite of this, it is important for patent holders to retain the rights to require licenses in order to control and protect the value of their patents. Keep in mind that although a company may be making a commitment to make a patent available on a royalty free basis for a particular standard, it may still be charging royalties (or not licensing at all) in other contexts.
In the RAND-z standards space, even the most permissive RAND-z commitment has at times created tension with implementers, especially in the open source community. Even though the patent may be available without royalty, the license itself may include other terms that some believe are incompatible with certain open source licenses.
In response to these concerns, several companies, including Microsoft, are using a different approach to making their patents available for certain RAND-z standards. Rather than requiring parties to come to the patent holder to get a license to use the required patents, that patent holder agrees not to assert its patents as long as certain conditions are met. Essentially, rather than having to go to a patent holder to get permission in the form of a license to use the patent, the patent user automatically has the ability to use the patents available under the grant. The idea is that parties will be able to make use of the patents while still respecting the rights of the patent holders.
I'll be looking at how these grants work in another post.
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.