Re: [codec] Last Call: <draft-ietf-codec-oggopus-10.txt> (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard

["Timothy B. Terriberry" <[e-mail]>]

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?