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

[Ron <[e-mail]>]

On Tue, Feb 02, 2016 at 02:51:38PM -0600, Robert Sparks wrote:
> Ben's recent response to Tim captures the main point, but to reinforce
> what's said there:
> 
> We learned a lot as a community from going through the development of
> RFC6716, and there's been  strong sentiment expressed that we wouldn't do
> things like produce normative code again. I think if we were able to repeat
> the exercise fresh, knowing what we learned, that we also wouldn't have made
> this copyright change in just this way. However, the most relevant point is
> that with RFC6716 we at least had an exceptional condition to point to. This
> draft does not have that.

This draft does however include things which are directly applicable to
any code which might implement it, even if they don't appear in it in
the form of "normative code".

At the very least things like the header definitions and downmixing
matrices would seem to fall quite squarely under what is described in
RFC 5377 4.3, which says:

 Rights Granted for Implementing Based on IETF Contributions

 ...

 As such, the rough consensus is that the IETF Trust is to grant
 rights such that code components of IETF Contributions can be
 extracted, modified, and used by anyone in any way desired.

And above that gives examples of things considered "code components" and
a rationale which I think is congruent with many of the reasons we've
given for thinking this is needed in this case.


The nature of a codec mapping means this document is full of such things
in various places, and we're keen to avoid the mistakes which severely
limited the use of RFC 3951, which people could only use by distributing
a parser to extract them from the RFC and compile them on the end user's
machine.


> 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).

There is no international consensus on what constitutes "fair use", and
the IETF has no change control over the exceptions that regional
jurisdictions might grant to the terms of the explicit licence granted.

If the intention is to allow things, we should say explicitly what we
intend to allow.  I think we have reasonably broad agreement on what
"common sense" says people should be allowed to do with this text, we
just need to agree on the language which actually allows them to do
that - without needing to resort to external 'loopholes'.


> In the copy below, you elided my suggestion that the draft argue
> why the existing boilerplate is insufficient.

Sorry, that didn't mean I was ignoring it.  To me that question was
implicit, and I thought the previous discussion that you referred to
in that had already answered it - which is why I was trying to
understand the basis upon which you thought it didn't in this case.


> It _is_ fairly clear to me that the kind of change you're asking for is not
> really specific to this draft, though.
> 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.

I'm not actually sure that the things which we do need to make this a
practically useful document are actually applicable to *all* RFCs.

I do think they may be applicable to many more of them, and in more
parts of them, than have currently addressed this question head on.
But this discussion seems to make it clear that we are still at the
"understanding the problem" stage of fixing that, which makes it a
bit premature to be heading straight for "propose a general solution
for all documents" on the basis of what this one needs.


The IETF clearly recognises there is nuance in what rights it needs
to grant individual documents to maximise their usefulness.

RFC 5377 defines some broad categories for the type of rights which
may be required in different cases.

RFC 5744 extends that and requires independent submissions published
as RFCs to always have the sort of liberal grant that we've requested
here, except in exceptional circumstances.


I think the intended uses for *this* document falls across a range
of the categories recommended for use in RFC 5377 section 4.
And that unless we want to get into a horrible game of trying to
individually salami slice which clauses in it most fit into which
categories for which users, the only sensible and pragmatic choice
from that set which could be applied singly is 4.3.

Which is essentially what asking for this extra header text has done.


I think that's a somewhat blunt instrument, and I agree there are
other ways that we can achieve the same outcome, and I agree that
there are questions here which the community will at some point
need to address as it continues to refine the boilerplate options
which it recommends.

Personally, I think that separately publishing the content of this
document, under a licence equivalent to what 4.3 would allow, is not
the option which minimises the risk of having people diverge from
this document in ways I think we all agree would be undesirable.

But I think it does need to be available under such a licence to
cover all the use cases we can already reasonably envisage.

Which is why I think the best option is to have a single publication
as an RFC, which people can only exercise the rights of 4.3 to if
they no longer claim the result is still an RFC.  And I think the
method used for 6716 fits this well, and falls within the existing
recommendations.


Reasonable people could disagree with that though, so I think the
question as it relates to this document is whether the consensus
is that the IETF is best served by doing this, and remaining the
single authoritative source until someone does exercise that right.

Or whether the authors should publish a separate grant, which would
effectively create two sources of this document immediately, in its
unmodified form.  One of which has a less restrictive licence than
the other, and (as Gresham's Law tells us) may then be the most
likely to become the common currency with the widest circulation.


I think that's a question the community does need to form a good
understanding of and address, but the immediate question is what
is the best answer for us to employ with this document?  The
broader question will need to consider many more cases based on
the needs of many more documents, but I think this is a good
example of one of those cases for us to explore solutions to.

  Cheers,
  Ron