Network Working Group S. Bradner Internet-Draft Harvard University Editor February 2005 Extracting RFCs Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 7, 2005. Abstract Many people have expressed a desire to extract material from IETF RFCs for use in documentation, text books, on-line help systems, and for similar uses. In addition, some IETF RFCs contain MIBs and other types of program code that could be compiled. This document proposes an update to RFC 3667 and 3668 to explicitly permit extracting material for a wide range of uses. RFC 2026 limited the rights the IETF requires of document authors and editors. RFC 2026, and its successors, do not require that the authors permit the creation of derivative works based on their contribution outside of the IETF process. Some people have expressed a desire for the IETF to obtain such permission to enable people outside of the IETF to create derivative works, for example, within Bradner [Page 1] Internet-Draft RFC Extracts February 2005 an open source environment. This document tries to spell out the issues surrounding this desire in order to stimulate discussion within the IETF community about possibly updating RFC 3667 and RFC 3668 to request such rights from RFC authors. Copyright Notice Copyright (C) The Internet Society. (2005) 1. Introduction Section 3.3(a)(E) of RFC 3667 [RFC 3667] requires that the author(s) of IETF contributions grant the IETF the right to make and use certain types of extracts of the contributions for purposes not limited to the IETF standards process. When I wrote that section I intended that to mean that anyone could make such extracts but the wording I used limited the permission to the IETF. This document tries to fix the words to match my intent. Historically RFCs have been assumed to be fair game to anyone who wanted to use text and ideas from an RFC in their own work. The RFC publication process did not explicitly request that RFC authors surrender the right for the creation of such derivative works but no limits to do so were noted in RFCs. Starting with RFC 1602 [RFC 1602] the IETF stared requesting that RFC authors agree to grant specific rights to the IETF regarding the text and ideas in RFCs. These requests were made more explicit in RFC 2026 [RFC 2026] and clarified in RFC 3667. Currently, as defined in RFC 3667, authors must grant to the IETF the right for derivative works to be created within the IETF standards process but the IETF does not request the right for people not working within the IETF standards process to make derivative works. The author(s) may do that on their own if they want but its not part of the rights the IETF requires the author grant as part of RFC publication process. Note that the RFC Editor requires that authors grant the right for anyone to make derivative works as a requirement for the publication of a non-IETF RFC. Note also that authors may explicitly add text to their submission that prohibits the creation of derivative works at all. (See RFC 3667 Section 5.2.) Recently there has been considerable discussion on the IETF IP working group mailing list about the implications of the IETF not requiring that authors grant the right for anyone to create derivative works from RFCs. This document discusses the issue and is intended to serve as a catalyst for discussion. 2. Extractions from RFCs I see no reason to limit the ability for people to make and use extracts from RFCs as long as the extract is not modified and that Bradner [Page 2] Internet-Draft RFC Extracts February 2005 proper acknowledgement is given and the ISOC copyright notice is included. Thus I propose that something like the following be added to RFC 3667 as Section 3.3(c): c. To the extent that a Contribution or any portion thereof is protected by copyright and other rights of authorship, the Contributor, and each named co-Contributor, and the organization he or she represents or is sponsored by (if any) grant a perpetual, irrevocable, non-exclusive, royalty-free, world-wide right and license to extract, copy, publish, display, distribute, and incorporate into other works, for any purpose (and not limited to use within the IETF Standards Process) any portion of the Contribution as long as the extract is not modified, proper acknowledgement is given and as long as the ISOC copyright notice is included. It also being understood that the licenses granted under this paragraph (c) shall not be deemed to grant any right under any patent, patent application or other similar intellectual property right disclosed by the Contributor under [IETF IPR]). 3. Unrestricted derivative works A number of people have expressed the opinion that it should be possible for anyone to modify and republish a RFC if they feel that they can improve on the technology described in the RFC. A number of messages to the IETF IP working group mailing list asserted that the open source development process depends on the ability to do this. As noted above, historically this was possible with RFCs until RFC 2026 changed things so that modifications had to be done within the IETF standards process unless the author had given specific permission for modifications to be done elsewhere. The IETF is not alone in not providing the right to make unrestricted derivative works. The W3C, the ITU, ANSI, IEEE, etc all restrict the ability to make derivative works based on their specifications. I have not found a standards organization that permits it (but I'm sure that it will be pointed out if there are such standards organizations. Disclaimer: I do not think that granting the unrestricted ability to make derivative works is a good thing for the IETF to do so I expect the following list of advantages is far from complete. 3.1. Advantages of the unrestricted ability to make derivative works 3.1.1. Support for open source The assertion was made by a number of posters to the IETF IPR working group mailing list that the open source community requires the unrestricted ability to make derivative works. 3.1.2. Speed of technological evolution Bradner [Page 3] Internet-Draft RFC Extracts February 2005 It is clear that there would be more rapid evolution of technology standards if anyone could create their own variation and document it so that others could implement and support that version. 3.2. Disadvantages of the unrestricted ability to make derivative works 3.2.1. Confusion over what constitutes the standard It would clearly be confusing if someone could take an IETF standard such as RFC 3270 (MPLS Support of Differentiated Services), change a few key words and republish it, maybe in a textbook, as the definitive standards for MPLS Support of Differentiated Services. The IETF could, as Larry Rosen suggested create a process whereby the IETF could create a certification mark and a process to ensure that the mark was only used on products that implement the IETF version but that would be adding a lot of extra effort of a type that the IETF has not shown itself to be very good at. 3.2.2. Architecturally agnostic modifications IETF working groups undertake a great deal of effort to develop a common understanding of the underlying architectural assumptions of the standards they develop. Modifications or extensions to a standard done without an understanding of those architectural assumptions may easily introduce significant operational or security issues. The best place to extend a standard is in the working group that developed it because they know what the underlying assumptions are and can properly ascertain if the modification or extension is something that fills a real need (and not just a local optimization of something that can already be done) and if its done in a way that does not break the existing standard. 3.2.2. Cooperation between standards organizations Many standards development organizations (SDOs) are now working in the technology areas that were once the nearly exclusive territory of the IETF. This increased standards activity can be very good for innovation but frequently other standards organizations have decided that IETF technologies are almost, but not quite, right for them to use. If it were perfectly OK for such an SDO to publish a modified version of an IETF standard as one of their own standards (and most likely publish it in a way that bans the creation of derivative works) it would distort the standards playing field. I think that SDOs working in the same or overlapping areas should cooperate with each other not try to usurp the other SDO's work. Just as the IEEE would not like it if the IETF to republish a modified specification for 802.11 and the ITU-T would not like it if the IETF were to republish a modified version of the specification of SONET/SDH, neither of these organizations should assume that they are encouraged to create modified versions of IETF specifications. 3.2.3. Restricting open source Bradner [Page 4] Internet-Draft RFC Extracts February 2005 I do not buy the argument that the open source community requires the ability to make capricious changes in standards. I fully agree that the IETF should place no restrictions on the ability of anyone to implement an IETF standard (some people or companies claiming patent rights might do so but that is not something the IETF should do). I do not see that the open source community requires the ability to create a modified and incompatible version of ATM signaling or of the Ethernet backoff algorithm. If someone in the open source community thinks they have a better idea then they should present that idea to the standards organization that developed the technology to see if the standards organization agrees. The open source community does not have this ability with the output of other standards organizations, I do not see justification to say that its OK to do so for Internet technology. It seems to be perfectly reasonable for an open source development effort to implement a standard rather than assume they know better. 3.3. Call for discussion The question of the IETF's getting from RFC authors the right to let anyone create derivative should be discussed on the IETF IP working group list and in the next meeting. Adding something like the following as Section 3.3.(c) to RFC 3667 would make the change: c. To the extent that a Contribution or any portion thereof is protected by copyright and other rights of authorship, the Contributor, and each named co-Contributor, and the organization he or she represents or is sponsored by (if any) grant a perpetual, irrevocable, non-exclusive, royalty-free, world-wide right and license to extract, modify, copy, publish, display, distribute, and incorporate into other works, for any purpose (and not limited to use within the IETF Standards Process) any portion of the Contribution as long as proper acknowledgement is given and as long as the ISOC copyright notice is included. It also being understood that the licenses granted under this paragraph (c) shall not be deemed to grant any right under any patent, patent application or other similar intellectual property right disclosed by the Contributor under [IETF IPR]). 4. Other problems in what RFC 3667 requires from authors Sam Hartman posted a note to the IETF IPR working group mailing list in which he said that he was not sure that the current granting of rights on RFC 3667 was sufficient to cover the case where he too text from an existing standard to use in a new RFC since he felt that he might not be able to fulfill the Internet-Draft boilerplate requirements. (http://www1.ietf.org/mail-archive/web/ipr- Bradner [Page 5] Internet-Draft RFC Extracts February 2005 wg/current/msg02677.html) I'm not sure there is a problem but the working group should explore the issue to see if a change is needed to fix the problem Sam sees. 5. References 5.1. Normative References [RFC 3667] Bradner, S., Ed., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. 5.2. Informative References [RFC 1602] IAB, IESG, "The Internet Standards Process -- Revision 2", RFC 1602, March 1994. 6. Editor's Address Scott Bradner Harvard University 29 Oxford St. Cambridge MA, 02138 Phone: +1 617 495 3864 EMail: sob@harvard.edu 7. 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 Bradner [Page 6] Internet-Draft RFC Extracts February 2005 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. Bradner [Page 7]