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

["Joel M. Halpern" <[e-mail]>]

If what is needed is the right to excerpt, with unmodified content 
(format modification clearly would be allowed) portions of the RFC, I 
would support that.  I understand your reasons, as set forth below, for 
seeing that as useful.

But that is not what the text in the draft asks for.  It asks for the 
right to create derivative works.  In copyright terms, that means the 
right to modify the text.  That is where I have trouble.

Yours,
Joel

On 1/29/16 12:24 AM, Ron wrote:
>
> Hi Joel,
>
> On Thu, Jan 28, 2016 at 03:23:37PM -0500, Joel M. Halpern wrote:
>> The point of doing the work to create an RFC is to reach agreements on
>> what the words should be.
>
> Yes, and we spent a lot of time and put a lot of work into making sure
> we picked the best words to clearly describe what it was that we wanted
> to define.
>
> Which is exactly why we want as many people as possible to reuse those
> words *precisely*, rather than having to rewrite them or paraphrase them
> willy-nilly, when they need them to appear in some other context where
> reproducing the full document in its entirety would not be appropriate
> or helpful for perfect understanding.
>
> If I want to provide a function in a library which allows the caller to
> construct or manipulate an OggOpus header structure, it would be much
> better if I can quote the relevant parts of this document directly, with
> some surrounding text that talks about the other constraints and return
> codes of my function, than it would be for me to invent new ways of
> describing that (for no other reason than I'm not permitted to cut and
> paste that and manipulate it to fit my documentation coherently without
> this extra grant).
>
> I think you and I are in violent agreement here that we want these words
> to be preserved as perfectly as possible everywhere they are used in
> reference to this standard.
>
>
>> Saying after that "oh, but anyone else can change these words any way
>> they want" just does not work for me.
>
> Fortunately, that's not what we are saying.  We expressly state that
> you can not call anything you extracted from this an RFC.
>
> We don't want people to misrepresent this, because we already spend
> enough time correcting people who accidentally made some error in
> their implementation.
>
> We don't think that situation would be improved by *forcing* people
> to change these words to use them in their own descriptions and
> library/application documentation.
>
>
>> More generally, I think we need to establish that this is not how we work,
>> rather than letting folks do this more and more often.
>>
>> In terms of documentation, I am actually very concerned with this apparent
>> effort for us to support documenting of protocols and behaviors that do not
>> comply with the RFC.  That is not our purpose.
>
> Again, I think we are in violent agreement with what I *think* is your
> real concern here.  You just appear to be misunderstanding what the
> "apparent effort" is aimed at doing here - and how by not allowing
> people to use selected and context appropriate parts of these words
> verbatim, you are actually forcing them to create precisely the terrible
> outcome that you fear.
>
> Because the only other alternative to that, is they completely ignore
> the licence grant on this document, and we turn a blind eye to that
> and pretend they didn't do that and don't prosecute them for it.
>
> Which isn't a good outcome either, for lots of reasons.  I know a lot
> of corporate licence grants work that way, but I don't think we win
> at this by forcing people who do respect licences to act in a way that
> we seem to agree we all would rather they didn't (and so rewrite this
> document in their own words which they can then redistribute).
>
>
>
> On Thu, Jan 28, 2016 at 04:07:28PM -0500, Joel M. Halpern wrote:
>> We (the IETF) had this discussion regarding our copyright rules.  We
>> discussed the tension with reuse by open source documentation where the
>> community could not commit to copying things without changing them  (If they
>> could make that promise, there would be no problem as such copying is
>> already permitted.)
>
> I can't extract portions of this document, to copy verbatim just the
> salient parts of it into a context where that is what needs to be
> highlighted or explained.
>
> At least not without this extra grant, which is why we want it, or
> something like it, to be part of how these words are licenced for
> reuse.
>
> Doing that is indistinguishable from "modification".
>
> We're running on the assumption that people with good intent should
> be able to misrepresent this document as little as possible in their
> genuine use of it, with the guarantee that people with bad intent
> can't misrepresent their corruption of it as an RFC.
>
>
> If you're coming at this with the mindset of it being some sort of
> ideological war that those evil open source commies are waging on
> our purity of essence, then I can see how you might be missing or
> blinded to the real concern that we have about people using and
> implementing this standard as accurately and correctly as possible.
>
> What we'd like to see happen is that we *strengthen* the IETF's
> authority as the source of the words that everyone uses in their
> own dissemination of understanding this standard.  And you don't
> do that by saying "you must paste in the entire War And Peace epic,
> everywhere you want to do that, or you're allowed to use none of it".
>
>
>> So either the open source communities needs to be able to change the text,
>> or it does not need to be able to change the text, or it has created rules
>> for itself where it needs to be permitted to change the text even though it
>> does not actually want to change.
>
> ... or they have decided that the only protection they have against
> abuse of their own licence conditions is to strictly respect the
> licences that others have given them.
>
> Which means they are in a position of not being able to do things
> which the IETF would probably agree is in its best interests and was
> its intent, and which it can only otherwise turn a blind eye to when
> people and companies who don't show that respect do things which the
> letter of the licence grant did not allow them to do.
>
> RFC 3951 was a poster child for the (I believe unintended) consequences
> of that.  I'm sure there are certainly many others.
>
> The IETF has shown that it has learnt from that, and improved things
> somewhat.  And what we discussed and did for 6716 shows that there is
> understanding about how we're still not quite where we really want to
> be yet ...
>
> Unless "where you want us to be" speaking as an individual is for these
> standards to only be maximally useful to people who ignore the licence
> granted to use them.  Which doesn't seem like a defensible position.
>
>
> Let me quote the explanation I gave before this went to IETF LC, and
> offer another example of why this is important, and why it is being
> recognised more broadly by other standards organisations too ...
>
>
> In https://www.ietf.org/mail-archive/web/codec/current/msg03163.html
> I wrote:
>> In the context of this draft, we *want* people to be able to use it.
>> And personally, I'd much rather have them quote parts of it verbatim,
>> modified to fit coherently into their own documentation, than have them
>> paraphrase those parts of it to avoid the legal restriction - possibly
>> introducing new ambiguities or misunderstandings, which may then become
>> quoted even more widely than the original RFC, simply because people are
>> allowed to reproduce that error in their own work, but aren't allowed to
>> quote or redistribute the RFC directly ...
>>
>> That outcome seems fairly directly counterproductive to what we want to
>> achieve by having a formal standard that we'd like everyone to follow.
>>
>> We'd have a kind of SDO version of Gresham's Law undermining the value
>> and currency of the words we worked so hard to choose carefully here.
>> The aim here is not to dilute the IETF's authority over this document,
>> but to give that authority the greatest possible value we can.
>
>
> The standing proof of that (though certainly not the only example) is
> the POSIX manual pages.
>
> A lot of programmers love manual pages as a primary source of
> documentation, but for many years, we faced the same sort of
> restrictions as we do here without this grant for creating and
> distributing them.
>
>
> And what was the result of that?
>
> An entire shadow standard emerged, of manual pages rewritten from scratch
> to describe the behaviour of POSIX functions in someone's own words.
> Which people then used as their primary source of information about them,
> and all of the errors, and omissions, and small differences became deeply
> engrained in the body of extant code that people came to depend on.
>
> Sometimes those errors would get noticed and fixed, and sometimes it was
> far too late to put the djinn back in the bottle and the chaos that
> caused would become the new reality everyone had to deal with.
>
> I'm sure there's an awesome April 1 RFC waiting to be written where the
> history of that happening to standards produced here is dissected as a
> hilarious yet sad warning to future participants.
>
>
> We can't (always) fix the past, but it is our responsibility to learn
> from it and try not to stuff up the future.
>
> In 2004, the IEEE and The Open Group granted permission to include
> extracts of their documents in derived works which included manual pages
> that detailed the known deviations which programmers may really have to
> deal with in the wild when writing portable code.
>
> In 2014, they renewed that grant for their latest publication of them,
> so it would appear their experience after 10 years, was that the upside
> benefits had clearly exceeded any downside risk.
>
> https://lwn.net/Articles/581858/
>
>
> If the wording of the extra grant that IETF-legal came up with for 6716
> is somehow not optimal, I'd love for us to have that discussion and try
> to address any substantive concerns people have.  But in order to do
> that, I think those need to be expressed a bit more concretely than
> "this is not how we do things", or "I'm afraid", or by picturing it as
> some sort of "them against us" agenda which is only "apparent" to some
> individual participants.
>
>
> I personally have a strong interest in open source software, not as an
> ideology, but because as a methodology It Works.  I likewise have a
> strong interest in the success and the strength of the IETF as an SDO,
> again, because the methodology used here Really Works to produce widely
> accepted standards that people can really use.
>
> I don't think either group can yet claim to be a "solved problem".
> I think we both have a lot we can learn from each other still, and I
> think we have enough overlap for that to occur naturally by osmosis.
> I'd rather we didn't squander that by claiming there is a barrier
> between us which is impermeable as a matter of dogma.
>
> So if there is a real problem here, let's discuss what that is, not
> handwave it away as some sort of outside conspiracy to destroy our
> way of life.
>
> The IETF is one of the best friends and resources that the developers
> of openly interoperable systems have.  There's no way I'd want it on
> my permanent record that I'd done anything to harm that in any way.
> And I don't see how this would.  But if we've missed something that
> we need to pay more attention to, that's where this process excels,
> so let's use it and fix any actual devil we can see in the details.
>
>
>    As an individual participant who helped author this draft,
>    Ron
>
>
>