next up previous contents
Next: The Protocol Development Process Up: The Free Protocols Foundation Previous: Contents



The Free Protocols Foundation Mission

Software patents pose a significant danger to protocols. In some cases patents become included in protocols by accident - that is, without deliberate intentionality on the part of the protocol developer. In other cases, however, an unscrupulous company or organization may deliberately introduce patented components into a protocol, in an attempt to gain market advantage via ownership of the protocol.

In either case, the protocol can then be held hostage by the patent-holder, to the enormous detriment of anyone else who may wish to use it. The inclusion of software-related patents in protocols is extremely damaging to the software industry in general, and to the consumer.

The mission of the Free Protocols Foundation is to prevent this from happening. We have defined a set of processes which a protocol developer can use to work towards a patent-free result, and we provide a public forum in which the developer can declare that the protocol conforms to these processes. As described below, it is not possible to provide an absolute guarantee that any particular protocol is truly patent-free. However, the Free Protocols Foundation processes allow a developer to provide some public assurance that reasonable, good-faith measures have been taken to create a patent-free protocol.

In some cases, standards organizations such as the IESG make use of their own processes for developing patent-free protocols. However, these processes are available only for the organization's own internal use. The Free Protocols Foundation makes the same general processes available to any protocol developer. Its processes allow any company, organization or individual to develop patent-free protocols, without requiring the developer to be part of a formal standards organization.

At the Free Protocols Foundation we strenuously oppose the creation and promotion of patented protocols. By providing clear mechanisms and assurances of patent-freedom, our goal is to make it abundantly clear to the industry at large whether a particular protocol is, or is not, patent-free.

The Patent Debate

At the time of writing, there is an ongoing debate within the software industry regarding software patents. Like many others within the industry, we at the Free Protocols Foundation regard the historical tradition of patents as being entirely inappropriate for software.

We consider software patents to have the effect of inhibiting free and open competition within the software industry, and to be extremely detrimental to the industry and the consumer. A complete discussion of the software patent issue is outside the scope of this document. More information on this subject can be found at various sources, for example [1] or [2].

How Patents Affect Protocols

Patents are applied to software, not to protocols. It is not possible to patent a protocol; in general only a process or an algorithm can be patented. However, a protocol may include a patented algorithm as an integral part of its specification. In this case, any software implementation of the protocol requires the use of patented software. That is, a patented algorithm is an inherent part of the protocol.

Even if a protocol does not explicitly decree the use of a specific patented software process, it may still be the case that any practical implementation of the protocol requires the use of patented software components. The protocol could in principle be implemented in a way which avoids the use of patented software. In practice, however, the result would be a significantly inferior implementation, for example in terms of efficiency.

In either case, the protocol effectively implies the use of patented software. We will refer to any such protocol as a patented protocol. That is, a patented protocol is any protocol whose practical implementation requires the use of patented software components.

We will use the term patent-free protocol, or just free protocol, to refer to a protocol which is functionally free from software patents. By ``functionally free from software patents,'' we mean either that (a) the protocol is truly free from patents, or (b) if the protocol does imply the use of patented software, that the patent-holder has granted non-restrictive rights to include the patented software components in implementations of the protocol.

In either case, the result is that the protocol can be freely implemented and used by anyone, without encountering significant restrictions.

Difficulties Relating to Software and Protocol Patents

Because of the current state of affairs regarding software patents, it is no longer possible to be absolutely certain that any particular protocol is patent-free. Whether or not a new invention or technology violates any existing patents has traditionally been determined by means of a patent-search - a direct search and examination of all relevant pre-existing patents. In the case of a physical technology, this yields a more or less definitive answer as to whether or not the technology violates any existing patents.

In the case of software, however, it is not possible to answer this question with the same degree of certainty. The basic reason for this lies in the very high degree of subtlety and complexity of modern software systems. A software system may contain hundreds or thousands of individual software constructs, any one of which may potentially violate an existing patent. Furthermore, it is very difficult to establish a taxonomy of existing software patents. A taxonomy is required to guide the patent-search process - the taxonomy defines which patents are ``related'' to the technology under search. Without a well-defined and meaningful taxonomy, it is not possible to define an appropriate scope of search.

In other words, a software system may contain a small universe of software constructs. Meanwhile, the Patent and Trademark Office has established a small universe of software patents. Unfortunately, there is no way to establish with certainty that none of the elements of one universe also reside in the other universe.

To make matters worse, there can be room for dispute regarding whether or not a particular software construct violates a particular patent. The patent-holder may claim that it does, while the software developer claims that it does not. If the two parties are unable to come to agreement, the issue can only be resolved in the courts.

Finally, because of the delay between a company filing a patent application and the granting of the patent by the PTO, it is entirely possible for a company to conduct a software patent-search with negative results, only to discover subsequently that a patent has been granted after-the-fact, which now places its software in violation.

For all these reasons, it has now become essentially impossible to establish with certainty that a particular piece of software is, and will remain, truly patent-free. Likewise, it has become impossible to establish with certainty that a particular protocol is, and will remain, patent-free.


Legal rights such as patents and copyright are sometimes referred to collectively as ``Intellectual Property Rights.'' Although this is a very commonly used term, we will avoid using it in this document.

Along with other authors, we object to the use of this term on the grounds that it blurs the distinction between intellectual items and material ones. The law allows ownership rights to be asserted with regard to both types of item, and therefore both may be considered in some sense to be ``property.'' However, we regard intellectual entities such as software and protocols to be fundamentally different in nature to material items, and worthy of entirely different legal treatment relating to questions of ownership.

Furthermore, the term ``Intellectual Property Rights'' is typically used to encompass a number of widely differing legal constructs, including patents, copyrights and trademarks. These three legal constructs have entirely different purposes, mechanisms, and consequences. Grouping all three together suggests that they share a general similarity, and leads to a misunderstanding of their important distinctions. For more discussion on this, see [3].

Where necessary, we will use explicit terms such as ``patent,'' or ``copyright,'' to refer to legal rights relating to intellectual constructs.


Throughout this document, we will use the following terms with the meanings indicated:

About the Free Protocol Policies and Procedures

This document establishes a set of policies and procedures for protocol development that is designed to ensure, insofar as this is possible, that the resulting protocol is functionally patent-free. The purpose of these procedures is to create a resulting protocol that is either free from patent restrictions, or for which non-restrictive usage rights have been obtained from the patent-holder. These procedures are set forth in Section 6.

The procedures of Section 6 are based on a similar set of procedures defined by the IESG (Internet Engineering Steering Group). Specifically, the FPF procedures are an extension of Section 10, Intellectual Property Rights, of RFC 2026, The Internet Standards Process - Revision 3 [4].

That section defines the procedures to be followed by the IETF (Internet Engineering Task Force) relating to patent-freedom. However, the scope of RFC 2026 is largely limited to the needs of the IESG itself; in particular, the patent-related procedures of Section 10 of RFC 2026 are limited to standards-track documents and other IETF-specific purposes. Thus, while these patent procedures may be entirely adequate for the needs of the IETF, they are not adequate to dealing with patent-freedom in a more general setting.

The processes and procedures in Section 6 of this document are therefore an extension of the RFC 2026 procedures, designed to address the need for patent-freedom procedures in general. They are intended to be a set of general-purpose processes which can be adopted by any protocol development organization.

About this Document

This document is available in several alternative formats at the Free Protocols Foundation website

next up previous contents
Next: The Protocol Development Process Up: The Free Protocols Foundation Previous: Contents