What 'trouble' is there given that the right is limited so that any derivatives have to make it clear they aren't IETF work[1]? I think the IETF has a strong interest in making sure that things that are not IETF works are not described as such (so I understand a general concern about unconstrained reuse), but that doesn't seem to be the case here. Scott K [1] "... no such derivative work shall be presented, displayed, or published in a manner that states or implies that it is part of this RFC or any other IETF Document." On Friday, January 29, 2016 01:10:09 AM Joel M. Halpern wrote: > 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