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

[Jean-Marc Valin <[e-mail]>]

On 02/03/2016 11:10 AM, Stephan Wenger wrote:
> However, it is still a procedural end-run around the currently
> in-force IETF position that the IETF reserves the right for itself to
> create derivative works from the RFCs it created (my paraphrasing).
> While perhaps not relevant for oggopus, it’s also against the main
> mission of standardization: ensure interoperability.  From a
> standardizer’s viewpoint, derivative work is evil (unless conducted
> in a backward compatible way), because it leads to non-interoperable
> implementations solving the same problem.  So if I were on the IESG,
> I would probably insist on an IESG note to the RFC editor requiring
> that this weird comment in the XML source be removed as of the time
> of publication of the RFC.

You cannot ensure interoperability through legal means here. I've seen
several cases where the text of the standard is not free so people
implement it from second-hand descriptions that are freely available on
the web and end up making mistakes. In the case of the IETF, the fact
that the unmodified text is freely (as in beer) distributable helps a
lot, but in any cases where someone needs to distribute a modified copy,
you're always better off given them permission than have them paraphrase
the whole thing the way they understand it.

> Trying to be creative here: I think your main motivation for asking
> the IETF to allow derivative work outside the IETF context is that
> the text could be used outside the IETF to create new containers for
> codecs other than opus.

That's one of them, but there's also mapping Opus to non-Ogg containers,
experimenting with new channel mapping families, and probably others I
can't think of at the moment.

> That’s perhaps somewhat justifiable, as the
> ogg base spec is not an IETF spec, and many codecs are not IETF
> codecs.  (It would not be right, for example, for opus’ RTP payload
> format.) 

Even text of the RTP spec is something that can reasonably be borrowed
for a different container. Not to mention there's still the
documentation-related issue.

> Is that about right?  If yes, then why not express it in a
> field of use limitation in the license granted?  That seems like a
> reasonable and sufficiently narrowly defined exception that could be
> justified.
> 
> Now, such a narrow exception does not solve the open source related
> problems, but for that you should really start a debate about the
> copyright policy as a whole, because it would be a major change
> affecting key tradeoffs of that policy that were deliberated
> literally for years.

Well, for the open-source issue, I think the best solution is still the
license given by authors on the XML.

	Jean-Marc