Re: [Gendispatch] New Version Notification for draft-thomson-gendispatch-rfc-derivatives-00.txt

[Eric Rescorla <[e-mail]>]

On Thu, Sep 28, 2023 at 8:19 AM Joel Halpern <[e-mail]> wrote:

> I have not asked the lawyers, but I  do think that if you claim your
> different spec is RFC xxxx, the community would probably expect the Trust
> to try to stop that.  I am not sure what tools we have, since as you
> suggest, our trademark is on IETF.
>
I would note that there are already several organizations which already
publish "RFCs" so I'm also not sure what basis we woul dhave.


> As we do not trademark protocol names, you presumably are free to make up
> your own "QUIC" or "IPv6" and try to convince people it was the real
> thing.  As you say, unless you were an author of the specification you
> would have to avoid using the IETF's words.
>
In practice, I suspect even if you were, because generally the authors do
not
contribute *all* of the text.

I am not asking that we tighten our legal protctions further (I can see way
> too many ways that would create problems).  But as far as I can tell, the
> proposed change would constitute endorsing the kined of behavior you
> describe below.  Which even if we can't prevent, we certain want to
> discourage.
>
> At the same time, I fail to see any benefit in permitting derivative
> works.  We do permit verbatim quoting with attribution.  The fact that what
> we permit is insufficient for some open source licenses to include the RFC
> in their documentation.  While I can hypothesize other cases, the draft
> does not make any such assertions.
>
> In fact, while you state that you agree that having multiple specs is a
> problem, the draft seems to claim it is beneficial.
>
Yeah, I realized after I posted my message that I could have written that
more clearly.

I do not think it is a desirable state of affairs for there to be multiple
competing
versions of a spec. However, it is also not good to have a situation where
the
SDO that originally authored the spec is, for whatever reason, not
meaningfully
maintaining it, or the community has gone elsewhere. In that case, I do
think it
is good if that other venue can take over the spec. Does that help clarify
my view (which may not be the view of my co-authors)?

-Ekr


-Ekr

Yours,
>
> Joel
> On 9/28/2023 11:00 AM, Eric Rescorla wrote:
>
>
>
>
> On Thu, Sep 28, 2023 at 6:52 AM Joel Halpern <[e-mail]> wrote:
>
>> I think this is a very bad idea.
>>
>> The point of the IETF process is to reach agreement on standards we can
>> live with that are good for the Internet.  If anyone who doesn't like
>> the agreement, even if they could live with it, can go make a different
>> standard it undermines the value and effort we put in to reach those
>> agreements.   The value to vendors and operators of having a standard
>> (whenver we can reach that goal) is to have itneroperable
>> implementations and only need to implement / support / deploy that
>> standard.  If there are a myriad standards (as is the inherent
>> consequence of allowing folks to fork RFCs) then we remove the value
>> proposition.
>>
>> If someone merely wants to build upon our standards, they already can.
>> What is at stake is the ability for other folks to change IETF RFCs.  I
>> see no value in permitting that.
>>
>
> Hi Joel,
>
> First, let me say that  I agree that it's not desirable to have multiple
> competing versions
> of a different protocol, so I think on that we are on the same page. Where
> I think we
> may disagree is on whether permitting people to use the text in IETF RFCs
> in
> their own specifications has a meaningful impact on whether that happens.
>
> It might be useful to start by putting the question of text aside. Suppose
> that
> I think that the IETF is taking protocol XYZ in the wrong direction. Under
> the current
> IPR rules, I don't think anything precludes me from:
>
> 1. Writing a new document that is wire compatible with XYZ but doesn't use
> the
> words from the IETF specification.
> 2. Calling that protocol "XYZ" in the document.
> 3. Calling that specification an "RFC" and in fact using the same number
> as the
> IETF specification.
> 4. Publishing the specification on my site.
>
> I *do* think I am precluded from using the trademark "IETF".
>
> Do you disagree with any of the above?
>
> -Ekr
>
> Yours,
>>
>> Joel
>>
>> On 9/28/2023 1:50 AM, Martin Thomson wrote:
>> > I raised a question during the IETF 117 plenary.
>> >
>> >>
>> https://www.ietf.org/archive/id/draft-thomson-gendispatch-rfc-derivatives-00.html
>> >>
>> https://datatracker.ietf.org/doc/html/draft-thomson-gendispatch-rfc-derivatives
>> >>
>> >> Abstract:
>> >>
>> >>     The IETF Trust holds rights to RFCs.  This document updates RFC
>> 5377
>> >>     to request that the IETF Trust change its licensing for IETF
>> >>     documents to permit the creation of derivative works.
>> > This is a relatively simple request, but - based on previous
>> discussions on this subject - I'm sure it will be quite controversial.
>> >
>> > Firstly, there is no plan (at least that I'm aware of) to fork the IETF
>> or to take any RFC to another venue.  The authors are pursuing this work
>> because we believe that it is the right thing to do. We believe that this
>> change is consistent with the IETF mission and the principles of open
>> standards that this community abides by.
>> >
>> > More liberal licensing on RFCs will make it easier for people to
>> continue with the maintenance of IETF work, especially when the IETF has no
>> desire or ability to do so itself.
>> >
>> > This would go beyond the excerpting licenses that are included in some
>> RFCs (for example, RFC 6716), where people independently license their
>> contributions independent of the license they grant the IETF Trust, or the
>> inconsistent fair use carve-outs that are available in some jurisdictions.
>> >
>> > Some people have observed that this makes it easier to copy IETF work
>> with the intent of confusing the market.  We have requested the inclusion
>> of what we think are reasonable conditions in the draft.  These conditions
>> are targeted at the potential for misrepresentation and include a
>> requirement to acknowledge the original and its authors, plus a stipulation
>> that protocols use a different name.
>> >
>> > The best defense against this sort of abuse is not copyright
>> protections.  My non-legally-trained understanding is that the IETF cannot
>> copyright a protocol anyway, only its specification can be protected. Our
>> best defense is the quality of the work performed here and the excellent
>> reputation of this institution.
>> >
>> > If there is time on the (already packed) gendispatch agenda, I'd
>> appreciate it if some time could be made for this topic.
>> >
>> > Cheers,
>> > Martin
>> >
>>
>> --
>> Gendispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/gendispatch
>>
>