Introducing the Open Web Foundation Agreement
After a little more than a year, the Open Web Foundation has just announced its agreement for Specifications. Having worked with the Open Web Foundation on the legal committee and on the board, I am extremely proud of this accomplishment, which involved the efforts of a number of individuals from a variety of backgrounds, philosophies, and companies. Special thanks go out to Eran Hammer-Lahav, Lawrence Rosen, David Recordon, DeWitt Clinton, and Stephan Wagner for all their hard work to get the agreement and the organization to this point.
The Open Web Foundation was formed to address the needs of the growing communities that are developing specifications outside of the traditional standards process. Communities involved in developing specifications such as OpenID, OpenSocial, and OAuth each began without legal structures in place and found that they couldn’t achieve widespread adoption without agreements to establish the legal terms around their specifications. Both OpenID and OpenSocial spent a great deal of time and energy (and attorney fees) forming new foundations for their specifications. OAuth spent many months negotiating its agreement after the specification itself was done. As more and more projects like these started to emerge, it became apparent that there needed to be a way to streamline the process of getting the legal and intellectual property agreements in place. The Open Web Foundation was formed to offer at least one solution to this problem.
At its core, the Open Web Foundation is developing a set of agreements that individual specification development communities can apply to their own projects. This is done independently of the Open Web Foundation itself. Just as anyone can apply a Creative Commons copyright license to their written work without Creative Commons being involved, specification developers can choose to use the Open Web Foundation agreement for their own projects without the Open Web Foundation being involved. In other words, the Open Web Foundation isn’t a standards body, but it does help specification developers handle the intellectual property issues that are vital to help gain the widespread adoption of the technologies they develop.
The Open Web Foundation is not a replacement for traditional standards bodies, but it is intended to be complementary. One of the core philosophies behind the Open Web Foundation agreement was to enable to the transition of specifications under the Open Web Foundation agreement to traditional standards bodies. It does so by establishing copyright and patent grants that are intended to be compatible with established standards development organizations.
How the Agreement Works
Needless to say, you should seek your own legal advice when considering using the Open Web Foundation agreement, or OWFa, and this should not be considered legal advice.
The agreement, which is applied a particular version of a specification, is short (about 2 pages) and lightweight. Unlike traditional agreements governing standards, the agreement does not establish any formal rules around governance, voting, or operational issues. The Open Web Foundation leaves that for each specification development community to establish on their own. What it does concentrate on is intellectual property.
For copyright, signatories grant a broad copyright grant to the world, including the right to create derivative works. If you make a derivative work, you need to provide attribution to the original specification.
The patent grant offers implementers two options. The first is a royalty free patent non-assert, where signatories agree not to assert their necessary patent claims against implementers of the specification. It also includes defensive terms intended to protect the ecosystem that has implemented the specification. The other patent option is a more traditional standards licensing approach, where the signatory commits, upon request, to make to make their necessary patent claims that cover an implementation of the specification available on royalty free terms that are reasonable and non-discriminatory. The actual terms of that agreement are left to the parties to work out on their own.
Even though we’ve tried to make the agreement easy to understand, we’ve tried to make it even more understandable by creating a Creative Commons inspired “deed,” included below, that provides a high level summary of the agreement. While you should always read and understand the full agreement, this gives a good, non-legally binding overview.
Open Web Foundation Agreement “Deed”
What You Give and What You and the Community Get
You Give Everyone:
- Copyright - a free license to use the copyrights in your contributions.
- Patent - free rights to use your necessary patent claims to implement the specification.
You and the Community are free:
- to Share - to copy and distribute the specification.
- to Revise the Specification - to make new versions of the specification.
- to Implement – to use the signatories’ necessary patent claims to make, use, sell, offer for sale, import, or distribute any implementation of the covered specification.
Under the following conditions:
- Revise the Specification - If you make new versions of the specification
- you must include attribution to the original specification (but not in any way that suggests that they endorse you or your use of the work).
- you don’t get any rights under the agreement to anything new that you add.
- you must maintain the required portions of the original specification if you want to continue to take advantage of the patent grant.
- Non-Defensive Legal Action - If you take non-defensive patent legal action against another implementer of the same specification, you lose any rights you received for the same specification under the agreement from everyone who signed the agreement.
Next Steps
The OWFa is really the first step in the overall OWF process. Next, the OWF will start to develop a variety of contributor license agreements. These agreements will be signed before someone participates in a spec development effort. I would expect that there will be a variety of these contributor license agreements, but each will lead to a specification covered by the OWFa. For example, there may be contributor license agreements that cover only copyright, others may include some sort of up front patent grant, some may include governance rules, etc. This is intended to be a flexible upfront approach that allows communities to choose the way they work while helping to assure a consistent outcome across OWFa covered projects in the end.
Ultimately, the OWF’s goal is to build a legally sound structure for its target specification development communities, and the Board’s approval of the agreement for final specifications is a great start.
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.
HD Photo Submitted for Standardization
Microsoft has started the process of standardizing HD Photo. Today, the Joint Photographic Expert Group (JPEG) announced a new work item around Microsoft’s HD Photo submission, which will tentatively be called JPEG XR.
It’s Microsoft’s intention to help ensure that, once standardized, JPEG XR will be widely adopted and deployed. To that end, Microsoft submitted HD Photo to JPEG for standardization with the commitment to make royalty free grants for its patents that are required to implement the standard.
Another Specification Available Under the Open Specification Promise
I have the opportunity to work with a number of different groups at Microsoft. Recently, I’ve been working with the folks in Microsoft Research on the release of the Decentralized Software Services Protocol (DSSP) protocol, which is used in Microsoft Robotics Studio. Notably, Microsoft has added DSSP to the list of specifications available under the Open Specification Promise. With this addition, Microsoft makes its patents available under the OSP for 47 specifications.
Standards Law Link Blog Added
Posting has been slow lately, but I am working on a couple of entries. In the meantime, I've added a standards law link blog that will include standards related news from around the web.
Floor Lamps are Not Software
IBM's Rob Weir wrote a nice piece about the standardization of electrical fixtures and the benefits those standards bring to consumers.
In fact, far from constraining choice, standards enable greater choice. Because the basic plugs, receptors and connectors are governed by standards, these core components have become commodities and are produced off-shore at low cost to you, the consumer. This causes lighting designers and manufacturers to compete on the basis of style, elegance, utility and features. So standards result in lower cost, greater competition and greater choice for the consumer.
Rob is certainly right that core electrical components have become commodities, which is why the outlets in a fifty year old house generally work fine with modern, stylized floor lamps. That's a good thing, especially since electricity hasn't changed much in recent memory. Safety and materials have certainly improved, but electricity itself remains pretty much the same.
Of course, there is more than one electrical socket standard in common use. While floor lamps work fine in common sockets, high power appliances such as dryers and cooking ranges require a more robust socket. Hence, NEMA 14-30 and 14-50 receptacles.
Clearly, a one size standard does not fit all.
Rob then equates electrical standards with document formats.
It is the same thing with document formats. Consumers don't want to worry about document formats. They don't want to even think about document formats. They just want them to work, invisibly, without problems. Of course consumers want choice, but it is the choice of applications, choice of features, choice of vendors, choice of support options, choice of open source versus proprietary source, choice of heavy weight versus web-based, a choice of buying a single application versus buying a suite, etc. A single universal file format is what makes these other choices possible, just like a choice of the Medium Edison Screw bulb leads to an affordable choice in lamp designs.
The problem is that software standards, which are generally concerned with software interoperability, are different than electrical standards, which govern physical objects. In the physical world, end users might need to use cumbersome physical converters to bridge US and European power socket standards (which, while inconvenient, enables interoperability). With software, applications can support multiple standards and can even translate between those standards in ways that are invisible to end users.
The iPod supports the AAC, MP3, Audible, Apple Lossless, AIFF, and WAV audio standards. In the document space, OpenOffice supports multiple formats including RTF, XHTML, and the OASIS Open Document Format. Sun's Jonathan Schwartz is even promoting the ability for documents created in Google's office to be "trivially" exported to OpenOffice and notes the coming availability of a plugin that enables Word to use the ODF document format.
Rob's equating a single electrical standard with his call for a single universal file format also misses an important point. Electricity is a largely mature and stable technology and there is not much room for innovation in the socket and receptacle space. Document formats, on the other hand, are constantly evolving to keep pace with changing technology. Competition is vital to ensure that those formats continue to meet those ever changing needs. Imagine if a single document format was adopted 15 years ago. How would that format deal with things that we take for granted today like including links to web pages, adding digital photos, or even embedding video in our documents? Unlike electricity, document formats are evolving at a rapid pace and competition will help drive that innovation.
IBM wants to prevent that competition. It is actively trying to prevent ISO/IEC JTC1 from even considering the ECMA Open XML standard. Rather than let the marketplace decide which standardized format is best for a particular purpose, IBM wants to remove that choice. To go back to Rob Weir's electrical fixture example, in IBM's world, as long as there is a standard socket for a floor lamp, there is simply no place for a competing standard that is better suited to high powered appliances like dryers.
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.
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.