Hi Jean-Marc, On 2/3/16, 09:57, "Jean-Marc Valin" <jmvalin@xxxxxxxxxx> wrote: >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. I tend to agree (except perhaps for the word “always” in the last sentence), but what I described is my understanding of the IETF’s position when creating the currently in force copyright policy, and not an absolute truth. > >> 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. So the issue with that proposal would be that it is difficult to create a sufficiently wide carve-out (short of “go and do with it whatever you want”)? I somewhat doubt that. Unfortunately, I don’t have the time right now to be more creative :-) > >> 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. I assume you are referring to the RTP payload format spec for opus, and not RFC 3550. With that spec there is absolutely nothing different from other RTP payload formats and nothing, in my view, that would justify any detour from our established policies and procedures. > >> 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. Within the narrowly interpreted language of the copyright policy RFCs, perhaps yes. But I continue to maintain it would still go against the spirit of the copyright policy. > > Jean-Marc