Statement made on 27 Feb 2009

Are standards helpful?

ICT Standards can help improve efficiency and technical interoperability and help to grow markets. In this regard they can be very useful and provide value.

Are standards the only way to achieve interoperability?

Standards are one way to help address technical interoperability concerns. When we find interoperability in the marketplace, it often results from product design, IPR licensing or collaborative efforts that may have nothing or little to do with standards. Companies have incentives to work together to respond to their customer needs and marketplace demands.

How do we judge how successful or effective a standard is?

Standards are only a means to an end. There are tens of thousands of ICT standards that emanate from hundreds of different standards-setting organizations (SSOs). Some standards are widely implemented, some less so, and some almost not at all. Often it has little to do with the particular SSO that promulgated the standard or the procedures under which it was developed. While most SSOs can point to one or more standards they have produced that were widely adopted (and therefore useful or arguably successful), they all can also point to one or more of their standards that ended up largely "on the shelf" with very little voluntary implementation.

It is important to recognize that standards largely are implemented by industry players. A company most likely will use a standard when it is responsive to a market-driven need and therefore necessary or desirable for its business. Like any tool, a standard will be used by more people to the extent it serves a useful purpose.

Should there be only one standard for each technical area of focus?

The ICT marketplace - and the related needs - change rapidly. As a result, ICT standards must be able to change in response. New standards must be permitted to compete in order to respond to these needs, further new competition, and encourage the development of new, innovative solutions. Standards should be enablers - and not overly constricting.

Standards - and the use of standards - must be sufficiently dynamic if they are to continue to be effective. Attempts to mandate that all companies adhere to a single standard should be avoided whenever possible in order to avoid the related inhibiting effects on competition, innovation and customer/consumer choice. This is especially true in terms of ICT standards which typically are not developed to address a regulatory concern (such as those relating to safety, health or environmental issues) but rather to serve as tools to help companies respond to a rapidly changing and heterogeneous technical landscape.

This landscape offers companies around the world the opportunity to innovate and use their intellectual property to better compete in the global marketplace. Standards themselves can compete in the marketplace and be responsive to different sets of customer needs, while bridges (e.g., translators) often can be built virtually between different standards (and different implementations of standards) in order to address interoperability issues. Requiring companies to adhere to a single standard may unnaturally force a specific marketplace outcome.

What are some of the characteristics of an effective standard?

Among other things, ICT standards should be narrowly focused and avoid standardizing what essentially are product features. This will encourage further competition among different products implementing the standard and further innovation in both the technology reflected in the standard and in distinguishing features of the competing products.

Do standards ensure interoperability?

Standards are one way to help facilitate technical interoperability, but they do not guarantee end to end systems interoperability. But even if two companies' different products both fully implement the same standard, there is no guarantee that they will be interoperable as a result. This is for a number of reasons, many of them unintended by implementers. It also is why industry players will further collaborate in order to bridge the interoperability gap, which includes engaging in interoperability testing events. Moreover, while standards are useful tools in helping to address technical interoperability issues, they are far less effective tools for addressing semantic and organizational levels of interoperability. Users of standards, as well as government policymakers looking for ways to promote greater systems interoperability across internal organizations, need to be aware of these limitations of standards to solve all interoperability challenges.

Where does most of the innovative technology reflected in standards come from?

While standards are often developed using a collaborative process, the bulk of the technical research and development is conducted and funded by individual companies before the collaboration begins.

Different companies contribute their patented technology for incorporation into the standard for different reasons. For a company that develops commercial products, the adoption of a standard may increase market demand for the company's products. Innovators that develop technology and license that technology to others who will develop and sell commercial products view standards as a vehicle for licensing their technologies. Other companies provide services (e.g., IT support, mobile phone subscription services, product integration, consulting services) that depend on the widespread use of standardized technology, but sometimes that technology is used as a loss leader to up-sell services and other proprietary offerings.

Users or consumers (including government and non-governmental entities) of standards also have a stake in the success of most new standards. Standards should be designed to satisfy market needs defined by technology users. Consequently, users are also included in the collaborative development process.

How do SSOs address the inclusion of proprietary, innovative technology into standards?

