]>

San Francisco CA United States of America sayrer@gmail.com

The University of Auckland

School of Computer Science The University of Auckland PB 92019 Auckland 1142 New Zealand brian.e.carpenter@gmail.com

GEN General Area Dispatch derivative This document clarifies that IETF correspondence must not contain legal limitations on derivative works. About This Document Status information for this document may be found at . Discussion of this document takes place on the WG General Area Dispatch mailing list (), which is archived at . Subscribe at .

Introduction This document updates Rights Contributors Provide to the IETF Trust in order to clarify and limit which contributions may include a restriction on derivative rights.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Derivative Works There is an expansive definition of "Contribution" in . There is also a mechanism formally defined in Section 5.3 of that RFC that allows a Contributor to limit the right to produce derivative works. As written, this optional mechanism applies to all Contributions. Using this mechanism outside of specifications, for example, in electronic mail, makes it difficult for people to respond and inhibits collaboration. This behavior impedes the very idea of collaborating about the Internet over the Internet. The IESG has stated that derivative works limitations should only be applied to technical specifications. This document narrows the use of this mechanism to technical specifications, such as Internet-Drafts or other complete specifications. It no longer applies to correspondence, such as public online IETF fora as defined in , appeals, minutes, or audio or video recordings of IETF meetings. Such IETF correspondence MUST NOT include restrictions on derivative works. This restriction covers text that is intentionally inserted and also includes automatically inserted terms inserted by corporate email software. Both variations are disruptive. It is always possible to publish an Internet-Draft with a restrictive derivative works clause. When introducing a document with such a clause, care must be taken to note the restriction. This consideration applies to email and IETF meeting presentations. All other rights Contributors provide to the IETF Trust remain in place.

Security Considerations This document has no direct impact on Internet security.

IANA Considerations This document has no IANA actions.

References Normative References The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The IETF community will treat people with kindness and grace, but not endless patience. This memo obsoletes RFCs 3683 and 3934, and it updates RFCs 2418 and 9245 by establishing a policy for the moderation of disruptive participation across the IETF's various public contribution channels and discussion fora. It establishes guardrails for moderation and a moderator team. That team will develop a set of moderation procedures and facilitate their consistent implementation with chairs and administrators. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References IESG