Re: [Gendispatch] New Version Notification for draft-thomson-gendispatch-rfc-derivatives-00.txt

Joel Halpern <jmh@joelhalpern.com> Fri, 29 September 2023 16:09 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: gendispatch@ietfa.amsl.com
Delivered-To: gendispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087A9C151555 for <gendispatch@ietfa.amsl.com>; Fri, 29 Sep 2023 09:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.196
X-Spam-Level:
X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.091, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FC7CfTVEKH9k for <gendispatch@ietfa.amsl.com>; Fri, 29 Sep 2023 09:09:26 -0700 (PDT)
Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46144C1519A3 for <gendispatch@ietf.org>; Fri, 29 Sep 2023 09:08:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 4RxwHk73c1z5bqgh; Fri, 29 Sep 2023 09:08:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1696003698; bh=0M1RbHQVGfNVgMeFqArOp2MV7yzsaoWHct24U0l17Ic=; h=Date:Subject:To:References:From:In-Reply-To:From; b=cNFVocuQ8520GgQ9zFO/Vbe4Nbw9kXFv9t1t3drYMBGBD/HDLBzXdDVJgP36HZlZ6 ADVStCJ99YCTfxgMLutiElaNmRorIxAixMNobrqrp0QuLulY+e8z5qZ8WVzfM6k69y eNwIvn/foCN//Rbbf9ZDRM+zXVSnZykkIpSTLIfQ=
X-Quarantine-ID: <hu-ITzvLWD3C>
X-Virus-Scanned: Debian amavisd-new at b1.tigertech.net
Received: from [192.168.20.19] (unknown [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 4RxwHk36ZNz5bqXw; Fri, 29 Sep 2023 09:08:18 -0700 (PDT)
Message-ID: <f5f4a783-90e0-abdd-1510-f33f90d6af84@joelhalpern.com>
Date: Fri, 29 Sep 2023 12:08:17 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1
Content-Language: en-US
To: Martin Thomson <mt@lowentropy.net>, gendispatch@ietf.org
References: <169587871859.41935.17692726615817157868@ietfa.amsl.com> <3c7a5635-6a18-445e-9483-22ebfe31e1d5@betaapp.fastmail.com>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <3c7a5635-6a18-445e-9483-22ebfe31e1d5@betaapp.fastmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/w4CArh2NfRoLqg5-vOv8k-kcc6k>
Subject: Re: [Gendispatch] New Version Notification for draft-thomson-gendispatch-rfc-derivatives-00.txt
X-BeenThere: gendispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: General Area Dispatch <gendispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gendispatch/>
List-Post: <mailto:gendispatch@ietf.org>
List-Help: <mailto:gendispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Sep 2023 16:09:31 -0000

Let me ask a very basic question.  When I look at the draft, I see a 
general assertion that relaxing control would be good.  But the draft 
does not actually include any description of what problem needs to be 
addressed, much less any discussion of the benefits and costs of the 
change being proposed.  Without those, we each seem to be discussing our 
own imagined situations.  (Eliot seems to have tried to lay out one set 
of drawbacks.)

Given that we have an established policy, with widespread and long term 
community support, I would think we would need a clear and significant 
problem before we would entertain changing it.

Yours,

Joel

On 9/28/2023 1:50 AM, Martin Thomson wrote:
> I raised a question during the IETF 117 plenary.
>
>> https://www.ietf.org/archive/id/draft-thomson-gendispatch-rfc-derivatives-00.html
>> https://datatracker.ietf.org/doc/html/draft-thomson-gendispatch-rfc-derivatives
>>
>> Abstract:
>>
>>     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 is a relatively simple request, but - based on previous discussions on this subject - I'm sure it will be quite controversial.
>
> Firstly, there is no plan (at least that I'm aware of) to fork the IETF or to take any RFC to another venue.  The authors are pursuing this work because we believe that it is the right thing to do. We believe that this change is consistent with the IETF mission and the principles of open standards that this community abides by.
>
> More liberal licensing on RFCs will make it easier for people to continue with the maintenance of IETF work, especially when the IETF has no desire or ability to do so itself.
>
> This would go beyond the excerpting licenses that are included in some RFCs (for example, RFC 6716), where people independently license their contributions independent of the license they grant the IETF Trust, or the inconsistent fair use carve-outs that are available in some jurisdictions.
>
> Some people have observed that this makes it easier to copy IETF work with the intent of confusing the market.  We have requested the inclusion of what we think are reasonable conditions in the draft.  These conditions are targeted at the potential for misrepresentation and include a requirement to acknowledge the original and its authors, plus a stipulation that protocols use a different name.
>
> The best defense against this sort of abuse is not copyright protections.  My non-legally-trained understanding is that the IETF cannot copyright a protocol anyway, only its specification can be protected. Our best defense is the quality of the work performed here and the excellent reputation of this institution.
>
> If there is time on the (already packed) gendispatch agenda, I'd appreciate it if some time could be made for this topic.
>
> Cheers,
> Martin
>