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 previously, 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, insofar 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.
For example, both HTTP and HTML, the two protocols which form the basis of world-wide Internet communications, were developed and gained prominence entirely independently of any formal standards body. The same is true of Pretty Good Privacy (PGP), now a world-wide encryption standard. These and many other protocols became industry standards despite lack of endorsement by a formal standards organization.
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.
In our model of the protocol development process, the scope of FPF activities is limited to two items exclusively:
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.
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 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, for example, 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 companies' 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.
As described 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.
Various standards organizations share our view that patents pose a significant danger to protocols, and therefore include processes within their protocol development procedures which work towards patent-freedom. An excellent example is provided by the IESG protocol development procedures [4], on which our own are based.
In general, however, these patent-free processes are created for the standards organizations internal use, and are not available for a protocol which is not officially sanctioned by the organization. To use the IETF as an example again, its patent-free processes apply only to IETF standards track protocols, and the IETF exercises selectivity over which protocols it does, or does not, place on standards track. If the IETF does not consider a protocol worthy of being placed on standards track, then its patent-free processes are not available to that protocol.
In effect, the IESG places an imprimatur of legitimacy on some protocols, but not others. The Free Protocols Foundation, on the other hand, makes its patent-free processes available to any protocol developer, without discrimination.
This represents a fundamental difference in philosophy and purpose between the IETF/IESG and the Free Protocols Foundation. We believe that the official sanctioning of some protocols and not others is unnecessary and without purpose. Standards organizations such as the IETG/IESG certainly have no monopoly on innovation, creativity, or competence. Any company, organization or individual is capable of creating protocols that become successful, far-reaching industry standards, without the sponsorship or blessing of a standards body. Successful protocols such as HTTP, PGP and many others, are examples of this.
In any event we believe that the ultimate arbiter of any protocol is its industry usage. Some protocols become accepted as industry standards while others do not, and this is something that takes place independently of whether the protocol was created or sanctioned by a standards body. For these reasons we consider that the endorsement of a protocol by placing it on ``standards track'' is essentially without meaning - it is a castle in the air.
By making its processes available to all, the Free Protocols Foundation places all protocol developers on an equal footing regarding patent-freedom. The success of any protocol can then be determined on the basis of its own merits, not on its origin or an artificial endorsement.