Re: legal consultation (was List moderator action)

Simon Josefsson <simon@josefsson.org> Thu, 07 May 2026 07:16 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 131ADEA565A8 for <ietf@mail2.ietf.org>; Thu, 7 May 2026 00:16:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1778138202; bh=Aa4rF4dN7kzaA3+xyN6iDrFdqKQoH/+TetEihIaDb/I=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=NmdX0YYzQ6tf8FEPjyulVfQh0p9UAlCMA4mQvc9b5CYIvWICe2y82iZbmwAHdKt0J CUq4LWIELFa/3du9mN1uJxON7G3ugnUs4Bza3Nb9vh+v4tpPxMvszNq02N/7gCB793 SIZ7E+VEtJHyJTDV7PlGX9tTt8GTM7lk83Yq3mcM=
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="WDB3MTLQ"; dkim=pass (2736-bit key) header.d=josefsson.org header.b="F7xWIQ5g"
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 dlek7IT20NBb for <ietf@mail2.ietf.org>; Thu, 7 May 2026 00:16:40 -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 40EB3EA56588 for <ietf@ietf.org>; Thu, 7 May 2026 00:16:40 -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=McO/k+63KMPxPYImxtGF+aAGOLOXJLgbmJjjpWqbjXs=; t=1778138198; x=1779347798; b=WDB3MTLQX4pnehB3W2IHCWSYUsfGtwOmngdvkHpCYhPkQ8a4U5PCQZlJcFe+vvP61s4Ae61L6Eh TTK5vvG77Cw==;
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=McO/k+63KMPxPYImxtGF+aAGOLOXJLgbmJjjpWqbjXs=; t=1778138198; x=1779347798; b=F7xWIQ5gNqq9MjHoR9zW64a6ZcE1yo5puDtpOAXNY/NXaj/dJdyyQMX0zP0+CU5rGWPVYHQJPAp Sj4AHubmUucNTrM3Oddh66APfqg02v/DXvO3d+AzGqzfWPPocxZHAGlTGYW1rYOAao+myR8Y6KIIv Kp/2IaNVtfgwaSN5pvtpAggfuzNa+6NC420fhu5qtcspHm3ohOoLig76L4d2eAX3OO90YEnQQwEra RgIon+HAS5UuvqLHDxl9bdHBY41T01m6414aS2RaWkcY8GxURmIqX5bc0n6hABDPCJEi8fLxCXqeI 4OBIoXR3ryyK8aLL+X1LMKCV5+a8iRqQd7dZ++6ui5MHKyL2sSBJ7+imfEIoAD67BC/d8zUPQbg/A WFIfod/mXUq9bAIRtJ/YnbcCy5AiOJ/qE9XBGheku2qz7akUo/ZGMp2/Znukkk1Q2nafcSu6E;
Received: from h-178-174-130-130.a498.priv.bahnhof.se ([178.174.130.130]:37880 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 1wKsyL-005OTB-Ay; Thu, 07 May 2026 07:16:37 +0000
From: Simon Josefsson <simon@josefsson.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: legal consultation (was List moderator action)
In-Reply-To: <c7aae006-be27-4beb-9553-0b8efb4bd600@gmail.com> (Brian E. Carpenter's message of "Thu, 7 May 2026 15:47:57 +1200")
References: <CAChr6Sy1jsjNzh1qMEDVx7ABp_1_uPkfx_tY-T7zPpXTdZiXtQ@mail.gmail.com> <877bpgb7bq.fsf@josefsson.org> <c7aae006-be27-4beb-9553-0b8efb4bd600@gmail.com>
OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt
X-Hashcash: 1:23:260507:brian.e.carpenter@gmail.com::V3VLgnIEgSgEvGBT:Dpjr
X-Hashcash: 1:23:260507:sayrer@gmail.com::OfuSmwarymjBU3J3:YiyG
X-Hashcash: 1:23:260507:ietf@ietf.org::Gl6dd82xYLkgtC+s:0P24P
Date: Thu, 07 May 2026 09:16:38 +0200
Message-ID: <87o6iradux.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: AS34ONB5UBLVXH5K2IWBNIEY62RFEE3T
X-Message-ID-Hash: AS34ONB5UBLVXH5K2IWBNIEY62RFEE3T
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: Rob Sayre <sayrer@gmail.com>, 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/biTw3hnIfJ62Um8958UEAXXni7E>
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>

Brian E Carpenter <brian.e.carpenter@gmail.com> writes:

> Simon,
>
>> Thus, let me propose something stronger: forbid the no-derivative rights
>> clause completely, for all Contributions.
>
> Thr original intention was explicitly to allow the RFC series to
> re-publish 3rd party specifications (whether proprietary, or controlled
> by another SDO).
>
> That might still be useful, but IMHO could, and probably should, be
> done in the Independent Submission stream of RFCs. The Independent
> stream can already permit "no derivative rights" under RFC 5744.
>
> Therefore, IMHO it would be perfectly reasonable to disallow "no
> derivative rights" for all IETF stream contributions. I really
> don't think it will have a chilling effect on new work. (If someone
> is planning a patent, they will not submit a draft anyway.)

I don't have an opinion on that, but that doesn't reduce complexity.

My proposal is to get rid of the complexity stemming from the
no-derivative clause by removing it as an option.

With your proposal, the complexity is increased, and coupling different
streams to different set of legal terms.  It also begs the question how
to deal with a single document switches back and forth between streams,
or handling contributions received for each situation.  If we really
don't want to go down into that complexity rabbit hole, I suggest to
avoid it.

/Simon

> Incidentally, I cannot be certain of this without a lot of work, but
> I strongly suspect that the number of IETF stream documents with a
> "no derivative works" clause published since RFC 5378 is approximately
> zero. (There are many with the "pre5378Trust200902" boilerplate, but there
> is nothing to be done about that and it will remain necessary for some
> "bis" documents.) So I believe that Simon's proposal would have no effect
> whatever on the IETF's output, and would ease our discussions.
>
> Regards/Ngā mihi
>    Brian Carpenter
>
> On 07-May-26 08:40, Simon Josefsson wrote:
>> 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
>