Problems with the IETF's copying permissions

This page explain two problems with the IETF current copying permissions for RFC and other contributions. The current permissions are explained in RFC 3978, also known as BCP 78.

Problem #1: No Rights To Adapt Parts Of Contributions

The license in RFC 2026 [2] gave third parties the right to produce unrestricted derivative works, under some conditions. That right has widely been used to adapt RFCs into online help, reference manuals, source code comments and source code. BCP 78 [1] does not grant any rights to permit this usage. Examples of common usage that is not permitted through BCP 78 include:

  1. Extracting parts of RFCs into source code comments, where the source code is licensed under a license that permits modifications. Line breaks and other simple re-formatting is common. Further re-formatting or expansion, to help explain the source code is not uncommon.
  2. Material needed in source code may include large tables, see StringPrep [9]. It is customary to modify these tables and schemas, without changing the semantic nor affecting protocol interoperability, when implementing these IETF standards. The modifications are because the table as-is is not valid program code. Examples of deployed programs using tables derived from RFC 3454 include GNU Libc/Libidn, VeriSign's XCODE, and IBM's ICU.
  3. ASN.1 schemas from RFCs are often incorporated into products. For example, see the Kerberos 5 [13] ASN.1 schema. These schemas are frequently modified to be usable within particular implementations. Examples of deployed programs using modified ASN.1 schemas for Kerberos 5 include GNU Shishi, MIT Kerberos and Heimdal.
  4. Some RFCs include source code or header files that is meant to be included in software packages, and in practice they are frequently modified after inclusion in the software package. For example, GSS-API C bindings [5], GSS-API Java bindings [6], SHA-1 hash algorithm [7], SCTP checksum [8], Punycode [10], getaddrinfo DNS resolver API [11], multicast socket API [12]. Examples of deployed projects here include GSS-API libraries, libc libraries, and cryptographic packages.
  5. Material used in manuals or online help ("man" pages) may include protocol overviews (such as in SASL [4]) or API function documentation (such as in GSS-API [5]). For example, several vendors, including commercial companies like Sun, ship a man page for getaddrinfo [3] that is derived from RFC 2133.
  6. Educational use. One example that has been presented is to use RFCs in teaching, and make them part of the course material. Further, the RFCs may be modified as part of excercises, e.g., asking students to implement a modified protocol as a lab excercise. There is a desire to include that modified RFC in the course material, which can be distributed freely over the Internet.
  7. Development of protocol extensions. When IETF protocols evolve, that is sometimes done by creating a modified version of an existing implementation to experiment with how well the idea works. For example, the NSEC3 work done in the DNSEXT WG break compliance with DNSSEC. Yet, patches are provided for several DNS implementations that include portions of the RFCs in the source code and documentation. That means that it would be difficult to license a RFC under a "field of use" permission that only allow use for implementation a RFC compliant product. Experiments for protocol extensions may thus be illegal.

This list is far from conclusive, it is meant to illustrate some of the problems the license in BCP 78 causes. We argue that the usage explained in these examples, and others, should be permitted, and that BCP 78 should be updated to resolve this matter. Adding specific text for each kind of usage is problematic, because we do not have a complete list of "good" usages at this point. We believe the license text should be general enough to enable many different kind of usages.

We believe that the license text chosen to resolve this matter should be compatible with licenses typically used for implementions of IETF standards. These range from proprietary closed source licenses, such as Microsoft's End User License Agreement (EULA) [16] or Apple's Mac OS X Software License [17], over permissive licenses such as the MIT license [18], to copy-left licenses such as the GNU General Public License [19]. Further, we also argue that the license text should be aligned with the policy used in popular distribution mechanisms of IETF implementations, such as Debian and their Free Software Guidelines [20].

The revised section in BCP 78 below is believed to resolve this problem.

Problem #2: No Rights Are Granted To Third Parties

Traditionally, third parties have been permitted to copy and distribute Contributions. These rights were granted by the license text in RFC 2026. Reading BCP 78 reveal that it does not grant any rights to third parties that permit this usage. To explain how this is so, we will review the rights granted by BCP 78, and explain where it is failing, and reference discussion of its interpretation.

All rights granted to Contributions, in section 3.3 of BCP 78, begin with (emphasis mine):

a. 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 the ISOC and the IETF under all intellectual property rights in the Contribution:

