Robert Sparks wrote:
It is not clear to me how the things you are hoping to achieve with this
extra language are not already available to you (under fair use for
example). In the copy below, you elided my suggestion that the draft
argue why the existing boilerplate is insufficient.
We weren't ignoring it. But first we need to get consensus on an argument.
I don't think fair use is sufficient. That might be acceptable for some
examples given (e.g., quoting one or two sentences in API
documentation), but would not be acceptable for the examples I gave of
using the text as a basis for a mapping for a new codec into Ogg, or a
new mapping of Opus into some other container. I mean, IANAL, but my
understanding is that both of those would go against the spirit of
Folsom v. Marsh and not qualify for fair use.
It _is_ fairly clear to me that the kind of change you're asking for is
not really specific to this draft, though.
Well, the specific thing about this draft is that we wish to include the
XML source as documentation alongside an open-source software library,
with all of the usual open-source rights associated with that. That is
not a property of every draft, at least (for example, it was not a
property of RFC 7007).
The community developed a set of acceptable boilerplate text blocks. The
draft should use what we have, or convince the community that we need to
change what we allow for RFCs.
Reading what the community said in Section 4.4 of RFC 5377, it says,
"There is no consensus at this time to permit the use of text from RFCs
in contexts where the right to modify the text is required. The authors
of IETF Contributions may be able and willing to grant such rights
independently of the rights they have granted to the IETF by making the
Contribution."
We are able and willing. If adding an additional boilerplate text block
is not the way to go about it (and I have no particular ties to that
solution, we were simply doing what had been done before with RFC 6716),
what should we do?