1. Unrestricted Derivative Works Scott Bradner sob@harvard.edu

2. Problem some people want ability to modify and redistribute RFCs i.e., “open standards” like “open source” RFC 3667/3668 do not ask ID authors for the right to permit that

3. Proposal add something like this to RFC 3667 sec 3.3 c. 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 anyone to extract, modify copy, publish, display, distribute, and incorporate into other works, for any purpose (and not limited to use within the IETF Standards Process) any portion of the Contribution as long as proper acknowledgement is given and as long as the ISOC copyright notice is included....

4. Proposal, contd. It also being understood that the licenses granted under this paragraph (c) shall not be deemed to grant any right under any patent, patent application or other similar intellectual property right disclosed by the Contributor under [IETF IPR]). might go someplace other than as sec 3.3 (c)

5. Reasons to Permit Unrestricted Derivative Works support for open source open source (at least in some licenses) means permission to modify and redistribute code removing restrictions on the ability to modify and redistribute RFCs would fit the same mold enable more rapid evolution better respond to technological change better respond to bugs

6. Reasons to Not Permit Unrestricted Derivative Works confuses the marketplace minimizes likelihood of interoperability devalues the concept of standards assumes individuals know better than working group consensus encourages architecturally agnostic modifications

7. More Reasons to Not Permit Unrestricted Derivative Works confuses relationships between SDOs no agreement that open source needs ability to unilaterally modify standards does not have that ability with most technology

8. History historically (pre RFC 2026) extracting and modifying RFCs was permitted but nothing in the RFCs specifically stated that this was OK still the case for RFC Editor RFCs