That means that all the rights given in that section are given to the IETF and the ISOC, but not to third parties. Similar wording occur in section 4.2 on rights granted for RFC Editor contributions. The document do not grant any rights elsewhere.

Scott Bradner claims that section 7.1 give you these rights. However, the entire section 7 is titled "Exposition of why these procedures are the way they are". We believe section 7.1 can thus not be reasonable said to be included in the actual license statement. Rather, it is only part of the considerations that went into the process that ended up with the current license statement.

Another argument that were put forward was that the note "distribution of this memo is unlimited" in RFCs give third parties the necessary rights. However, there is no requirement for that text in RFCs, and it also appear unclear why the RFC Editor still add this text.

This problem was acknowledged through changes between version 00 and version 01 of ietf-ipr-rules-update; changes that, at least partially, address this concern. The revised section below address this concern.

My proposal to fix things

Note that this is a tentative proposal. Everyone is invited to investigate and verify that this text would be sufficient. Your comments are very welcome, please discuss general concerns on the IETF IPR WG mailing list and mail specific comments directly to me.

Include in section 3.3 and 4.2 new text that reads: 

    c.  The Contributor grants third parties the irrevocable
        right to copy, use and distribute the Contribution, with
        or without modification, in any medium, without royalty,
        provided that, unless separate permission is granted,
        redistributed modified works:

             (a) do not contain misleading author, version, name
                 of work, or endorsement information, and

             (b) do not claim endorsement of the modified work by the
                 Contributor, or any organization the Contributor
                 belongs to, the Internet Engineering Task Force
                 (IETF), Internet Research Task Force (IRTF), Internet
                 Engineering Steering Group (IESG), Internet
                 Architecture Board (IAB), Internet Assigned Numbers
                 Authority (IANA), Internet Society (ISOC), Request
                 For Comments (RFC) Editor, or any combination or
                 variation of such terms (including without limitation
                 the IETF "4 diamonds" logo), or any terms that are
                 confusingly similar thereto, and

             (c) remove any claims of status as an Internet Standard,
                 including without limitation removing the RFC
                 boilerplate.

        The IETF suggests that any citation or excerpt of
        unmodified text reference the RFC or other document from
        which the text is derived.

Published document

The current live IETF I-D document is available here:

Revision history

2005-12-13
Revised the draft and published -04, include discussion about warning labels and separating the license for code and text.
2005-12-09
Stichting NLnet publish my trip report about the IPR WG meeting.
2005-12-08
Updated license terms in draft and submitted -03.
2005-12-06
Wrote IPR WG trip report for NLNet Stichting.
2005-11-18
Asked the Debian community and the FreeBSD community to review the license. Discussion is here and here.
2005-11-17
Prepared and updated version -02. Changes in the license text to prevent fake RFCs.
2005-11-03
Updated the document with comments received over the past weeks.
2005-10-22
Prepared the -01 version. Revised this page and document significantly.
2005-10-17
Changed the proposed license based on comments from Ted Hardie.
2005-10-14
Changed license text so it isn't copyleft, and so that redistributing unmodified copies with endorsement claims are permitted.
2005-10-13
The -00 version of my draft was published by the IETF.
2005-10-11
Wrote initial draft and submitted it to the IETF I-D editor. Live document is linked from this page. Received support from several people. Debian Project Leader Branden Robinson suggested a license change (included above) that didn't make it into the -00 document.
2005-10-06
Created this page.

Thank you!

I used to ask for donations to finance my trip to the IETF 64 meeting in Vancouver here. I had paid US$500 on the conference fee, around US$1000 for the plane ticket and around US$350 for the hotel. With the help from a few of you, I managed to collect US$1700, thus covering most of my expenses. Thank you!

I have set aside time to spend on this issue, and will update my proposal and participate in future discussions so that this issue can be resolved. Hopefully with a positive outcome, of course...

If you like to sponsor my activities, to make it possible for me to spend more time on this issue or possibly travel to future meetings, I appreciate any donations. Contact me if you want SWIFT/IBAN bank account details, or click the PayPal button below.

Petition

This page also serve as a petition for an effort to change the current IETF copying conditions to align with typical free and open source software requirements. Please fill out the form below to indicate support of this effort.

Note! If the form doesn't work in your browser, feel free to e-mail me directly.

Your name:
At your discretion, state an association, e.g. "IETF participant", "Mozilla developer", "Debian developer", "Open source company".
Your association:

Current supporters include:

Simon Josefsson