Re: [Gendispatch] Questions about draft-thomson-gendispatch-rfc-derivatives

[Brian E Carpenter <[e-mail]>]

Hi,

I want to go a bit further along Ted's line of thinking.

The draft is undoubtedly correct that it cannot be retroactive pre-RFC5378. I think it would in fact be wrong in principle, and perhaps also in law but IANAL, to allow derivative works for any RFC published before the present draft is approved and published (if that happens). Authors in the past have submitted their text and allowed the RFC Editor to publish it in the knowledge that derivative works are not allowed. I don't think we can change that without the approval of those authors, which is effectively impossible. So I don't think this draft (if approved and published) and any resulting changes to the TLP can be retroactive to *any* earlier RFC, without requiring author permission.

More fudamentally, the draft says:

"The licensing terms generated in response to RFC 5377 [ADVICE] do not permit the creation of derivative works. This could unduly give the IETF an monopoly over the maintenance of protocols that are published as IETF documents."

There's no "could" about it - it *intentionally* gives the IETF that monopoly.

There's no "unduly" about it - it was instituted to prevent non-interoperable changes to IETF specifications.

That argument is just as strong as it was when first made. The draft hints at why exceptions might be made ("Should the IETF be unable to attract adequate depth of expertise to produce a revision of existing work, another organization might have that expertise.") That's fair enough, and I can see an argument for requesting the Trust to make that possible in specific cases and special circumstances, perhaps requiring IESG consultation. But making this a generic change such that any third party could rework any IETF specification (subject to the "naming rights" rules) is far too loose and very dangerous to interoperability.

One other point. The draft says:

" 7. IANA Considerations

This document has no IANA actions."

That doesn't consider the interaction betwee the "naming rights" discussion and IANA assignments. Is a third-party derivative work allowed to modify or extend an existing IANA registry that was created under IETF instructions? I suspect that will turn out to be a very complex issue.

Regards
    Brian Carpenter

On 09-Nov-23 21:56, Ted Hardie wrote:
> Dear authors,
> 
> I have a couple of questions and notes about the draft to be presented at Gen Dispatch.
> 
> The document references RFC 5377 as the current advice, but this has been obsoleted by RFC 8721.  I do not personally see any differences relevant to the purposes you propose (though the language noting a lack of consensus on the topic is slightly different).  Can you confirm that the updated reference for ADVICE does not change your proposal?
> 
> The document has discussion of how older documents are to be treated in Section 5, effectively saying that older documents do not inherit the new terms.   I believe this means that for any document published prior to the license change, a republication by the IETF with the new license would be required to permit derivative works.  Does this match your understanding?
> 
> For me, this raises a new possibility.  Rather than making a blanket change to allow the creation of derivative works on all RFCs produced on its stream after a specific date, the IETF could make specific representations on the need for derivative works on specific documents to the IETF trust on a case by case basis.  While that might occur on initial publication, it could also occur when the protocol community maintaining a protocol is no longer present in the IETF but is present elsewhere; the IESG could at that time request re-publication with a license permitting derivative works.  Importantly, that would also allow the IETF to specify a recipient organization for the right to derivative works.  While there may be cases where a general right is warranted, there seem to me cases where the rights might be granted to a specific successor (to avoid multiple forks of a specific protocol).
> 
> If that seems like a potentially useful way forward, I will note that in the case where a specific successor has been identified, it would also allow the Trust to grant the rights to the protocol name as well as the text (thus obviating the need for section 3.2).
> 
> I look forward to your comments and the discussion later today.
> 
> regards,
> 
> Ted
>