Tim,
On 2/2/16, 20:19, "Timothy B. Terriberry" <tterribe(_at_)xiph(_dot_)org> 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