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

[Ted Hardie <[e-mail]>]

Hi Martin,

Comments in-line.

On Tue, Nov 14, 2023 at 6:15 AM Martin Thomson <[e-mail]> wrote:

> On Thu, Nov 9, 2023, at 19:56, Ted Hardie wrote:
> > The document references RFC 5377 as the current advice, but this has
> > been obsoleted by RFC 8721.
>
> That's my mistake.  I failed to notice that 5377 was obsolete.  I'll fix
> that. See https://github.com/martinthomson/rfc-derivatives/pull/6
>
>
Thanks for the update.

> 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 clarified this during the meeting.  The intent was to ask for licensing
> updates on documents that use the post-RFC 5378 licensing, but not those
> that have are effectively not licensed to the Trust (pre-5378).  That was
> mainly on the basis that obtaining licenses for pre-5378 documents was not
> considered worthwhile in the past, so it would be unlikely to be worthwhile
> here.   On re-reading this, that text was very much unclear.  See
> https://github.com/martinthomson/rfc-derivatives/pull/7


Thanks for the update.  As was noted in the meeting.  it may be
significantly simpler to institute a new regime and apply it only to the
documents going on from there.  The question of releasing change control is
often a significant part of bringing new work to the IETF, and I strongly
suspect that some of those conversations would not have gone the same way
had the change control discussion been to give a global grant of derivative
works (to be fair, I think there are some where it would have been easier
as well as some in which it would have been harder).

>
> > 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.
>
> As I think that I said during the meeting, I don't think that this sort of
> gatekeeping function is a useful one.
>
> We've learned not to hold on too tightly with IANA registries.  Attempts
> to maintain control have been largely unsuccessful to the point that people
> just don't ask.  People rarely ask even when the policy is very loose.
>
> Maybe the word "futile" doesn't apply as much in the case of copyright,
> but what you suggest starts to look a lot like trying for Standards Action
> on a registry.  The possibility that someone might decline a request
> remains, which is still a barrier.  Not asking permission at all removes
> any uncertainty, which is a source of risk for someone who might want to
> take their work back.  I understand that you might want to retain the
> ability to say "no", but that possibility is what I would eliminate.
>
> Perhaps you were suggesting some sort of streamlined process, maybe even a
> mostly automated one.  My sense is that the cost of building a process that
> is effective would probably be greater than a change to the license.
>
>
I was not suggesting an automated process.  I agree that we have moved many
registries to more open policies over time, but we have done so when the
space of the registry was either unbounded or very large.  We haven't gone
there with tight registries like IP version numbers and we haven't even
allowed them to be re-used in those cases, so I think this analogy actually
cuts the other way.  We do expect the choice of registry policy to be
automatically the loosest available; it's a judgement call.  I am
suggesting that this is a judgement call as well.
I think a gatekeeping function that allows work to move from the IETF to
another SDO or body is both useful and probably reasonably lightweight.
The IESG and last call community knows pretty well whether work is going on
in the IETF, and I suspect many cases would be uncontroversial, but it will
be different in some cases.  CIP (RFC 2651) will be easy. SIP (RFC 3261)
would be hard.  SIP should be hard because multiple different groups would
likely fork it in different directions and VoIP interoperability would go
down as a result.  It is also likely that the grants of IPR licenses would
have to be re-evaluated in many cases (I invite you to search the IPR
disclosures for documents relating to SIP to get a sense of the scale of
the problem there).

Just my opinion, of course,

Ted Hardie




> Cheers,
> Martin
>
> p.s., While chasing things down, I realized that transfer of a draft to
> the IRTF or ISE is not allowed by the TLP.  The original authors often
> retain copyright, but in the case where there are contributions from other
> people, I bet that there are plenty of cases where the transfer is
> technically in violation of the license for non-IETF documents.  See
> https://datatracker.ietf.org/doc/html/rfc5378#section-1
>