TOC 
Network Working GroupS. Josefsson
Internet-DraftDecember 14, 2005
Updates:3978 (if approved) 
Expires: June 17, 2006 

RFC 3978 Update

draft-josefsson-ipr-rules-update-05

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 BCP 79.

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 June 17, 2006.

Copyright Notice

Copyright © The Internet Society (2005).

Abstract

Two problems with BCP 78 regarding the outbound rights granted to third parties are identified. A proposal to solve the problems is proposed.

The first problem is that rights granted to third parties in BCP 78 are more restrictive then what was permitted through the license in RFC 2026. The rights granted by the new license is too limited for some uses of Contributions. The uses include adapting portions of Contributions for online help, reference manuals, and source code. The second problem is that rights to publish and distribute documents are not granted to third parties.

We also discuss an issue that has been expressed regarding fake RFCs, that might have been permitted through our earlier license, and we also attempt to solve that problem.



Table of Contents

1.  Introduction
2.  Problem #1: No Rights To Adapt Parts Of Contributions
3.  Problem #2: No Rights Are Granted To Third Parties
4.  Modifications leading to fake works
5.  Revised Section 3.3
6.  Requiring a warning label to be added
7.  Separating the license for code and text
8.  Alternative
9.  Acknowledgments
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements




 TOC 

1. Introduction

This document discuss two problems with BCP 78 (Bradner, S., “IETF Rights in Contributions,” March 2005.) [1]. Familiarity with that document is assumed. Several terms defined in that document are used below. In particular, this document use the term "Contributions" to denote material to which rights are granted. After describing the problems, we conclude with an update to BCP 78 to address the problems.



 TOC 

2. Problem #1: No Rights To Adapt Parts Of Contributions

