Re: legal consultation (was List moderator action)

For some reason, I suspect because many of us are engineers, the IETF often seems to avoid the simplest solution to a given problem.

We publish lots of RFCs, a very tiny fraction of them use the no derivatives clause.  The pain & hassle of allowing for "no derivatives" vastly outweighs any benefits of allowing it.

At John pointed out, there are loads of alternative ways to publish stuff on the Internet.  Let's just get rid of this (ideally from all streams, but at least the IETF stream) and move on with a very slightly simpler IETF/RFC process than we have today.

Kind regards,
Rob


From: Brian E Carpenter <[email protected]>
Date: Friday, 8 May 2026 at 06:12
To: Simon Josefsson <[email protected]>; Rob Sayre <[email protected]>
Cc: IETF discussion list <[email protected]>
Subject: Re: legal consultation (was List moderator action)

With some help from John Levine, I can tell you that exactly 4 IETF stream RFCs since RFC 5378 carry the "no derivative works" boilerplate: RFCs 5728, 6449, 6667 and 7016.

RFC 8789 makes it highly unlikely there will ever be any more. (Personal opinion: all of those four would have been perfectly appropriate for the Independent stream.)

There are 17 "no derivative works" RFCs in the Independent and IRTF streams.

Regards/Ngā mihi
    Brian Carpenter

On 07-May-26 15:47, Brian E Carpenter wrote:
> 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.)
>
> 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 <[email protected]> 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