Re: [codec] AD Evaluation of draft-ietf-codec-oggopus-09

[Ron <[e-mail]>]

On Mon, Jan 11, 2016 at 10:22:33PM -0600, Ben Campbell wrote:
> On 22 Dec 2015, at 14:31, Ron wrote:
> 
> >Yes, I think this probably needs to be changed to something more like
> >>>what IETF legal suggested for RFC 6716, granting "the right to extract
> >>>sections 1 - 14 ...".  This allows people to make liberal use of the
> >>>details in this document, but ensures they can't misrepresent any such
> >>>use as somehow being an RFC.
> >>>
> >
> >>
> >>Using the modified boilerplate from RFC 6716 would make more sense, if
> >>this
> >>document really needs it. But why does this document need it? It doesn't
> >>include code (normative or otherwise) like 6716. Or more to the point,
> >>why
> >>does this document need the extra grants more than any other
> >>standards-track
> >>RFC?
> >
> >
> >The crux here is twofold.  We have organisations including, but not
> >limited to, Debian, who cannot distribute this included with an
> >implementation of it, unless it also grants people the right to
> >redistribute potentially modified versions of it.  A restriction
> >which prevents people from claiming that a modified version is an
> >RFC is fine, but people need to be able to cut selected parts out
> >of it (possibly to include just selected parts in the documentation
> >of their own library or applications), and/or adapt them for other
> >purposes too.
> >
> >But beyond that, this document itself cribbed as much as we could
> >from the work of other previous Ogg mappings, and includes things
> >which are more generally useful, like the channel mapping definitions
> >and the downmixing matrices, just to pick two.
> >
> >So it's not unreasonable to think this may in turn be a base which
> >future work is built on, and in fact we'd encourage that, because
> >it's definitely good not to change things that aren't broken and
> >don't need changing for other future mappings.
> >
> >We'd also encourage that work to ultimately end up in an IETF working
> >group too - but any initial work at least is quite likely to start
> >outside of one until things are proven enough to take that next step.
> >
> >
> >Ultimately, the rationale for this is actually almost identical to
> >6716, the only difference is 6716 created the weird situation where
> >the normative part *was* the code, and it was already covered by a
> >grant even more liberal than what we'd like for the descriptive text.
> >
> >The alternative (which we discussed with Robert Sparks for 6716) is
> >the authors could publish a separate "this is not an RFC" version
> >outside of the IETF with the extra grants - but that didn't seem like
> >it would create less confusion than the solution IETF legal arrived
> >at - which seems pretty close to ideal for any document that might
> >be the basis for future or continuing work.
> >
> >
> >We don't want people to be claiming that modified versions are an RFC,
> >but we would like them to be able to reuse anything out of this that
> >it makes sense to, as freely as we can allow them to.  Otherwise we
> >just artificially stifle further progress (or force everyone to turn
> >a blind eye when people do things we didn't explicitly grant them
> >the right to do - and that is the part I think we all share the desire
> >to avoid).
> 
> My question here is, why is this different for this draft than for any other
> RFC?

I think there's sort of two questions embedded in that, both of which
are relevant and important, but only one of which is sort of in the
scope for this WG to address (which doesn't mean I wouldn't like to
also see the other addressed in whatever is the right scope for it :)