The license in RFC 2026 (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.) [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 (Bradner, S., “IETF Rights in Contributions,” March 2005.) [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] (Hoffman, P. and M. Blanchet, “Preparation of Internationalized Strings ("stringprep"),” December 2002.). 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 (Neuman, C., Yu, T., Hartman, S., and K. Raeburn, “The Kerberos Network Authentication Service (V5),” July 2005.) [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 (Wray, J., “Generic Security Service API Version 2 : C-bindings,” January 2000.) [5], GSS-API Java bindings (Kabat, J. and M. Upadhyay, “Generic Security Service API Version 2 : Java Bindings,” June 2000.) [6], SHA-1 hash algorithm (Eastlake, D. and P. Jones, “US Secure Hash Algorithm 1 (SHA1),” September 2001.) [7], SCTP checksum (Stone, J., Stewart, R., and D. Otis, “Stream Control Transmission Protocol (SCTP) Checksum Change,” September 2002.) [8], Punycode (Costello, A., “Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA),” March 2003.) [10], getaddrinfo DNS resolver API (Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, “Basic Socket Interface Extensions for IPv6,” February 2003.) [11], multicast socket API (Thaler, D., Fenner, B., and B. Quinn, “Socket Interface Extensions for Multicast Source Filters,” January 2004.) [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 (Myers, J., “Simple Authentication and Security Layer (SASL),” October 1997.) [4]) or API function documentation (such as in GSS-API (Wray, J., “Generic Security Service API Version 2 : C-bindings,” January 2000.) [5]). For example, several vendors, including commercial companies like Sun, ship a man page for getaddrinfo (Gilligan, R., Thomson, S., Bound, J., and W. Stevens, “Basic Socket Interface Extensions for IPv6,” April 1997.) [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) (Microsoft, “Microsoft Licenses,” .) [16] or Apple's Mac OS X Software License (Apple, “Apple Licenses,” .) [17], over permissive licenses such as the MIT license (MIT, “MIT Licenses,” .) [18], to copy-left licenses such as the GNU General Public License [19] (FSF, “GNU Licenses,” .). 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] (Debian, “Debian Social Contract: Free Software Guidelines,” .).

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



 TOC 

3. 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 (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.) [2]. Reading BCP 78 (Bradner, S., “IETF Rights in Contributions,” March 2005.) [1] 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 does not grant any rights elsewhere.

Scott Bradner claims [15] (Bradner, S., “Post to IPR WG mailing list,” .) that section 7.1 gives 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 reasonably 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 adds this text [15] (Bradner, S., “Post to IPR WG mailing list,” .).

This problem was acknowledged through changes between version 00 and version 01 of [14] (Bradner, S., “RFC 3978 Update,” October 2005.); changes that, at least partially, address this concern. The revised section below addresses this concern.



 TOC 

4. Modifications leading to fake works

A fear has been expressed that if modification of IETF Contributions is permitted, it may lead to the distribution of fake works. That is, a work that is based on a IETF published document but modified in a subtle way that cannot easily be identified. The work would be easy to confuse with the original, causing confusion for the community.

David Black proposed to require that modified works would be forced to remove the boilerplate that is used at the beginning of RFCs. The theory is that the fake is not credible if the endorsement by the IETF and the boilerplate is absent.

The license text below incorporate this idea.



 TOC 

5. Revised Section 3.3

This memo adds the following as paragraph 3.3(c) of RFC 3978:

    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.



 TOC 

6. Requiring a warning label to be added

To further protect against works claiming to be the original work, it has been suggested that the license should require that people who modify the contents should be forced to add a "warning label". There are two ways to achieve this. The first is to explicitly suggest the text that is to be added. The second is to implicitly require that text is added, by stating that the derivative works must not be confusable with the original.

The first approach of using a particular warning label may lead to problems when an implementation support many RFCs. If the particular warning label include the RFC number, there may be a potentially huge list of warning labels that only differ in the RFC number. Even if the specific RFC number is not part of the warning label, the text of the warning label may seem inappropriate and confusing in some modified uses, making the reader question what the warning label is adressing.

We believe the second approach, of requiring that implicit warning labels protect against the same abuse but leads to more readable end products.

A license that require warning labels to be added may be incompatible with certain free software licenses, and depending on the language used, it may even make the license non-free. We believe further review by the free software community is required if this solution is to be considered further.

As a starting point for further research, we propose to add the following implicit requirement for warning labels to the license below:

  (d) clearly label a derivative work as such, to avoid
      similarity between the original work and the derivative
      work.



 TOC 

7. Separating the license for code and text

It has been suggested that the license should be separated to cover code and text separately. The intention is supposedly that code can use a free and GPL/BSD-compatible license, whereas the text portion will not.

We argue that this solution is sub-optimal, and in particular it would prevent scenarios including the following:

  1. Excerpts from RFCs included in source code comments. This is a common example, many free IETF implementations embed excerpts from the RFC text in source code comments.
  2. Teaching material derived from RFC texts. University teacher may want to modify RFCs to illustrate a point and as an implementation exercises, and include the resulting work in freely available online course material.
  3. Documentation for IETF implementations. Both FreeBSD and Sun has shipped a getaddrinfo man page that is derived from the RFC. I believe being able to inherit that text from the RFC helped getting getaddrinfo implemented and utilized. If implementations are not permitted to do this, adoption of IETF protocols will likely be slower. If we believe the IETF is producing standards that, if adopted, would benefit the IETF, I believe we should make sure they can be implemented as fast and as widely as possible.

For these reasons, we argue that the same license should be used for both code and text.



 TOC 

8. Alternative

The reader should be aware that another BCP 78 Update proposal has been published [14] (Bradner, S., “RFC 3978 Update,” October 2005.). The change from version 00 and version 01 of that document was to discuss our second problem, i.e., that third parties have no rights to distribute copies of RFCs. However, it does not discuss nor address our first problem.



 TOC 

9. Acknowledgments

The author acknowledges contributions from: David Black, Todd Glassey, Ted Hardie, M. Warner Losh, Francesco Poli, Chuck Powers, MJ Ray, Branden Robinson, Joe Smith, Florian Weimer.

Special acknowledgment is given to Joost van Baal, Markus Demleitner, Nathanael Nerode, Nikos Mavrogiannopoulos, and Wytze van der Raay of Stichting NLNet.

Contributions of many members of the IPR mailing list are gratefully acknowledged.



 TOC 

10. References



 TOC 

10.1. Normative References

[1] Bradner, S., “IETF Rights in Contributions,” BCP 78, RFC 3978, March 2005.


 TOC 

10.2. Informative References

[2] Bradner, S., “The Internet Standards Process -- Revision 3,” BCP 9, RFC 2026, October 1996.
[3] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, “Basic Socket Interface Extensions for IPv6,” RFC 2133, April 1997 (TXT, HTML, XML).
[4] Myers, J., “Simple Authentication and Security Layer (SASL),” RFC 2222, October 1997 (TXT, HTML, XML).
[5] Wray, J., “Generic Security Service API Version 2 : C-bindings,” RFC 2744, January 2000.
[6] Kabat, J. and M. Upadhyay, “Generic Security Service API Version 2 : Java Bindings,” RFC 2853, June 2000.
[7] Eastlake, D. and P. Jones, “US Secure Hash Algorithm 1 (SHA1),” RFC 3174, September 2001.
[8] Stone, J., Stewart, R., and D. Otis, “Stream Control Transmission Protocol (SCTP) Checksum Change,” RFC 3309, September 2002.
[9] Hoffman, P. and M. Blanchet, “Preparation of Internationalized Strings ("stringprep"),” RFC 3454, December 2002.
[10] Costello, A., “Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA),” RFC 3492, March 2003.
[11] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, “Basic Socket Interface Extensions for IPv6,” RFC 3493, February 2003.
[12] Thaler, D., Fenner, B., and B. Quinn, “Socket Interface Extensions for Multicast Source Filters,” RFC 3678, January 2004.
[13] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, “The Kerberos Network Authentication Service (V5),” RFC 4120, July 2005.
[14] Bradner, S., “RFC 3978 Update,” draft-ietf-ipr-rules-update-01 (work in progress), October 2005.
[15] Bradner, S., “Post to IPR WG mailing list,” WWW http://article.gmane.org/gmane.ietf.ipr/2790.
[16] Microsoft, “Microsoft Licenses,” WWW http://www.microsoft.com/licensing/resources/default.mspx.
[17] Apple, “Apple Licenses,” WWW http://www.apple.com/legal/sla/.
[18] MIT, “MIT Licenses,” WWW http://www.opensource.org/licenses/mit-license.html.
[19] FSF, “GNU Licenses,” WWW http://www.gnu.org/licenses/licenses.html.
[20] Debian, “Debian Social Contract: Free Software Guidelines,” WWW http://www.debian.org/social_contract#guidelines.


 TOC 

Author's Address

  Simon Josefsson
Email:  simon@josefsson.org


 TOC 

Intellectual Property Statement

Disclaimer of Validity

Copyright Statement

Acknowledgment