John C Klensin <john-ietf@xxxxxxx> writes: > Hi. > > In an attempt to get this discussion unstuck and to provide a > way forward for those of us whose reading of 5378 (or advice > from counsel) have convinced us that we cannot post most > documents that contain older text written by others under the > new rules, I've posted a new I-D, > draft-klensin-rfc5378var-00.txt. Thanks for trying to do something about this problem. I've read the -01 document. It describes a solution that would be very far from a good copyright situation -- even further away than RFC 5378 alone, given that RFC 3978 is seriously flawed in some ways. However, I think your draft is likely to be one of few approaches that can gain consensus quickly enough to be an effective solution to the problem you describe. It could be a stop-gap measure for the next year or so, until better copyright policies can be developed. There is one detail I disagree with rather strongly. Section 7 suggests that the Trustees should prepare a replacement for BCP 78. First, I don't think the Trustees have the necessary competences or resources to take on that huge effort. Further, there is a conflict of interest here: any policies written by the Trustees is likely to just give more rights to the IETF Trust That is the problem that caused this situation to begin with. I don't believe the output would be representative of the needs of the wider IETF community. Instead, I suggest there should be a wider IETF effort to document the copyright policy that will serve the IETF better... ...and hopefully such an effort can review some of the bigger pictures that were declared out of scope in the IPR WG. One consideration would then be: * Whether the two-phase construct with an IETF Trust is a good idea. One alternative is to require contributors to release their work under a liberal license that allows everyone to copy and modify it. This would avoid the liability issues that are inherent in the IETF Trust construct. This would save money for the IETF. The license would be significantly less complex. I agree there are some situations were contributors doesn't find this model acceptable. Just like there are exceptions in the current license, there could be a exception in the new license to allow exceptions for non-modifiable content. Compare how the GNU FDL license restricts certain parts of a manual to be modified freely. /Simon _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf