| Internet-Draft | RFC Derivative Works | September 2023 |
| Thomson, et al. | Expires 31 March 2024 | [Page] |
The IETF Trust holds rights to RFCs. This document updates RFC 5377 to request that the IETF Trust change its licensing for IETF documents to permit the creation of derivative works.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://martinthomson.github.io/rfc-derivatives/draft-thomson-gendispatch-rfc-derivatives.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-thomson-gendispatch-rfc-derivatives/.¶
Discussion of this document takes place on the General Area Dispatch Working Group mailing list (mailto:gendispatch@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/gendispatch/. Subscribe at https://www.ietf.org/mailman/listinfo/gendispatch/.¶
Source for this draft and an issue tracker can be found at https://github.com/martinthomson/rfc-derivatives.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
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."¶
This Internet-Draft will expire on 31 March 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The IETF produces RFCs to further its mission [RFC3935] of improving the Internet. Intellectual property rights for these documents are held by the IETF Trust [BCP101].¶
Previous advice to the IETF Trust [ADVICE] was that usage rights for IETF documents be limited to copying and translations. This can have the effect of granting the IETF monopoly rights over the maintenance of work that is published in IETF documents.¶
This document revises the advice to the IETF Trust given in RFC 5377 to expand the rights granted in relation to IETF documents to include the ability to create derivative works.¶
The IETF Trust, by way of its Trustees, has indicated that it will respect the wishes of the IETF in regard to the rights it will grant in relation to RFCs. It is therefore the IETF's responsibility to articulate those wishes.¶
The mission of the IETF [RFC3935] is to make the Internet better. This is primarily achieved by producing documents, RFCs, that define interoperable Internet protocols. The IETF also publishes RFCs that further this mission in other ways, including Best Current Practice (BCP), Informational, and Experimental documents.¶
Over time, the IETF has published documents on a very wide range of topics. The quality of IETF publications depends on the ability for the IETF to find a sufficient number of participants with expertise in the topic area.¶
The IETF has an excellent reputation as a venue for the standardization of Internet protocols. The protocols and documents produced by the IETF are well respected. The IETF enjoys strong ongoing support and so appears to be a good choice of venue for standardization in the areas in which the community has strong expertise.¶
Should the IETF be unable to attract adequate depth of expertise to produce a revision of existing work, another organization might have that expertise. In the most extreme case, the IETF could fail entirely or cease to be a viable venue for standardization, making it necessary to produce revisions in another venue. Licensing that permits the creation of derivative works could allow another organization to perform necessary maintenance or revisions.¶
The licensing terms generated in response to RFC 5377 [ADVICE] do not permit the creation of derivative works. This could unduly give the IETF an monopoly over the maintenance of protocols that are published as IETF documents.¶
While contributors are able to provide a license for this purpose, that depends on securing permission from all contributors. The collaborative nature of IETF work makes it difficult to obtain this sort of license. In many cases it may not even be practical to determine all the contributors and contact them. The IETF Trust is in a position to make more permissive terms more readily available for all new documents.¶
Similar considerations apply to other document streams: IAB, IRTF, or independent submissions [RFC4844]; however, see Section 4.¶
This document advises the IETF Trust to amend the license for IETF Documents (RFCs and Internet-Drafts) [LICENSE] to permit the creation of derivative works.¶
This is in addition to the rights granted under the existing license [LICENSE].¶
The IETF Trust is requested to ensure that any license permitting the creation of a derivative work stipulates that the original work be clearly identified. Derivatives also need to clearly attribute authors and contributors of the original.¶
The IETF Trust is advised to make the license to create derivative works conditional on the use of a distinct protocol name when creating new versions of existing protocols. This need not apply to reused or copied protocol elements or fields; it only applies to the protocol, extension, or component that is being revised.¶
The IETF Trust should maintain the ability to permit the reuse of a name in appropriate cases, such as when the IETF agrees to transfer development of a protocol to a different organization or where the IETF has decided not to take up a given piece of work and the proponents bring it elsewhere.¶
The potential for confusion about the status of a derivative work is not completely avoidable. However, the requirement to use a new name for protocols or mechanisms ensures that names are not used to compound any potential confusion.¶
The IETF Trust is also responsible for licensing terms on documents that are produced in relation to the activity of other RFC streams (IRTF, IAB, and independent). The IETF cannot advise the IETF Trust as it relates to licenses on RFCs published in these other streams.¶
Ideally, other streams would adopt the amended license terms, as they have done for the existing license [LICENSE]. That would ensure consistency across the RFC series and for work contributed to other streams. However, this document cannot serve as advice from other streams; it can only capture IETF consensus.¶
As noted in [LICENSE], IETF documents published prior to the effective date of that license are subject to other licensing provisions. The IETF Trust is not requested to attempt to secure the ability to alter the license terms for these documents.¶
This document is purely procedural in nature and therefore raises no new concerns that might affect the security of Internet users. However, ensuring that proper protocol maintenance can be conducted by qualified and motivated experts could improve security.¶
This document has no IANA actions.¶
TODO acknowledge.¶