ietf
[Top] [All Lists]

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

2016-02-03 11:58:18
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

<Prev in Thread] Current Thread [Next in Thread>