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