SSOs try to take a balanced approach and accommodate all of these stakeholders to ensure that the standards that are developed meet user requirements, market needs, and can be widely adopted. In order to achieve those objectives SSOs recognize that the inclusion of patented technology is not only often necessary but desired by the user community so long as the patented technology is licensed to all on reasonable and non-discriminatory terms and conditions (RAND/FRAND). The IPR policies typically encourage patent holders to participate in the process and contribute their patented technology so that it can be shared with competitors on RAND/FRAND terms.

What is an "open standard"?

This is a matter of some debate.

Many SSOs would say that they have been developing open standards for decades. They would define an "open standard" as one developed through an open, transparent, consensus-based process that is supported by a balanced IPR policy.

More recent definitions are being proposed that suggest that an "open standard" is one where all of the holders of essential patent claims would necessarily agree to license their necessary patents for free or even to waive their rights altogether. There are not many SSOs that likely would produce any standards meeting these requirements. SSOs have no ability to ensure that all necessary patents (especially those held by non-members) would be made available to implementers under these terms. Many of them would be reluctant to move away from a RAND/FRAND approach and seek to override certain basic property rights held by others. If a standards body had such a patent policy that would force patent holders to give up many of their patent rights, patent holders either would not participate in such a standards-setting activity or else they would not invest R&D funds to innovate in that technology area. This could create innovation "dead zones" around technology areas that subject to standardization and inhibit the ability of companies of all sizes and in all locations to use their intellectual property to help them compete in the global marketplace.

This debate around what constitutes an open standard or measurements of openness may not provide much real value. The Danish Government recently funded an IDC evaluation of the degree to which ten SSOs (CEN, Ecma, ETSI, IETF, ISO, ITU, NIST, OASIS, OMG and W3C) were "open". The study concluded:

Standard organizations are generally aware of the need of openness because they all aim at providing successful, widely accepted standards. However, the concepts of openness and consensus have been implemented using different models that relate to the type of organization, their formal foundation and their degrees of formalization. We therefore see the apparent differences in openness as a sign of the structure chosen by the organizations.

In conclusion there are, indeed, differences between standard setting organizations in terms of "openness" and certainly in terms of how openness is implemented. It can be, however, difficult to make a distinction of which form of "openness" is the most appropriate.

How do "open standards" and "open source software" relate?

Open source software (OSS) is one way to implement a standard, but it is not at all the same as a standard. A standard sets forth the minimum technical requirements to achieve a very narrow purpose, and if it is a good standard, there will be many different competing implementations (in different types of software including both proprietary software and OSS, hardware, a combination of them, etc.) that will be further differentiated to respond to different customer needs. See TIA-Paper

Is there a tension between OSS and F/RAND licensing?

OSS (and the various licenses under which the code is distributed) has been an important development in the ICT sector over the last decade. Commercial or "proprietary" software (also referred to as "closed source") continues to play a critical role and shows no signs of retreating in importance. As the role of OSS has evolved, it has become clear that rather than being a replacement for proprietary software, OSS will increasing be part of so-called "mixed source" offerings, as vendors learn to mix the best of both software licensing models. Although this often involves complex licensing review and architectural decisions to ensure conformance with various competing licensing terms, it has been shown to be possible. And many companies have succeeded in the marketplace doing just that. Notwithstanding the success of a number of companies who incorporate OSS into some of their core products (and of individual open source products in their own right), some questions have been raised about whether and how OSS and standards can co-exist. These questions have often focused on the standards context, and are often framed to suggest that the long established standards principle of RAND (Reasonable and Non-Discriminatory) license terms for patents somehow discriminates or is incompatible with all OSS (regardless of the specific license under which the code is distributed).

Although the issue of compatibility between OSS licenses and RAND licensing commitments has been raised on many occasions, there is surprisingly little detail and analysis given in such discussions and few (if any) real world examples given where a standard governed by a RAND licensing commitment could not be implemented by an OSS vendor. In order to fully explore the perceived tensions between OSS licenses and RAND commitments, it is important to carefully study all open source licenses and make a determination, for which license(s) do potential issues arise and what is the specific language of clause in that OSS license which creates tension? Even a cursory review suggests that with many OSS licenses there are no conflicts or challenges at all. In addition, to the extent there are potential issues identified with a specific clause in a particular OSS license, it is important to consider the full range of possible solutions (beyond merely a requirement that standards be licensed under Royalty Free (RF) terms). As previously mentioned, many companies mix OSS and proprietary code together, using sophisticated architectural mechanisms to ensure various portions of the product are not subject to the requirements of an OSS license. These same solutions are likely to be available to developers to help solve any potential issues in the context of implementing RAND-based standards. In summary, it is important to keep discussion grounded in actualities, so it needs to be asked, what are the concrete examples of real problems where there is tension between an OSS license and a RAND licensing commitment and what are the range of possible solutions? It would be optimal to find a solution that is fair to types of software and all related business models.

