Re: legal consultation (was List moderator action)

Simon Josefsson <simon@josefsson.org> Wed, 06 May 2026 20:40 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: ietf@mail2.ietf.org
Delivered-To: ietf@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id DA3B0EA270D3 for <ietf@mail2.ietf.org>; Wed, 6 May 2026 13:40:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1778100046; bh=8GFGNKqeES696/H7ePg6HvLxQF80DTmOaDYa6SMe6qA=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=p6s+93T9YyGqOO09nAYym1OBhMneqz+Eq/JqIRgjZ3ba+A6qYTxJV113lwrq72Eiw lD9NgfMkeA4IQATUEtlMpjjaKbtGQhGSwbpYhFAYB7d30R5bZfcGcvbTu6Wf0vPDJN PcWbQdZYiilxaYp6EKbje0HvaNxC6JAqcG3QkEz4=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.401
X-Spam-Level:
X-Spam-Status: No, score=-4.401 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=josefsson.org header.b="i2nEQna6"; dkim=pass (2736-bit key) header.d=josefsson.org header.b="XtEhjhKy"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6EGKtZYuNvV for <ietf@mail2.ietf.org>; Wed, 6 May 2026 13:40:42 -0700 (PDT)
Received: from uggla.sjd.se (uggla.sjd.se [IPv6:2001:9b1:8633::107]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 8543BEA2701F for <ietf@ietf.org>; Wed, 6 May 2026 13:40:11 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=ed2303; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=vNu7p0N0lAVjHNc0X3aTIO9YG4cY0wy2UKVA6oNQmYM=; t=1778100009; x=1779309609; b=i2nEQna6jb1jAYbFshTP+FiqKnCo1lAk1zjqZQQDP6PcRefXm0J9MFqIGKBxrMM2lrK4VpW32I2 I61hdD6eMBg==;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=rsa2303; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=vNu7p0N0lAVjHNc0X3aTIO9YG4cY0wy2UKVA6oNQmYM=; t=1778100009; x=1779309609; b=XtEhjhKyPb7aJaPsSJjeQOB1PoCSWzq3f4sZyt1AaA2JC5TF2H7KRNdYx1SvB3dBw3vwAjtvEvN GJzx922ovvlCtUO4/vC9J49A2oiHvzB7NgknsZoP9mYuuLP7gLAA1n7wcPSpRgXLofZwUaXuX5ViU bYgX5rsJKN1bCe5S2KuM4LELi8IsGmn1MYDLQS43TGLof/tqEkA3TaxykXjuSumve/+gGIgNIUQA0 0meTbG9Mi0hOwW9YeJFxZA05N4O8qkc5Benqj/xdUpusKiHZ/x8jbNAtk9rILaNMvTc65oZXHX3Ce hZBsKlPhO62+a+D4tgmAD/idYWXNK1YA+8igeQ7wPCvTNLFVcYb7UBgzJaPIyio5t7Nrs+9EVMuYB Sf7HpwHNx05oSyhWjcQCHiKM64e8Q8PMn6Cg6PQNbbCfvpsLVXCVWgKtGE6Hagk1khFhYbLrb;
Received: from h-178-174-130-130.a498.priv.bahnhof.se ([178.174.130.130]:56204 helo=frallan) by uggla.sjd.se with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <simon@josefsson.org>) id 1wKj2O-004bud-Ql; Wed, 06 May 2026 20:40:08 +0000
From: Simon Josefsson <simon@josefsson.org>
To: Rob Sayre <sayrer@gmail.com>
Subject: Re: legal consultation (was List moderator action)
In-Reply-To: <CAChr6Sy1jsjNzh1qMEDVx7ABp_1_uPkfx_tY-T7zPpXTdZiXtQ@mail.gmail.com> (Rob Sayre's message of "Wed, 6 May 2026 12:56:28 -0700")
References: <CAChr6Sy1jsjNzh1qMEDVx7ABp_1_uPkfx_tY-T7zPpXTdZiXtQ@mail.gmail.com>
OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt
X-Hashcash: 1:23:260506:sayrer@gmail.com::uWmr9zHQSYGe7fQ1:0pAy
X-Hashcash: 1:23:260506:ietf@ietf.org::7I40W5s79B6DeM4I:4gTy
Date: Wed, 06 May 2026 22:40:09 +0200
Message-ID: <877bpgb7bq.fsf@josefsson.org>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Message-ID-Hash: LDETCRNGU73C7EVVN73QQGXCC2R3O3FB
X-Message-ID-Hash: LDETCRNGU73C7EVVN73QQGXCC2R3O3FB
X-MailFrom: simon@josefsson.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ietf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: IETF discussion list <ietf@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/1UiMVtpqrysu27chvjPTzqin-Ns>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Owner: <mailto:ietf-owner@ietf.org>
List-Post: <mailto:ietf@ietf.org>
List-Subscribe: <mailto:ietf-join@ietf.org>
List-Unsubscribe: <mailto:ietf-leave@ietf.org>

Rob Sayre <sayrer@gmail.com> writes:

> Hi, I wrote it up:
>
> https://datatracker.ietf.org/doc/draft-sayre-gendispatch-derivative/

Thanks for writing that.

I don't think it make sense to permit I-D's to prohibit derivative works
and at the same time forbid presentation or e-mail posts about the I-D
to use the same clause.  It seems hard to discuss or present a
no-derivative I-D in a presentation that can be derived by others and
re-used in other's Contributions.  The policy should be consistent
regardless of the form of contribution, which I believe it currently is.

Thus, let me propose something stronger: forbid the no-derivative rights
clause completely, for all Contributions.

I wonder what people think about that?

Has it been a net-win for the IETF to permit Contributions under the
no-derivative rights clause?  The approach was designed in a different
era, where (IIRC) external SDOs/people could gauge IETF-interest for
some piece of work without giving up rights.

I still think no-derivative rights contributions may be useful, so I'm
not sure it is possible to reach consensus to kill the concept.  Scott
Bradner has explained earlier some of the original rationale, and I
think that had a point.

/Simon

> I'm happy for anyone to take that off my hands and create a derivative work.
>
> In off-list discussion, it was clarified that Section 3 and Section 4 are
> non-normative.
>
> thanks,
> Rob