soon as reasonably possible after the Contribution is published in an
Internet Draft or RFC, unless the required disclosure is already on
file. Participants who realize that the IPR will be or has been
incorporated into a submission to be published in an Internet Draft,
or is seriously being discussed in a working group, are strongly
encouraged to make at least a preliminary disclosure. That
disclosure should be made as soon after coming to the realization as
reasonably possible, not waiting until the document is actually
posted or ready for posting.
If a participant first learns of IPR that meets the conditions of
Section 6.6 in a Contribution by another party, for example a new
patent application or the discovery of a relevant patent in a patent
portfolio, after the Contribution was published in an Internet-Draft
or RFC, a disclosure must be made as soon as reasonably possible
after the IPR becomes reasonably and personally known to the
participant.
6.3. How must a disclosure be made?
IPR disclosures are made by following the instructions at
http://www.ietf.org/ipr-instructions.
6.4. What must be in a disclosure?
6.4.1. The disclosure must list the numbers of any issued patents or
published patent applications or indicate that the claim is based on
unpublished patent applications. The disclosure must also list the
specific IETF or RFC Editor Document(s) or activity affected. If the
IETF Document is an Internet-Draft, it must be referenced by specific
version number. In addition, if the IETF Document includes multiple
parts and it is not reasonably apparent which part of such IETF
Document is alleged to be Covered by the IPR in question, it is
helpful if the discloser identifies the sections of the IETF Document
that are alleged to be so Covered.
6.4.2. If a disclosure was made on the basis of a patent application
(either published or unpublished), then, if requested to do so by the
IESG or by a working group chair, the IETF Executive Director can
request a new disclosure indicating whether any of the following has
occurred: the publication of a previously unpublished patent
application, the abandonment of the application and/or the issuance
of a patent thereon. If the patent has issued, then the new
disclosure must include the patent number and, if the claims of the
granted patent differ from those of the application in manner
material to the relevant Contribution, it is helpful if such a
disclosure describes any differences in applicability to the
Contribution. If the patent application was abandoned, then the new
disclosure must explicitly withdraw any earlier disclosures based on
the application.
New or revised disclosures may be made voluntarily at any time.
6.4.3. The requirement for an IPR disclosure is not satisfied by the
submission of a blanket statement of possible IPR on every
Contribution. This is the case because the aim of the disclosure
requirement is to provide information about specific IPR against
specific technology under discussion in the IETF. The requirement is
also not satisfied by a blanket statement of willingness to license
all potential IPR under fair and non-discriminatory terms for the
same reason. However, the requirement for an IPR disclosure is
satisfied by a blanket statement of the IPR discloser’s willingness
to license all of its potential IPR meeting the requirements of
Section 6.6 (and either Section 6.1.1 or 6.1.2) to implementers of an
IETF specification on a royalty-free basis as long as any other terms
and conditions are disclosed in the IPR disclosure statement.
6.5. What licensing information to detail in a disclosure.
Since IPR disclosures will be used by IETF working groups during
their evaluation of alternative technical solutions, it is helpful if
an IPR disclosure includes information about licensing of the IPR in
case Implementing Technologies require a license. Specifically, it
is helpful to indicate whether, upon approval by the IESG for
publication as RFCs of the relevant IETF specification(s), all
persons will be able to obtain the right to implement, use,
distribute and exercise other rights with respect to an Implementing
Technology a) under a royalty-free and otherwise reasonable and non-
discriminatory license, or b) under a license that contains
reasonable and non-discriminatory terms and conditions, including a
reasonable royalty or other payment, or c) without the need to obtain
a license from the IPR holder.
The inclusion of licensing information in IPR disclosures is not
mandatory but it is encouraged so that the working groups will have
as much information as they can during their deliberations. If the
inclusion of licensing information in an IPR disclosure would
significantly delay its submission it is quite reasonable to submit a
disclosure without licensing information and then submit a new
disclosure when the licensing information becomes available.
6.6. When is a disclosure required?
IPR disclosures under Sections 6.1.1. and 6.1.2 are required with
respect to IPR that is owned directly or indirectly, by the
individual or his/her employer or sponsor (if any) or that such
persons otherwise have the right to license or assert.
7. Failure to disclose
There are cases where individuals are not permitted by their
employers or by other factors to disclose the existence or substance
of patent applications or other IPR. Since disclosure is required
for anyone submitting documents or participating in IETF discussions,
a person who does not disclose IPR for this reason, or any other
reason, must not contribute to or participate in IETF activities with
respect to technologies that he or she reasonably and personally
knows to be Covered by IPR which he or she will not disclose.
Contributing to or participating in IETF discussions about a
technology without making required IPR disclosures is a violation of
IETF process.
8. Evaluating alternative technologies in IETF working groups
In general, IETF working groups prefer technologies with no known IPR
claims or, for technologies with claims against them, an offer of
royalty-free licensing. But IETF working groups have the discretion
to adopt technology with a commitment of fair and non-discriminatory
terms, or even with no licensing commitment, if they feel that this
technology is superior enough to alternatives with fewer IPR claims
or free licensing to outweigh the potential cost of the licenses.
Over the last few years the IETF has adopted stricter requirements
for some security technologies. It has become common to have a
mandatory-to-implement security technology in IETF technology
specifications. This is to ensure that there will be at least one
common security technology present in all implementations of such a
specification that can be used in all cases. This does not limit the
specification from including other security technologies, the use of
which could be negotiated between implementations. An IETF consensus
has developed that no mandatory-to-implement security technology can
be specified in an IETF specification unless it has no known IPR
claims against it or a royalty-free license is available to
implementers of the specification unless there is a very good reason
to do so. This limitation does not extend to other security
technologies in the same specification if they are not listed as
mandatory-to-implement.
It should also be noted that the absence of IPR disclosures is not
the same thing as the knowledge that there will be no IPR claims in
the future. People or organizations not currently involved in the
IETF or people or organizations that discover IPR they feel to be
relevant in their patent portfolios can make IPR disclosures at any
time.
It should also be noted that the validity and enforceability of any
IPR may be challenged for legitimate reasons, and the mere existence
of an IPR disclosure should not automatically be taken to mean that
the disclosed IPR is valid or enforceable. Although the IETF can
make no actual determination of validity, enforceability or
applicability of any particular IPR claim, it is reasonable that a
working group will take into account on their own opinions of the
validity, enforceability or applicability of Intellectual Property
Rights in their evaluation of alternative technologies.
9. Change control for technologies
The IETF must have change control over the technology described in
any standards track IETF Documents in order to fix problems that may
be discovered or to produce other derivative works.
In some cases the developer of patented or otherwise controlled
technology may decide to hand over to the IETF the right to evolve
the technology (a.k.a., "change control"). The implementation of an
agreement between the IETF and the developer of the technology can be
complex. (See [RFC 1790] and [RFC 2339] for examples.)
Note that there is no inherent prohibition against a standards track
IETF Document making a normative reference to proprietary technology.
For example, a number of IETF Standards support proprietary
cryptographic transforms.
10. Licensing requirements to advance standards track IETF Documents
RFC 2026 Section 4.1.2 states: "If patented or otherwise controlled
technology is required for implementation, the separate
implementations must also have resulted from separate exercise of the
licensing process." A key word in this text is "required." The mere
existence of disclosed IPR does not necessarily mean that licenses
are actually required in order to implement the technology. Section
4.1 of this document should be taken to apply to the case where there
are multiple implementations and none of the implementers have felt
that they needed to license the technology and they have no plausible
indications that any IPR holder(s) will try to enforce their IPR.
11. No IPR disclosures in IETF Documents
IETF and RFC Editor Documents must not contain any mention of
specific IPR. All specific IPR disclosures must be submitted as
described in Section 6. Specific IPR disclosures must not be in the
affected IETF and RFC Editor Documents because the reader could be
misled. The inclusion of a particular IPR disclosure in a document
could be interpreted to mean that the IETF, IESG or RFC Editor has
formed an opinion on the validity, enforceability or applicability of
the IPR. The reader could also be misled to think that the included
IPR disclosures are the only IPR disclosures the IETF has received
concerning the IETF document. Readers should always refer to the
on-line web page to get a full list of IPR disclosures received by
the IETF concerning any Contribution. (http://www.ietf.org/ipr/)
12. Security Considerations
This memo relates to IETF process, not any particular technology.
There are security considerations when adopting any technology,
whether IPR-protected or not. A working group should take those
security considerations into account as one part of evaluating the
technology, just as IPR is one part, but there are no known issues of
security with IPR procedures.
13. References
13.1. Normative References
[RFC 2026] Bradner, S., Ed., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC 2028] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, October
1996.
[RFC 2418] Bradner, S., Ed., "Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[RFC 3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004.
13.2. Informative References
[RFC 1790] Cerf, V., "An Agreement between the Internet Society and
Sun Microsystems, Inc. in the Matter of ONC RPC and XDR
Protocols", RFC 1790, April 1995.
[RFC 2339] IETF & Sun Microsystems, "An Agreement Between the
Internet Society, the IETF, and Sun Microsystems, Inc. in
the matter of NFS V.4 Protocols", RFC 2339, May 1998.
14. Acknowledgements
The editor would like to acknowledge the help of the IETF IPR Working
Group and, in particular the help of Jorge Contreras of Hale and Dorr
for his careful legal reviews of this and other IETF IPR-related and
process documents. The editor would also like to thank Valerie See
for her extensive comments and suggestions.
15. Editor’s Address
Scott Bradner
Harvard University
29 Oxford St.
Cambridge MA, 02138
Phone: +1 617 495 3864
EMail: sob@harvard.edu
16. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.