Protocols come in all shapes and sizes, and from a variety of sources. Some are proprietary, intended for use exclusively by their developer. Others may be ``open'' in some sense, indicating that they are intended for more general, public usage. In this context, the word ``open'' can mean any one of several different things. It may mean nothing more than that the protocol has been published by its developer. The protocol may still be very tightly controlled: revision of the protocol may remain the exclusive right of the developer; the protocol may be protected by patent or copyright restrictions; and use of the protocol may require a licensing agreement. This is a very narrow, and to our mind misleading, use of the word ``open.''
At the other extreme, the protocol may be open to a very high degree of public accessibility: it can be published by an open mechanism such as RFC publication; undergo revision by means of public working groups; and be entirely free of usage restrictions. A protocol satisfying all these criteria can be said to be ``open'' in the broadest sense. Protocols are often referred to as ``open'' to imply that they are open in a broad sense, whereas in fact they are open only in the narrowest sense.
Also, protocols can have widely differing periods of industry tenure. Some protocols never achieve widespread acceptance and usage, or else have very short lifetimes before becoming obsolete or being eclipsed by competing protocols. Other protocols become highly successful, and persist as long-term industry standards.
Over its lifetime, a protocol typically goes through a number of developmental phases. In general, from conception to decease, a protocol may go through some or all of the following phases:
Depending on its purpose, nature, and history, a protocol may undergo some, all, or none of these phases. Also, a protocol may iterate through phases 3 - 7 multiple times, as it undergoes maturation via repeated revision and re-publication. As described later, the Free Protocols Foundation plays a role in only two of these phases. For completeness, however, in the following sections we provide a brief description of each phase, along with commentary on the FPF's philosophy regarding the protocol development process.
The conception and early development of a protocol can take place in a variety of ways. A traditional source of Internet protocols is the IETF/IESG. Other sources of protocols are private businesses, the academic community, or even a single individual.
We believe that there is a tendency among established standards bodies to regard their own, officially sanctioned protocols as authoritative, while any other protocol is of questionable worth or validity. However, the history of protocol development does not support this view. Small groups of individuals have created protocols with far-reaching consequences (e.g. the World Wide Web), just as established standards bodies have created protocols which failed to achieved industry acceptance.
At the Free Protocols Foundation, we do not regard any one source of protocols as necessarily superior to any other. We believe that any coordination of activities can generate useful protocols, and we are ready to provide the same support for patent-freedom regardless of the initial source of the protocol.
If necessary, global parameters must be assigned to the protocol, e.g. by the IANA. The Free Protocols Foundation plays no role in this process.
If the protocol is intended to be an open protocol, as opposed to an exclusively proprietary one, then it must be made publicly available. This can be accomplished in various ways; the protocol can be self-published by the developer, or it can be published through an independent agency such as the Internet RFC Editor.
Ideally, the protocol should be published in a way which allows permanent and unrestricted access to the protocol by anyone wishing to implement it. In the case of Internet protocols, this is usually accomplished by RFC publication.
Depending on their intentions, the developers of a protocol may take steps to work towards a patent-free result, and they may wish to make certain declarations to that effect.
In general, there may be both an Author and a Working Group involved in the development of a protocol. The Author is the person, company, or other entity that has primary responsibility for the protocol. In some cases, the protocol may also undergo development at the hands of a Working Group - a set of independent individuals or companies who work cooperatively on the protocol, usually via public mailing lists.
Both the Author and the Working Group may wish to make declarations regarding the patent-freedom of the protocol. The Author may wish to make an initial declaration that the protocol is intended to be patent-free. As described later in this document, it is not possible to make an absolute guarantee that a protocol is, and will remain, completely patent-free. The best an Author can do is make a good-faith declaration that:
Similarly, the Working Group may wish to make a declaration that:
One of the roles of the Free Protocols Foundation is to provide a
public forum in which such declarations can be made. Any such
declaration which is submitted to the FPF will be published on our
website at
http://www.FreeProtocols.org.
Examples of previously submitted declarations may be seen at that
location.
The ultimate test of a protocol is whether or not it becomes widely accepted and implemented in the industry. If a protocol is largely unused, or eclipsed by a competing protocol, then it is largely irrelevant.
Protocols are usually not static, but instead typically undergo revision and enhancement in response to experience and/or changing industry requirements. Depending on the intentions of the Authors, this may take place by closed and proprietary processes, or by open and public ones. In the case of a truly open protocol, the development process should allow commentary and participation by all the constituencies that are affected by the protocol.
In some cases, continued development and enhancement of the protocol is accomplished by means of a public Working Group. Also depending on the Authors' intentions, the Working Group may function in a way which preserves the patent-freedom of the protocol, and the Working Group may wish to make a declaration to this effect.
Two things are required in order to achieve these goals. First, the developers must establish and follow a set of Working Group operating procedures that will have the effect of preserving the patent-freedom of the protocol. Second, the developers must make a public declaration that the Working Group follows these procedures.
A developer can achieve both of these things without the assistance of the Free Protocols Foundation. The development organization can establish its own set of Working Group operating procedures, and can independently announce that the Working Group follows them.
However, the Free Protocols Foundation provides a means of accomplishing these things which is external to, and independent of, the development organization itself. It is for this purpose that the FPF primarily exists. First, the FPF defines a clear and unambiguous set of Working Group processes and procedures which ensure, as far as possible, that the resulting protocol will remain functionally patent-free. Any development organization is free to adopt these procedures with regard to its own protocol. Second, the FPF provides an external forum in which the developer may declare publicly that its Working Group follows these procedures.
The FPF Working Group procedures are designed to:
The ultimate arbiter of protocols is the industry itself, in which a multitude of individual decisions leads to the acceptance or rejection of any particular protocol. The acceptance of a protocol as a standard is therefore something that occurs independently of formal endorsement by a standards body.
Nevertheless, once a protocol has become accepted as an industry standard, it is often the case that it receives the formal sanction of a standards body.
It is sometimes the case that many of the above phases of development take place under the direction of a single institution, or a group of tightly coupled institutions. For example, when developing protocols the IETF/IESG/IAB traditionally claims authority for all aspects of development except for (5), over which, of course, it has no direct control.
At the Free Protocols Foundation, we consider it undesirable to place control of multiple aspects of the development process in the hands of any single institution. First, this can include built-in conflicts of interest. For example, if a standards body is responsible both for developing protocols and publishing industry protocols, the body may be inclined to favor publication of its own protocols in preference to competing protocols from other sources, or it may be inclined to place inappropriate commentary within competing protocols. The IETF/IESG has a history of doing both of these things.
As another example, if the Maintenance and Enhancement responsibility is closely-held by a developing company or group of companies, this process may be biased in favor of the companys' interests, rather than those of the industry at large.
Furthermore, a large spread of responsibility within a single institution can lead to bureaucratization of its activities; the energy of the organization can become directed towards maintaining its internal bureaucracy, rather than serving the needs of its consumers. In other words, the institution can become authority oriented, as opposed to responsibility oriented. The historical evolution of the IETF/IESG/IAB is a classic example of this.
For these reasons, the Free Protocols Foundation is in favor of decoupling, as much as possible, the responsibility for the various aspects of development. A separation of powers greatly lessens the potential for conflicts of interest. Furthermore, an organization with limited responsibility can be discarded, reformed, or replaced more easily than one with very broad responsibility. Separation of powers thus provides a greater degree of choice, and therefore competition, within the protocol development process.
The Free Protocols Foundation is therefore in favor of placing responsibility for the various phases and aspects of development in the hands of independent organizations with limited agendas. We favor delegating the Protocol Publication phase to a truly independent third-party entity, such as the Internet RFC Editor. We favor handling the Maintenance and Enhancement phase by means of a variety of truly open public working groups, not just the IETF. Both of these steps ensure unbiased processing of the protocol.
In the same spirit, we favor placing responsibility for working towards patent-freedom in the hands of an independent organization. It is primarily for this reason that the Free Protocols Foundation exists. The role of the Free Protocols Foundation is to place those aspects of the protocol development process which relate to patent-freedom in a common, central, public location. The various other aspects of the development process have been described only to place the role of the FPF in its proper context; the FPF plays no role in those aspects.
In our model of the protocol development process, the scope of FPF activities is limited to two items exclusively:
and the Free Protocols Foundation has no agenda other than this.
Note that the role played by the FPF regarding protocol patents is somewhat analogous to the role played by the RFC Editor regarding protocol publication. RFC publication provides a means of publishing, via an independent agency, Internet protocols which have been produced by a variety of sources.
Similarly, the FPF represents a means of dealing with patent issues by an independent agency. Hitherto, this responsibility has been taken by multiple standards bodies, each of which has been obliged to define its own processes and procedures relating to patents. By adopting the FPF procedures, a standards body or development organization can make use of a set of general services established by an external agency.
As noted in the previous section, the FPF is in favor of distributing responsibility for the various aspects of protocol development, rather than consolidating all these aspects under the umbrella of a single organization, such as the IETF.
The objection may be made, that this distribution of responsibility creates coordination difficulties. It can be argued that vertically-integrated organizations like the IETF play a valuable role in terms of coordination of activities, and that it is more difficult to coordinate the activities of multiple independent organizations. In particular, it can be said that the IETF assists in the logical and orderly development of multiple protocols, by establishing a common architecture and structure for sets of related protocols.
However, we believe that this objection is unfounded. It has been well demonstrated, for example by the development of Linux, that multiple independent entities can coordinate their development efforts extremely effectively. In any event, the advantages to be gained from a separation of powers certainly exceed the drawbacks.