--On Wednesday, January 21, 2009 7:39 -0500 Marshall Eubanks <tme@xxxxxxxxxxxxxxxxx> wrote: > On Jan 21, 2009, at 2:58 AM, Dean Willis wrote: >... >> Given that we've historically weeded out the contributor-list >> on a document to "four or less", even if there were really >> dozens of "contributors" at the alleged insistence of the >> RFC Editor, I don't see how any older document or even a >> majority of new documents-in- progress could be adapted to >> the new rules. >> >> This appears to require complete abandonment of all previous >> works and "clean room" rewrites under the new terms. > > Even in this worse case scenario (which clearly won't be true > in all cases), I think that that is only true for documents > that need to be licensed outside of the IETF process. But there is no way to know whether a particular document will be licensed outside of the IETF process at the point the RFC enters the publication queue, much less when the first I-D that will (or might) lead to such a submission is posted. My recollection (which could easily be wrong) is that it was precisely that lack of foreknowledge that drove the WG to adopt the 5378 plan: if one wants the Trust to be able to license documents for use outside the IETF, and to do so well after those documents are posted as I-Ds or published as RFCs, then the Trust has to acquire the needed rights when the Contributions are made. If they have to wait until they need those rights to issue licenses, they have to take responsibility for tracking down anyone who might be a Contributor (known or unknown, dead or alive, etc.) or they have to license whatever they have, leaving responsibility for getting permission from anyone the Trust hasn't identified and tracked down to the person or group who want to use things outside the IETF. If one takes the definition of "Contribution" and "Contributor" used in 5378 (and 3978, etc.) -- as distinct from the RFC Editor's definition -- seriously, then the first posting of an I-D could contain text contributed to a mailing list months earlier. The length of time between first relevant Contribution and the publication date of an RFC can be very long, certainly measured in years in some cases. That implies that there will be a very long time before we can assume that every Contribution in a document pending publication occurred since 10 November (or whenever 5378 can be legally assumed to be effective). It is clearly outside the authority of the Trust to undo that "everyone transfers rights at submission time" 5378 model, even if it can effectively be made non-retroactive (which the work-around appears intended to do). If we decide, in retrospect, that we don't like it, either someone needs to post an I-D that is much more radical than the three posted so far or we need to spin up a WG. I suspect, given other conversations, that the IESG will insist on a WG unless there is overwhelming consensus for a particular I-D and I believe there is no possibility for overwhelming consensus for anything in this area. While each approach involves many details to be sorted out (including whether there are differences between I-Ds and RFCs, which some of us consider an important question), I think we might adopt any of three models for the long term, any of which would require WG action. There may of course be others but, as general categories, they just don't occur to me right now. The three options are deliberately stated in non-lawyer language and legal theories on which they might be based are not discussed. In no particular order: (1) Abandon the entire 5377 "the Trust gets to grant particular licenses" model and use a "once something is Contributed to the IETF, it is available for use by anyone, for any purpose, including excerpting, modification, and inclusion in for-profit publications" model. Of course, that still leaves a legacy problem of what to do about pre-5378bis Contributions; presumably that would have to fall on those intending to use the material. (2) Discard 5378 and most of 5377. Go back to 3978 as a starting point, modify it to make special provisions for "code" and to make clear that, from a permissions standpoint, any IESG-authorized handoff of a specification to an IETF-recognized standards body is an extended part of the IETF standards process and covered by the same rules. Any _other_ non-IETF use would require those intending to use the material to sort things out (or to decide that they don't need to), just as has been the case for decades. That is potentially burdensome for those who want to include large chunks of RFCs in program documentation (inline or separate) or manuals, but, even if we change the rules to something 5377/5378-like, they still have to deal with older documents unless the Trust is able to guarantee that it has rights to _all_ Contributions that may have made up the document. I continue to believe that IETF handoff of maintenance and responsibility for a spec to another SDO is "part of the IETF standards process" and hence that this could be a clarification that would apply to pre-3978ter contributions, but IANAL and all of the other usual disclaimers. (3) Keep 5378 but remove all obligations for author/submitters to obtain consent from anyone else or guarantee that all rights have been obtained. That would take us all the way down the path that the workaround (and both my I-D and Brian's) starts us down: 5378 could not be assumed to be fully effective for all new documents for a couple of years and would never be fully effective for documents that are revisions of most older ones (where "older ones" are documents containing 5378 material, including descending from I-Ds posted before 10 November). Consequently, the Trust would have trouble granting any licenses under 5377 that were not full of qualifications about rights the Trust might not have and be able to transfer. --john _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf