Tim, On 2/2/16, 20:19, "Timothy B. Terriberry" <tterribe@xxxxxxxx> wrote: >Ron wrote: >> And we are specifically not proposing to give *anyone*, open source or >> otherwise, "the option to take an RFC and “run with it”" ... >> >> We're trying to find consensus on the best way to apply BCP 78 and the >> options outlined in RFC 5377 to the needs of this document, in a way >> that best matches the needs of its intended users to the best interests >> of the IETF. > >It seems to me like putting a BSD copyright header in an XML comment at >the top of the XML source file and dropping Section 13 from the draft >would resolve all of the issues, if everyone agrees that is an >acceptable thing to do. Ron? I believe that, even if I were so inclined (which I’m not), I could not prevent anyone from downloading the so-labelled XML source from the IETF datatracker and modify it in any way I wish. So, yes, it appears to me that this is an option that solves your problem. 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. 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 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.) 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. Stephan