Filter by topic and date
At Long Last, A Revised Patent Policy for IETF: What’s Behind BCP79bis?
- Scott O. Bradner
- Jorge Contreras
14 Jul 2017
Working on technical standards in the computing, communications and networking industries often involves dealing with patents. Like most standards-development organizations (SDOs), the IETF has policies that deal with patents covering IETF protocols, specifications and standards.
The IETF’s first patent policy appeared in RFC 1310 (Mar, 1992), but the basis for today’s policy approach originated with RFC 2026 (October 1996), which still defines many aspects of the Internet Standards Process. The first major overhaul of this policy occurred a decade later in RFC 3979 (also designated as BCP 79). Though the IETF’s policies relating to copyrights, open source code and other forms of intellectual property (IPR) evolved, particularly after the formation of the IETF Trust in December 2005, the IETF’s patent policy remained relatively stable for more than 20 years.
As stated in RFC 2026, the overall intention of these policies has been to benefit the Internet community and the public at large, while respecting the legitimate rights of others, and that remains the case today.
As originally codified in RFC 2026, the IETF patent policy states that anyone who makes a contribution to an IETF specification or standard must disclose any patents held by the contributor or his/her employer which cover or may cover the contribution and are “reasonably and personally known” to the contributor, as well as any such patents that cover contributions of others. If an IETF participant knows of third party patents covering some aspect of an IETF document, disclosure is voluntary. Unlike many SDOs, the IETF does not require that patent holders make any particular commitment to license their patents on fair, reasonable and non-discriminatory (FRAND) or any other terms (a discussion of the history behind this approach can be found here). However, the IETF provides a facility (the IPR Disclosure Form) whereby patent holders can voluntarily disclose their licensing terms, and many make use of this facility to declare, for example, that they will not assert patents against implementations of IETF standards except in defensive situations.
In 2010, following a period of extensive discussion of IPR policies in the industry and at other SDOs, and with the completion of a major overhaul of the IETF copyright policy in 2008 (RFC 5378/BCP78), we began to consider updating BCP 79 to reflect current practices at the IETF, as well as the evolving roles of the RFC Editor, IETF Secretariat, IETF Executive Director, IRTF, IAB and other groups operating within IETF.
This was not a quick process. We began work in 2010 and held a first BOF at IETF 81 in Quebec City (July 2011). We published a -00 version of a revised policy in December 2012 and held a second BOF at IETF 87 in Berlin (July 2013). We received comments and input from a wide range of community members, legal counsel and interested parties. The Internet-Draft went through 13 versions and was finally published as RFC 8179 in May 2017, seven years after we began to work on it.
The principal changes that RFC 8179 introduced to BCP 79 are described in Section 13 of the document. A quick summary of the highlights is below:
What’s a Contribution to the IETF? — Over the years, the modes in which IETF work takes place have changed. We updated BPC 79 to reflect the reality that technical contributions are made in BOFs, and online via chat rooms and other online fora. In addition, we have clarified the rules regarding oral contributions and when they trigger a requirement to disclose patents.
What is Participation in the IETF? – Many of the obligations imposed by BCP 79 apply to persons who “participate” in IETF standardization activities. So what does “participate” mean? Does it include walking into a meeting room where a discussion is taking place, sitting in the back saying nothing, or silently “lurking” on an email list? In BCP 79bis, we clarify that participation in the IETF means either making a contribution or “in any other way acting in order to influence the outcome of a discussion relating to the IETF Standards Process”. Thus, silently rolling your eyes or giving a thumb’s down during a technical presentation could subject you to the IETF’s disclosure requirements.
What to Disclose? – In addition to information regarding a patent and the portion(s) of an IETF document that it covers, the inventor(s) must now be disclosed.
Updating Disclosures – We have added a lot of needed detail around the process for updating IPR disclosures, including when such updates are required and how they should be made.
Licensing Declarations – When a person or company makes a voluntary statement about the terms on which it will license its patents covering IETF standards, that statement is viewed as binding and irrevocable so that others may rely on it.
General Disclosures – We updated the procedures relating to voluntary disclosures that are not required by the IETF rules. These disclosures of patents potentially covering IETF documents can be made by anyone and will be posted on the IETF IPR Disclosure page. We also clarified that required disclosures that are deficient in some way (e.g., they omit some required information) are also posted.
Failure to Disclose – We outline some of the remedial measures that can be taken when the IETF disclosure rules are violated, including IESG actions described in RFC 6701.
Evaluating Alternative Technologies – We provide some guidelines around the consideration of patent and licensing disclosures by IETF WGs. We also discuss some areas in which royalty-free licensing is preferred, such as security technology.
Alternate Streams – We have made it easier for other groups using the IETF RFC publication process, such as the RFC Editor, IAB and IRTF, to adopt the IETF patent policy.
As you can see, the changes are mostly clarifications; the basic patent policy remains as it was defined in 1996. Changes in patent law or patent practice may, at some point in the future, necessitate an update to RFC 8179, but that will be someone else’s task.