*What* is different, is that the authors are very conscious of this
problem and would very much like to avoid having this RFC caught up
in it, in whatever the best way we might do that would be.  That seems
like a discussion we can reasonably have here (though of course it
won't end here, it still needs broader approval too).

*How* this is document is different from other RFCs, is a somewhat
bigger can of worms.  Because I do actually think that a lot of other
RFCs would stand to benefit from something like this too.

The only ones that maybe wouldn't, would be documents in the mold of
"here's some arbitrary proclamation, that's necessary for interop,
but that there really isn't any scope at all for further development
or research on, unless we find a reason to make an updated arbitrary
proclamation on this later".

But I'd tend to think they are probably in the minority, and most
non-trivial RFCs would be open to further research, possibly initially
outside of the IETF before that research is proven enough to then be
formalised for wider use on one of the RFC tracks.  For things like
that, I think the interesting question is why should the IETF prohibit
that work by default (or only permit it by everyone turning a blind
eye to breaches of the licencing provisions that were granted).

That is a discussion I'd like to have, but here doesn't seem to be
the right place to have it.  Nutting through the details for this
particular draft though might be helpful to that process.  If only
to establish where the right bounds may be, and give everyone some
experience that the world doesn't end and chaos doesn't reign if we
do this.


> Are there no other RFCs that get distributed by Debian or others with
> similar requirements?

There are some other RFCs which can be and are distributed by people
in this position.  But what those have in common is they *all* have
some extra grant permitted in their text to make that possible.

The big difference that occurred with 6716, was that rather than
adding an arbitrary clause somewhere in the text (which tends to
be a bit different if not substantively similar in each document),
IETF legal approved some alternative header boilerplate, which I
do think is a big improvement.  Having a standard grant for this
makes it a lot easier for everyone to know where they stand, and
for the IETF itself to issue a later clarification of its position
if some unforeseen corner case should ever make that necessary.

Debian definitely isn't the only user affected by this, but they
do make a reasonably good John Doe that we can discuss specific
details around.


> As you mention, RFC 6716 was unique in the fact that
> the code _was_ the spec. This draft does not share that property--so how is
> it different from any other standards-track RFC?

I don't think that's actually the important property of 6716 which
gave adding this grant to it real value.  The important part was
that there was a reasonable expectation other users would want to
publish all or some of it in contexts which the standard grant
would otherwise prohibit.

As another example, it might be impossible for me to use parts of
that text, or even the whole document, in a GPL licenced work (in
any way more than just "mere aggregation"), since the added
restrictions could be in conflict with the GPL's licence conditions
(which mandate no additional restrictions), and the resulting work
would be undistributable by anyone who took respecting licences
seriously.  There's a big can of worms all its own in that example,
so again, it's better considered as a poster child for a class of
problems we'd be wise to avoid than a specific individual exception
that needs to be singled out for special treatment.


In 6716 we just had the added paradox of the normative part of the
spec already having a liberal licence grant, while the informative
parts of it did not without the extra grant.


> (As I just responded to Tim, I will not block IETF last call over this
> particular issue, but I expect that there is more discussion to be had
> before all is said and done.)

Nod.  I quite expect there will be too :)  But I think it is a useful
thing for us to inch toward some sort of broader consensus on, that
takes everyone's concerns and use cases and fears into account.


I think in some ways, part of the crux of the problem is that historically
many of the participants have come from corporate backgrounds, where the
default legal presumption is to prohibit as much as you think you can get
away with prohibiting, to the point of actually outlawing things you do
expect and want your users to do, but then ignoring widespread breaches of
that unless someone crosses some line you don't like, in which case you
have the biggest possible bag of ammo for your lawyers to fire at them.

But that kind of falls down when you have organisations that do take such
licence grants seriously, and don't ignore "inconvenient" parts of them
to use them anyway in contravention of what was actually allowed.


In the context of this draft, we *want* people to be able to use it.
And personally, I'd much rather have them quote parts of it verbatim,
modified to fit coherently into their own documentation, than have them
paraphrase those parts of it to avoid the legal restriction - possibly
introducing new ambiguities or misunderstandings, which may then become
quoted even more widely than the original RFC, simply because people are
allowed to reproduce that error in their own work, but aren't allowed to
quote or redistribute the RFC directly ...

That outcome seems fairly directly counterproductive to what we want to
achieve by having a formal standard that we'd like everyone to follow.

We'd have a kind of SDO version of Gresham's Law undermining the value
and currency of the words we worked so hard to choose carefully here.
The aim here is not to dilute the IETF's authority over this document,
but to give that authority the greatest possible value we can.


These are all good questions to ask though, and I would like to see
this bubble up into some good answers the IETF can build consensus on.

  Cheers,
  Ron