As an alternative to allowing IETF to decide and
control the future of the RFC Publication Service,
we propose a model of independent services (RFC
Publication, IANA, patent-free declarations, ...)
creating an environment for a market of protocols
with inherent checks and balances.
What is to follow, for the most part focuses on the
Patent-Free declarations but the general model and
the importance of an independent RFC Publication
Service separate from the likes of IETF/IESG are
also described.
The plain text version below has been trimmed, the
general process and RFC Publication Service
related text is kept. The complete document in
plain text, PDF and HTML formats are available at:
http://www.freeprotocols.org/freeProtocolProcess/index.html.
----
The Free Protocols Foundation
Policies and Procedures
www.FreeProtocols.org
Version 0.7
May 10, 2000
Copyright 2000 Free Protocols Foundation.
Published by:
Free Protocols Foundation
3610 164th place SE
Bellevue, WA 98008 USA
Permission is granted to make and distribute verbatim
copies of this document provided the copyright notice and
this permission notice are preserved on all copies.
1 Introduction
================
1.1 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.
1.2 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].
1.3 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 the
protocol is truly free from patents, or 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.
1.4 Difficulties Relating to Software and Protocol Patents
------------------------------------------------------------
...
1.5 Terminology
-----------------
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.
1.5.1 Definitions
-------------------
Throughout this document, we will use the following
terms with the meanings indicated:
o Truly Patent-Free Protocol. A protocol that can be
implemented in the form of entirely patent-free
software. A Truly Patent-Free Protocol contains no
limitations whatsoever on its dissemination and
use, and may be freely implemented by anyone,
without restriction.
o Functionally Patent-Free Protocol. A protocol for
which there are either no known software patent
restrictions, or where software patent restrictions
are known to exist, non-restrictive usage rights
have been obtained from the patent-holder.
o Free Protocol Specification. A protocol that
conforms to the policies and procedures of the Free
Protocols Foundation relating to patents,
copyright, and confidentiality. These procedures
are set forth in Section 6.
o Declared Patent-Free Protocol. A protocol for
which a declaration has been made to the Free
Protocols Foundation that it conforms to the
procedures of Section 6.
o Author of a Protocol. The individual, company or
organization, or the set of individuals, companies
or organizations, who are responsible for the
creation, development, maintenance, or enhancement
of the protocol specification.
o Working Group. An open-ended set of individuals or
organizations who collectively work towards the
creation, development, maintenance, or enhancement
of the protocol specification.
o Free Protocol Development Working Group. A Working
Group which has voluntarily elected to adhere to,
and be bound by, the policies and procedures of the
Free Protocols Foundation regarding patent-freedom.
o Free Protocol Developer. A contributor to a Free
Protocol Development Working Group.
1.6 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.
2 The Protocol Development Process
====================================
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.
2.1 Phases of Development
---------------------------
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:
1. Initial development.
2. Global parameter assignment.
3. Publication.
4. Patent-free declarations.
5. Industry usage.
6. Maintenance and enhancement.
7. Endorsement by a standards body.
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.
2.1.1 Initial Protocol Development
------------------------------------
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.
2.1.2 Global Parameter Assignment
-----------------------------------
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.
2.1.3 Protocol Publication
----------------------------
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.
2.1.4 Patent-Free Declarations
--------------------------------
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:
o To the best of his knowledge the protocol is not
subject to any patent restrictions.
o It is the Author's intention to maintain the
protocol patent-free.
o If any patent restrictions relating to the protocol
become known to the Author, he will make prompt
disclosure of this.
Similarly, the Working Group may wish to make a
declaration that:
o The protocol has been developed in such a way as to
ensure that no patented components have been
intentionally introduced into the protocol.
o If any patent restrictions relating to the protocol
become known to the Working Group, it will make
prompt disclosure of this.
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.
2.1.5 Industry Usage
----------------------
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.
2.1.6 Maintenance and Enhancement
-----------------------------------
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:
o Ensure that no patented components can be
intentionally introduced into the protocol as a
result of the Working Group activities.
o Provide remedies in the case of unintentional
introduction of patented components into the
protocol. These remedies consist of prompt
publication of the fact of the patented component,
and an attempt to secure non-restrictive usage
rights from the patent holder.
2.1.7 Endorsement by a Standards Body
---------------------------------------
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.
2.2 Role of the Free Protocols Foundation
-------------------------------------------
In our model of the protocol development process, the
scope of FPF activities is limited to two items
exclusively:
o (4) Patent-free declarations
o (6) Maintenance and enhancement
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.
2.3 Comparison to Standards Organization Processes
----------------------------------------------------
2.3.1 Centralisation vs. Decentralization of Responsibility
--------------------------------------------------------------
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.
2.3.2 Coordination of Activities
----------------------------------
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.
2.3.3 Selective vs. Egalitarian Patent-Freedom
-------------------------------------------------
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.
3 The Free Protocols Foundation
=================================
3.1 General Philosophy
------------------------
...
3.2 Purpose, Activities and Scope
-----------------------------------
...
3.3 Other Activities
----------------------
...
4 Free Protocol Development Working Groups
============================================
It is often the case that protocols are developed, or
maintained and enhanced, by means of public Working
Groups. A Working Group may enter into participation
at various stages in the protocol's development.
In many cases, the creation and initial development of
a protocol is done by a single Author or a small team
of core developers. Once an initial basis for the
protocol is in place, a larger public Working Group is
then formed, which takes over responsibility for
maintenance and enhancement of the protocol. In this
case, the Working Group begins participating at stage
(6), Maintenance and enhancement.
In other cases, a Working Group may be formed in order
to do the initial creation and development work itself.
In this case, the Working Group begins participating at
the very beginning, at stage (1), Initial development.
Working Groups typically communicate among themselves
by means of working group mailing lists, together with
occasional physical meetings as necessary. Under these
circumstances, it is possible for a large number of
contributors to participate in the development of a
protocol.
The processes and procedures of Section 6 include
provisions whereby patent-freedom can be maintained for
a protocol despite its being developed by a public
Working Group. These provisions consist of a set of
procedures that, if followed by the Working Group, will
keep the protocol functionally patent-free. A key
provision is that anyone who participates in the
Working Group is required to adhere to these
procedures. That is, the Working Group must impose
adherence to its procedures on all Working Group
contributors.
Note that the FPF does not manage Working Group mailing
lists itself, nor does it maintain a list of Working
Groups which have adopted the FPF's processes and
procedures. Though the FPF does provide a mechanism
whereby Working Groups may make a declaration that they
conform to the FPF Working Group procedures, it does
not provide a mechanism whereby individual contributors
may make such a declaration.
The role of the FPF regarding Working Groups is limited
to that of establishing a minimal set of policies and
procedures that contributors may choose to adopt in
order to maintain a patent-free protocol. This minimal
set of policies relates only to patents, copyright and
confidentiality. All other procedures are at the
discretion of each individual Working Wroup.
5 Patent-Free Declarations
============================
5.1 Author's Declaration
--------------------------
Any Author may make an initial patent-free declaration
to the Free Protocols Foundation relating to a
protocol. This declaration should include statements
to the effect that:
o To the best of the Author's knowledge, the protocol
is not subject to any patent restrictions.
o It is the Author's intention to maintain the
protocol patent-free.
o In the event that the Author becomes aware of a
patent right restriction relating to the protocol,
or a patent right assertion is made with respect to
the protocol, the Author will make prompt
disclosure of this fact to the Free Protocols
Foundation.
Any such statement provided to the FPF will be
published on the FPF website. Examples of statements
previously provided to the FPF can be found in the
Author's Declarations section of the FPF website.
5.2 Working Group Declaration
-------------------------------
If a Working Group participates in the development
and/or maintenance and enhancement of a protocol, it
may make a declaration that its protocol maintenance
and enhancement procedures conform to the FPF Processes
and Procedures regarding patent-freedom. A Working
Group may do this by providing the Free Protocols
Foundation with a statement that its protocol
development process conforms to the processes and
procedures set forth in Section 6.
Any such statement provided to the FPF will be
published on the FPF website, and the corresponding
protocol will be added to the list of those declared to
conform to the FPF's patent-free policies and
procedures.
Examples of statements previously provided to the FPF
can be found in the Free Protocols Working Group
Declarations section of the FPF website. The list of
declared-conforming protocols is available in the List
of Free Protocols Specifications and Their Declarations
section of the FPF website.
6 Patents, Copyright and Confidentiality - Policy Statement
=============================================================
In this section we define a set of policies and
procedures which ensure that a protocol will remain
functionally patent-free. Any Working Group is free to
make use of these procedures as part of their
development process. A key component of these
procedures is that every member of the Working Group is
required to abide by the procedures.
6.1 Policy Statement Principles
---------------------------------
Because of the difficulties relating to software
patents described in Section 1.4, it is not possible to
be absolutely certain that a protocol is truly
patent-free. The scope of these policies and
procedures is therefore limited to ensuring that a
protocol is patent-free as far as is practically
possible. The purpose of the procedures is to codify
the following principles:
o Author's Patent-Free Intent Declaration. When a
developer makes a patent-free declaration to the
FPF, a key part of the declaration is that of
intent. That is, the declarer is making the
statement that to the best of the declarer's
knowledge the protocol is patent-free, and that it
is the declarer's intention to keep it so.
o Ongoing Patent-Free Contributions. By becoming a
member of a Working Group, every contributor to the
on-going maintenance and enhancement of the
protocol is required to adhere to principles and
procedures which preserve patent-freedom of the
protocol.
o Working Group's Declaration When a Working Group
makes a declaration to the FPF, the effect of this
declaration is that the Working Group's activities
conform to a set of processes that ensure, insofar
as possible, that the resulting protocol
specification is functionally patent-free.
o Patent Assertion Disclosure If a patent assertion
is made subsequent to the declaration, the declarer
undertakes to make prompt announcement of this to
the Free Protocols Foundation. The Free Protocols
Foundation maintains a record of all patent right
assertions that have been made against any of its
listed protocols. This record is available in the
Notices of Claimed Rights section of the FPF
website.
o Obtaining Non-Restrictive Usage Rights. In the
event that the developer becomes aware of a patent
restriction relating to the protocol, the developer
will attempt to obtain non-restrictive usage rights
for the protocol.
6.2 General Policy
-------------------
In all matters of patent and confidentiality rights and
procedures, the intention of the FPF is to benefit the
Internet community and the public at large, while
respecting the legal rights of others.
6.3 Confidentiality Obligations
--------------------------------
...
6.4 Rights and Permissions of All Contributions
-------------------------------------------------
...
6.5 FPF Role Regarding Free Protocol Specifications
----------------------------------------------------
1. Where any patents, patent applications, or other
proprietary rights are known, or claimed, with
respect to any Free Protocol Specification, and
brought to the attention of the FPF, the FPF shall
prepare a note, to be included in the next revision
of the Free Protocol Specification, indicating the
existence of such rights, or claimed rights.
2. The FPF encourages all interested parties to bring
to its attention, at the earliest possible time,
the existence of any patent rights pertaining to
Free Protocol Specifications.
3. Where the FPF knows of rights, or claimed rights
under (1), the FPF shall assist the Free Protocol
Working Group in attempting to obtain from the
claimant of such rights, a written assurance with
respect to the relevant protocol specification(s),
that any party will be able to obtain the right to
implement, use and distribute the technology or
works when implementing, using or distributing
technology based upon the specific specification(s)
under openly specified, reasonable,
non-discriminatory terms.
References
==========
...
See http://www.freepatents.org for the complete document.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf