Marshall Eubanks <tme@xxxxxxxxxxxxxxxxx> writes: > While this has been argued to death I disagree. The issue was raised only few weeks ago, and this e-mail thread is (as far as I have seen) the first where the problem has bee re-stated in an e-mail to any public IETF list. > Contributors of IETF material should represent that one or more of 3 > conditions apply to any particular contribution: > > 1.) There is no material in this contribution from pre-RFC5378 work. > > 2.) There is material in this contribution from pre-RFC5378 work by > one or more of the > current set of authors, and they hereby license this older material > under the current conditions. > > 3.) There is material in this contribution from pre-RFC5378 work and > the license status of that material may not be consistent with > RFC5378. I like this. > Number 3 is for the cases where the previous authors were different, > or where the current authors do not own their previous work, and is in > either case intended to flag the contribution as > possibly one needing attention by the Trust. For # 3 it means that the Trust cannot sub-license it without contacting the original contributors. For all IETF internal purposes, there shouldn't be any problem. > Note that # 2 and #3 are not mutually exclusive, and obviously the > Trust Counsel would need to pass any actual wording. I believe even # 2 may need consideration by the trust, in case the pre-RFC5378 work contain copyrightable material written by others. > This would shift any work to obtain earlier licenses onto the Trust > and the Trust Counsel, where in my opinion it belongs. This would also > serve the useful purpose of automatically obtaining licenses from > people who are just reusing their own work (if they are in a position > to grant such a license). Indeed. /Simon > Regards > Marshall > >> Any what if the contributor is deceased? >> >> It would be very useful if the IAOC/Trust develop, together with legal >> aid, guiding instructions for this situation. It would answer the >> common questions. It seems applicable to a lot of work that will >> happen >> in the next 5 years: updating any RFC issues prior to RFC 5378. >> >> /Simon >> _______________________________________________ >> Ietf mailing list >> Ietf@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf