Network Working Group S. Josefsson
Internet-Draft November 17, 2005
Updates: 3978 (if approved)
Expires: May 21, 2006
RFC 3978 Update
draft-josefsson-ipr-rules-update-02
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 May 21, 2006.
Copyright Notice
Copyright (C) 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
Josefsson Expires May 21, 2006 [Page 1]
Internet-Draft RFC 3978 Update November 2005
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem #1: No Rights To Adapt Parts Of Contributions . . . . 3
3. Problem #2: No Rights Are Granted To Third Parties . . . . . . 5
4. Modifications leading to fake works . . . . . . . . . . . . . 6
5. Revised Section 3.3 . . . . . . . . . . . . . . . . . . . . . 6
6. Alternative . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Josefsson Expires May 21, 2006 [Page 2]
Internet-Draft RFC 3978 Update November 2005
1. Introduction
This document discuss two problems with BCP 78 [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.
2. 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.
Josefsson Expires May 21, 2006 [Page 3]
Internet-Draft RFC 3978 Update November 2005
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.
Josefsson Expires May 21, 2006 [Page 4]
Internet-Draft RFC 3978 Update November 2005
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 [2]. Reading BCP 78 [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] 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].
This problem was acknowledged through changes between version 00 and
version 01 of [14]; changes that, at least partially, address this
concern. The revised section below addresses this concern.
Josefsson Expires May 21, 2006 [Page 5]
Internet-Draft RFC 3978 Update November 2005
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.
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 redistributed modified works do not contain
misleading author or version information. This
specifically imply, for instance, that redistributed
modified works must remove any references to endorsement
by the IETF, IESG, IANA, IAB, ISOC, RFC Editor, and
similar organizations and remove any claims of status as
Internet Standard, e.g., by removing the RFC boilerplate.
The IETF requests that any citation or excerpt of
unmodified text reference the RFC or other document from
which the text is derived.
6. Alternative
The reader should be aware that another BCP 78 Update proposal has
been published [14]. 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.
7. Acknowledgments
Josefsson Expires May 21, 2006 [Page 6]
Internet-Draft RFC 3978 Update November 2005
The author acknowledges contributions from: David Black, Todd
Glassey, Ted Hardie, Francesco Poli, Branden Robinson, 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.
8. References
8.1. Normative References
[1] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978,
March 2005.
8.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.
[4] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
[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)",
Josefsson Expires May 21, 2006 [Page 7]
Internet-Draft RFC 3978 Update November 2005
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.
Josefsson Expires May 21, 2006 [Page 8]
Internet-Draft RFC 3978 Update November 2005
Author's Address
Simon Josefsson
Email: simon@josefsson.org
Josefsson Expires May 21, 2006 [Page 9]
Internet-Draft RFC 3978 Update November 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Josefsson Expires May 21, 2006 [Page 10]