Are there commercial interests around OSS that may impact the debate on "open standards"?

Many OSS business models make money by selling warranties, support, training and related consulting services. In terms of a customer's implementation of a standard, such business models seek to encourage that customer to spend its IT budget on these other services as opposed to having to pay for the right to use others' patented technology. So some companies may be advocating in support of the newer definitions of an "open standard" in order to further their own competitive objectives. But balanced approaches to standards procedures and policies assure that the playing field is a level one. It hardly seems "fair" or "balanced" for one group to be able to claim that they should have unrestricted access to others' hard-earned property rights.

It also would undermine the benefits that patent rights provide around the world to those who invest in innovation and then seek to use those property rights to compete in the global marketplace. There is a strong correlation between respect for intellectual property rights and local economic development.

What are the implications of "IP-free" policies on EU innovation and competitiveness?

Intellectual property rights property rights are becoming increasingly important for European inventors, creators and businesses, particularly as they seek access to foreign markets that are critical for growth. As the Commission itself has stated, "Because European competitiveness is built on the innovation and value added to products by high levels of creativity, protection and enforcement of intellectual property go to the heart of the EU's ability to compete in the global economy."

In An Industrial Property Rights Strategy for Europe, the European Commission also noted the importance of IPR to small-and-medium-sized enterprises:

[SMEs] account for 99% of all enterprises, providing 85 million jobs in Europe. Successful exploitation of industrial property rights can provide the essential leverage for SMEs to prosper.

Any policy approach taken in the EU may have repercussions in other parts of the world as well.

Is the Soft IP proposal a viable solution?

The pros and cons of the "License of Right" proposed approach is the topic of much debate. While on the one hand they may be easier to obtain, they also arguably place the burden on the patent holder to bring an action for damages against infringers that may prove costly and time-consuming to pursue. It may be that this would reduce the value of having the patent and the usual benefits associated with patent protection.

Is there a need for modifications to current IPR policy approaches at SSOs?

SSOs routinely review their procedures and policies and make improvements as needed. This regular self-assessment is healthy.

Some people have argued there is a "patent hold-up" problem that can occur because an implementer has a reduced bargaining position with the holder of essential patent claims vis-à-vis licensing terms once the standard is finalized. After reviewing the issue in some detail, a number of SSOs have decided to permit the voluntary disclosure of those licensing terms "ex ante". There have been additional proposals to the effect that SSOs should mandate the disclosure by the patent holder of the licensing terms for its essential claims to the SSO before the standard is approved.

There is a real question whether the hold-up problem is widespread. Many believe that it appears to have occurred in a very small number of situations when compared to the thousands of ICT standards that exist and are being widely implemented. This may be because many patent holders also are implementers, and there are incentives for stakeholders to make the system work. There also are concerns that mandatory approaches are overly burdensome and inefficient, and the related "pains" to the system outweigh any perceived "gains".

Others question the value of having this information supplied to the SSO "ex ante". Most implementers are not interested in a license for just the essential patent claims. They want a customized license from the patent holder that addresses their entire product and all of the patent claims that may be implicated by that. In addition, most standards-related licenses involve portfolio licenses, cross-licenses or patent licenses that are part of a larger business transaction. Accordingly, the disclosure of specific licensing terms for just the Essential Claims often is not particularly meaningful for prospective licensees. It may be more helpful for them to be aware of the disclosure of patents that likely will be essential and the identification of the relevant patent holder that they can then contact.

Furthermore, any group discussions of such licensing terms or relative costs, while possibly pro-competitive on one level, can also lead to possible anti-competitive conduct (such as group boycotts, buyer cartel behaviors, etc.). And there is a concern that mandatory approaches may shift any perceived possibility of a "hold up" problem by a patent holder after the standard is finalized to a possibility that the patent holder could be "held up" by the standards group. This can result in reduced incentives to innovate in technical areas subject to standardization, which in turn can reduce dynamic efficiencies and create innovation "dead-zones" around standardization.