Re: no no derivatives, was legal consultation (was List moderator action)

[John C Klensin <[e-mail]>]

--On Friday, May 8, 2026 17:23 +1200 Brian E Carpenter
<[e-mail]> wrote:

> On 08-May-26 14:11, John C Klensin wrote:
>> Brian,
>> 
>> Let me split a hair or two:  There are strong arguments (already
>> made in notes you may not have read yet) for allowing "no
>> derivatives" for an initial I-D for the "bring into some sort of
>> discussion with an AD about sponsorship or into a DISPATCH process
>> to see if the IETF is interested".  That set of arguments would
>> almost certainly apply to published RFCs, especially in the IETF
>> Stream.  I'd hate to make a rule that would then tangle us up in
>> special cases, but, in general, that reason for allowing "no
>> derivatives" probably would not only apply to drafts a WG has
>> agreed to examine, ones dispatched to a WG, or ones that an AD had
>> agreed to sponsor.  Except in very odd cases that I have trouble
>> imagining, I wouldn't expect to see such a disclaimer on the
>> second (i.e., -01) version of an I-D.  A rule that we didn't want
>> to allow a "no derivatives" clause in a published RFC would have
>> zero impact on such an "is the IETF interested" I-Ds.
> 
> Assuming that be "we" you mean the IETF stream, yes. And as I have
> said elsewhere, RFC 8789 essentially does this already, but means
> that it could still be done in unusual circumstances (such as you
> describe below).

I was deliberately not restricting my comments to the IETF stream
because all of the other streams, except the ISE, have community
discussion (even if not consensus) requirements.  And the ISE has a
requirement for IESG review of documents and either the ISE or the
IESG may open those reviews to broader discussions.  

> So if we want to close this discussion, something like
> draft-sayre-gendispatch-derivative is probably sufficient, but
> I'm pretty sure it will need close scrutiny by counsel.

Agree about the close scrutiny part.  I'm not going to guess at what
the lawyers might say.  But, even (or especially) if we focus on the
IETF stream, I believe that allowing an I-D to progress into active
WG consideration and even IETF LC with a "no derivatives"
restrictions creates (as I think we have seen already) a situation in
which participants would need to consider how to make comments very
carefully out of fear.  That fear would often be less about whether
some language or, e.g., proposals of alternate text and how they are
made, violated the rules but about concerns of setting off
discussions about whether they are violating the rules.

As a partial example, we have a long history of someone commenting on
a document by proposing alternate text in the from of 

	Old:
	<quotation from original text, possibly several sentences or
	   even a paragraph of two>
	New:
	<text that is not completely new but that include parts of
	   the original with some alterations>

Now, setting aside whatever position the lawyers might take about
where the boundary would fall between "discussion" and violation of a
"no derivatives" position, is it hard to imagine an author who wanted
to protect their ideas, words, and form of expression going on-list
or to moderators and claiming an infringement on a "no derivatives"
statement in the document.  Insisting on such claimed rights could
easily set off a new round of the type of discussion we are having,
completely distract from substantive discussions of the document, and
so on.   A claim that behavior to try to defend against infringement
of a "no derivatives" was disruptive and should be sanctioned would
invite a dispute that it would probably take judges to settle,
probably at considerable cost, both financial and reputational,
probably to both the IETF and participants.

I don't think we want to go there.  And, to me, that means that, if
we are going to prohibit restrictions on discussions, we'd better
decide that, once a document is formally expected to evolve into
something to be published by the community (especially obvious for
IETF stream documents under RFC 8789 as you say, but other streams
who have public discussions about the content of documents they are
going to publish have similar considerations), the prohibition on
no-derivatives probably needs to apply to the documents as well
(again, probably with exceptions for special circumstances the
community can accept).   Put differently for the IETF Stream and as
recently noted on a different list, beyond some point, authors or
editors of a document don't own or control the content of that
document but act as agents of a WG and the IETF.  Their right, or
those of others, to claim "no derivatives" generally should go away
with that transition.  

So my objections to draft-sayre-gendispatch-derivative are that it
doesn't go far enough and that, in not doing so, it opens us up to
more debates about the situation or claims rather than ending those
debates.

And please see the earlier comments below about trying to dispose of
the problem by limiting things to the IETF Stream.

best,
   john


>> Second, while I think the odds that we would, again, find a need to
>> republish an approved standard or technical report developed by a
>> different SDO or other organization -- it is just too easy for them
>> to put up a web page somewhere -- are quite small, experience
>> suggests that, if we made such a rule, if would be only a matter of
>> time before an odd case came up for which we'd have to scramble
>> around to adjust the rules or find a loophole.  I can even imagine
>> at least one scenario in which that need would arise... and
>> require a normative reference from a Standards Track document.
>> Even an "those could be handled by the ISE" rule would work only
>> most of the time. Without speaking for any of the ISEs or their
>> predecessors with whom I've worked, I find it fairly easy to
>> imagine a situation in which a request to republish an externally
>> produced document would arise and an ISE would decide it should
>> not be published without IETF rough consensus for doing so.
>> Forcing a complex dance in which the IESG issued a Last Call on an
>> ISE Stream document, then "suggested" the ISE publish it, but
>> waiving whatever rules we have about normative references to such
>> a document, does not seem to me to be in anyone's interest,
>> especially the interests of transparency about what we are doing.
>> 
>> best,
>>     john
>> 
>> 
>> 
>> 
>> --On Friday, May 8, 2026 12:58 +1200 Brian E Carpenter
>> <[e-mail]> wrote:
>> 
>>> Sorry, I meant:
>>> 
>>> Are there any other exemplars between RFC 5378 and RFC 7016?
>>> 
>>> Regards/Ngā mihi
>>>      Brian Carpenter
>>> 
>>> On 08-May-26 12:56, Brian E Carpenter wrote:
>>>> On 08-May-26 06:38, John Levine wrote:
>>>>> It appears that Salz, Rich <[e-mail]> said:
>>>>>> -=-=-=-=-=-
>>>>>> 
>>>>>>     *
>>>>>> Therefore, IMHO it would be perfectly reasonable to disallow
>>>>>> "no *
>>>>>> derivative rights" for all IETF stream contributions.
>>>>>> 
>>>>>> That�s a really bad idea.  For example, I could post a draft
>>>>>> with no-derivative as a trial balloon to see if the IETF is
>>>>>> interested, say as a DISPATCH presentation. If not, then I am
>>>>>> free to take it to other places or to seek a patent.
>>>>> 
>>>>> Twenty years ago I would have agreed with you. These days, it
>>>>> would take about 10 seconds to stick a draft or draft-like thing
>>>>> on a server somewhere else and send a note to an IETF list
>>>>> saying take a look at my document at https://blah and tell us
>>>>> if you're interested.
>>>>> 
>>>>> Considering the length of this thread, I think the
>>>>> simplification would be worth it. I realize there is a process
>>>>> nit about how you might ask to DISPATCH somehthing if there
>>>>> isn't an I-D but I think we can deal with it.
>>>>> 
>>>>> By my count there have been 21 RFCs published with "no
>>>>> derivatives" lanaguage, the most recent RFC8216 in 2017. The
>>>>> last in the IETF stream was RFC7016 in 2013, over a decade ago.
>>>> 
>>>> And it could not be published in the IETF stream today, per RFC
>>>> 8789.
>>>> 
>>>> Are there any other exemplars between RFC 5378 and RFC 8216?
>>>> 
>>>>        Brian
>> 
>>